Proposal to rename specialpurpose to plugins
Locked
12
12
 
|
Hello Everyone,
In reference to earlier discussions and threads on the above subject, I am hereby proposing renaming the directory "specialpurpose" to "plugins". I have patch ready with all tests passing. Ref discussion: https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E Cheers, Taher Alkhateeb |
Re: Proposal to rename specialpurpose to plugins
Administrator
|
+1
Jacques Le 02/01/2017 à 17:45, Taher Alkhateeb a écrit : > Hello Everyone, > > In reference to earlier discussions and threads on the above subject, I am > hereby proposing renaming the directory "specialpurpose" to "plugins". I > have patch ready with all tests passing. > > Ref discussion: > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > Cheers, > > Taher Alkhateeb > |
Re: Proposal to rename specialpurpose to plugins
|
In reply to this post by taher
+1
Gil On 02/01/2017 17:45, Taher Alkhateeb wrote: > Hello Everyone, > > In reference to earlier discussions and threads on the above subject, I am > hereby proposing renaming the directory "specialpurpose" to "plugins". I > have patch ready with all tests passing. > > Ref discussion: > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > Cheers, > > Taher Alkhateeb > |
Re: Proposal to rename specialpurpose to plugins
|
|
What's the plan for the hot-deploy folder? Remove it?
Regards Scott On 3 January 2017 at 08:26, gil portenseigne <[hidden email]> wrote: > +1 > > Gil > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > >> Hello Everyone, >> >> In reference to earlier discussions and threads on the above subject, I am >> hereby proposing renaming the directory "specialpurpose" to "plugins". I >> have patch ready with all tests passing. >> >> Ref discussion: >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E >> >> Cheers, >> >> Taher Alkhateeb >> >> > |
|
|
Hi Scott,
I don't know, it depends on what people prefer. We can either delete the component-load.xml in /plugins and remove hot-deploy, or keep the component-load.xml and hot-deploy. I lean slightly towards the former but no strong opinion. I think one thing at a time though. The focus now is to rename and prepare a mechanism for handling plugins. Perhaps we can start aanother thread to discuss the next steps moving forward. Cheers, Taher Alkhateeb On Jan 2, 2017 11:02 PM, "Scott Gray" <[hidden email]> wrote: > What's the plan for the hot-deploy folder? Remove it? > > Regards > Scott > > On 3 January 2017 at 08:26, gil portenseigne <[hidden email]> > wrote: > > > +1 > > > > Gil > > > > > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > > > >> Hello Everyone, > >> > >> In reference to earlier discussions and threads on the above subject, I > am > >> hereby proposing renaming the directory "specialpurpose" to "plugins". I > >> have patch ready with all tests passing. > >> > >> Ref discussion: > >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e > >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > >> > >> Cheers, > >> > >> Taher Alkhateeb > >> > >> > > > |
Re: Proposal to rename specialpurpose to plugins
|
|
Ok thanks, it just wasn't clear to me.
My only concern with renaming it just for the sake of renaming it is that we have to make sure our documentation reflects the change and we have to be aware that anyone searching our email archives is going to be confused about constant references to a folder that doesn't exist. I'm a +0, I don't want to get in the way of change but at the same time I'm not sure the benefits outweigh the potential confusion. Regards Scott On 3 January 2017 at 09:11, Taher Alkhateeb <[hidden email]> wrote: > Hi Scott, > > I don't know, it depends on what people prefer. We can either delete the > component-load.xml in /plugins and remove hot-deploy, or keep the > component-load.xml and hot-deploy. I lean slightly towards the former but > no strong opinion. > > I think one thing at a time though. The focus now is to rename and prepare > a mechanism for handling plugins. Perhaps we can start aanother thread to > discuss the next steps moving forward. > > Cheers, > > Taher Alkhateeb > > On Jan 2, 2017 11:02 PM, "Scott Gray" <[hidden email]> > wrote: > > > What's the plan for the hot-deploy folder? Remove it? > > > > Regards > > Scott > > > > On 3 January 2017 at 08:26, gil portenseigne < > [hidden email]> > > wrote: > > > > > +1 > > > > > > Gil > > > > > > > > > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > > > > > >> Hello Everyone, > > >> > > >> In reference to earlier discussions and threads on the above subject, > I > > am > > >> hereby proposing renaming the directory "specialpurpose" to > "plugins". I > > >> have patch ready with all tests passing. > > >> > > >> Ref discussion: > > >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e > > >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > >> > > >> Cheers, > > >> > > >> Taher Alkhateeb > > >> > > >> > > > > > > |
|
|
Hi Scott and All,
Recalling earlier discussions, one of the important reasons for creating the plug-in manager is to remove non-core components (perhaps to a separate repo) from OFBiz while having the ability to maintain them easily (i.e. the build system takes care of downloading and incorporating into the code base). So I think what this means is whether you rename or not most of the specialpurpose documentation will be irrelevant anyway if we apply this strategy. Of course the reason for this direction is to maintain a lightweight core. If you just look at the "birt" and "solr" components for example you will be see a massive amount of lib dependencies and some entanglements with core. On Jan 2, 2017 11:42 PM, "Scott Gray" <[hidden email]> wrote: > Ok thanks, it just wasn't clear to me. > > My only concern with renaming it just for the sake of renaming it is that > we have to make sure our documentation reflects the change and we have to > be aware that anyone searching our email archives is going to be confused > about constant references to a folder that doesn't exist. > > I'm a +0, I don't want to get in the way of change but at the same time I'm > not sure the benefits outweigh the potential confusion. > > Regards > Scott > > On 3 January 2017 at 09:11, Taher Alkhateeb <[hidden email]> > wrote: > > > Hi Scott, > > > > I don't know, it depends on what people prefer. We can either delete the > > component-load.xml in /plugins and remove hot-deploy, or keep the > > component-load.xml and hot-deploy. I lean slightly towards the former but > > no strong opinion. > > > > I think one thing at a time though. The focus now is to rename and > prepare > > a mechanism for handling plugins. Perhaps we can start aanother thread to > > discuss the next steps moving forward. > > > > Cheers, > > > > Taher Alkhateeb > > > > On Jan 2, 2017 11:02 PM, "Scott Gray" <[hidden email]> > > wrote: > > > > > What's the plan for the hot-deploy folder? Remove it? > > > > > > Regards > > > Scott > > > > > > On 3 January 2017 at 08:26, gil portenseigne < > > [hidden email]> > > > wrote: > > > > > > > +1 > > > > > > > > Gil > > > > > > > > > > > > > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > > > > > > > >> Hello Everyone, > > > >> > > > >> In reference to earlier discussions and threads on the above > subject, > > I > > > am > > > >> hereby proposing renaming the directory "specialpurpose" to > > "plugins". I > > > >> have patch ready with all tests passing. > > > >> > > > >> Ref discussion: > > > >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e > > > >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > > >> > > > >> Cheers, > > > >> > > > >> Taher Alkhateeb > > > >> > > > >> > > > > > > > > > > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
+1
Jacopo On Mon, Jan 2, 2017 at 5:45 PM, Taher Alkhateeb <[hidden email]> wrote: > Hello Everyone, > > In reference to earlier discussions and threads on the above subject, I am > hereby proposing renaming the directory "specialpurpose" to "plugins". I > have patch ready with all tests passing. > > Ref discussion: > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba167 > 2f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > Cheers, > > Taher Alkhateeb > |
Re: Proposal to rename specialpurpose to plugins
|
|
-1
This serves no other purpose than renaming for the sake of renaming and brings no added value. It will increase the workload on our volunteers contributing, as the impact is far reaching: not only our documentation must be revisited, but also elements in JIRA must be renamed. Our potential adopters, and new comers in the development field will get confused, as books out there are not in sync anymore. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Jan 3, 2017 at 8:25 AM, Jacopo Cappellato < [hidden email]> wrote: > +1 > > Jacopo > > On Mon, Jan 2, 2017 at 5:45 PM, Taher Alkhateeb < > [hidden email]> > wrote: > > > Hello Everyone, > > > > In reference to earlier discussions and threads on the above subject, I > am > > hereby proposing renaming the directory "specialpurpose" to "plugins". I > > have patch ready with all tests passing. > > > > Ref discussion: > > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba167 > > 2f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > > > Cheers, > > > > Taher Alkhateeb > > > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
+1
Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com On Mon, Jan 2, 2017 at 10:15 PM, Taher Alkhateeb <[hidden email] > wrote: > Hello Everyone, > > In reference to earlier discussions and threads on the above subject, I am > hereby proposing renaming the directory "specialpurpose" to "plugins". I > have patch ready with all tests passing. > > Ref discussion: > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba167 > 2f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > Cheers, > > Taher Alkhateeb > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
+0
James
|
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
+1.
Personally, I support the efforts to slim down OFBiz. I think lightweight will give us more flexibility. -----邮件原件----- 发件人: Taher Alkhateeb [mailto:[hidden email]] 发送时间: 2017年1月3日 0:45 收件人: OFBIZ Development Mailing List 主题: Proposal to rename specialpurpose to plugins Hello Everyone, In reference to earlier discussions and threads on the above subject, I am hereby proposing renaming the directory "specialpurpose" to "plugins". I have patch ready with all tests passing. Ref discussion: https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E Cheers, Taher Alkhateeb |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
I will try to exclude some useless dependencies in solr lib later.
BTW, is there any tool to find dependencies conflicts in gradle? -----邮件原件----- 发件人: Taher Alkhateeb [mailto:[hidden email]] 发送时间: 2017年1月3日 13:57 收件人: OFBIZ Development Mailing List 主题: Re: Proposal to rename specialpurpose to plugins Hi Scott and All, Recalling earlier discussions, one of the important reasons for creating the plug-in manager is to remove non-core components (perhaps to a separate repo) from OFBiz while having the ability to maintain them easily (i.e. the build system takes care of downloading and incorporating into the code base). So I think what this means is whether you rename or not most of the specialpurpose documentation will be irrelevant anyway if we apply this strategy. Of course the reason for this direction is to maintain a lightweight core. If you just look at the "birt" and "solr" components for example you will be see a massive amount of lib dependencies and some entanglements with core. On Jan 2, 2017 11:42 PM, "Scott Gray" <[hidden email]> wrote: > Ok thanks, it just wasn't clear to me. > > My only concern with renaming it just for the sake of renaming it is > that we have to make sure our documentation reflects the change and we > have to be aware that anyone searching our email archives is going to > be confused about constant references to a folder that doesn't exist. > > I'm a +0, I don't want to get in the way of change but at the same > time I'm not sure the benefits outweigh the potential confusion. > > Regards > Scott > > On 3 January 2017 at 09:11, Taher Alkhateeb > <[hidden email]> > wrote: > > > Hi Scott, > > > > I don't know, it depends on what people prefer. We can either delete > > the component-load.xml in /plugins and remove hot-deploy, or keep > > the component-load.xml and hot-deploy. I lean slightly towards the > > former but no strong opinion. > > > > I think one thing at a time though. The focus now is to rename and > prepare > > a mechanism for handling plugins. Perhaps we can start aanother > > thread to discuss the next steps moving forward. > > > > Cheers, > > > > Taher Alkhateeb > > > > On Jan 2, 2017 11:02 PM, "Scott Gray" <[hidden email]> > > wrote: > > > > > What's the plan for the hot-deploy folder? Remove it? > > > > > > Regards > > > Scott > > > > > > On 3 January 2017 at 08:26, gil portenseigne < > > [hidden email]> > > > wrote: > > > > > > > +1 > > > > > > > > Gil > > > > > > > > > > > > > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > > > > > > > >> Hello Everyone, > > > >> > > > >> In reference to earlier discussions and threads on the above > subject, > > I > > > am > > > >> hereby proposing renaming the directory "specialpurpose" to > > "plugins". I > > > >> have patch ready with all tests passing. > > > >> > > > >> Ref discussion: > > > >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e > > > >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > > >> > > > >> Cheers, > > > >> > > > >> Taher Alkhateeb > > > >> > > > >> > > > > > > > > > > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
>
> So I think what this means is whether you rename or not most of the > specialpurpose documentation will be irrelevant anyway if we apply this > strategy. Well yes and no. If I expect to find something under specialpurpose and it turns out to contain just a README file then I'll read that and understand where the contents are now. If I don't see specialpurpose, then there won't be anything strongly pointing me to go to plugins instead. I'm not against having a plug-in manager or a lightweight core. I'm just pointing out my concerns about the specific topic of renaming this folder, at this point in time when none of the loftier goals have been met. Regards Scott On 3 January 2017 at 18:57, Taher Alkhateeb <[hidden email]> wrote: > Hi Scott and All, > > Recalling earlier discussions, one of the important reasons for creating > the plug-in manager is to remove non-core components (perhaps to a separate > repo) from OFBiz while having the ability to maintain them easily (i.e. the > build system takes care of downloading and incorporating into the code > base). > > So I think what this means is whether you rename or not most of the > specialpurpose documentation will be irrelevant anyway if we apply this > strategy. > > Of course the reason for this direction is to maintain a lightweight core. > If you just look at the "birt" and "solr" components for example you will > be see a massive amount of lib dependencies and some entanglements with > core. > > On Jan 2, 2017 11:42 PM, "Scott Gray" <[hidden email]> > wrote: > > > Ok thanks, it just wasn't clear to me. > > > > My only concern with renaming it just for the sake of renaming it is that > > we have to make sure our documentation reflects the change and we have to > > be aware that anyone searching our email archives is going to be confused > > about constant references to a folder that doesn't exist. > > > > I'm a +0, I don't want to get in the way of change but at the same time > I'm > > not sure the benefits outweigh the potential confusion. > > > > Regards > > Scott > > > > On 3 January 2017 at 09:11, Taher Alkhateeb <[hidden email]> > > wrote: > > > > > Hi Scott, > > > > > > I don't know, it depends on what people prefer. We can either delete > the > > > component-load.xml in /plugins and remove hot-deploy, or keep the > > > component-load.xml and hot-deploy. I lean slightly towards the former > but > > > no strong opinion. > > > > > > I think one thing at a time though. The focus now is to rename and > > prepare > > > a mechanism for handling plugins. Perhaps we can start aanother thread > to > > > discuss the next steps moving forward. > > > > > > Cheers, > > > > > > Taher Alkhateeb > > > > > > On Jan 2, 2017 11:02 PM, "Scott Gray" <[hidden email]> > > > wrote: > > > > > > > What's the plan for the hot-deploy folder? Remove it? > > > > > > > > Regards > > > > Scott > > > > > > > > On 3 January 2017 at 08:26, gil portenseigne < > > > [hidden email]> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > Gil > > > > > > > > > > > > > > > > > > > > On 02/01/2017 17:45, Taher Alkhateeb wrote: > > > > > > > > > >> Hello Everyone, > > > > >> > > > > >> In reference to earlier discussions and threads on the above > > subject, > > > I > > > > am > > > > >> hereby proposing renaming the directory "specialpurpose" to > > > "plugins". I > > > > >> have patch ready with all tests passing. > > > > >> > > > > >> Ref discussion: > > > > >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e > > > > >> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Taher Alkhateeb > > > > >> > > > > >> > > > > > > > > > > > > > > > |
Re: Proposal to rename specialpurpose to plugins
|
Administrator
|
In reply to this post by Jacques Le Roux
Taher,
Could you please just wait 1 day or 2, maybe more? I'm currently working on https://issues.apache.org/jira/browse/OFBIZ-6919 and its subtasks (a new one is ready but not created). and would prefer to apply these patch before yours because it's a huge thing and mixing both will not help. Thanks Jacques Le 02/01/2017 à 19:34, Jacques Le Roux a écrit : > +1 > > Jacques > > > Le 02/01/2017 à 17:45, Taher Alkhateeb a écrit : >> Hello Everyone, >> >> In reference to earlier discussions and threads on the above subject, I am >> hereby proposing renaming the directory "specialpurpose" to "plugins". I >> have patch ready with all tests passing. >> >> Ref discussion: >> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E >> >> Cheers, >> >> Taher Alkhateeb >> > > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by taher
+1
In general I think that the word 'plugins' will have more meaning to people than 'specialpurpose'. Thanks Sharan On 2017-01-02 17:45 (+0100), Taher Alkhateeb <[hidden email]> wrote: > Hello Everyone, > > In reference to earlier discussions and threads on the above subject, I am > hereby proposing renaming the directory "specialpurpose" to "plugins". I > have patch ready with all tests passing. > > Ref discussion: > https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E > > Cheers, > > Taher Alkhateeb > |
|
|
In reply to this post by Jacques Le Roux
Sure Jacques, I'll wait for you and this thread is under discussion anyway
On Tue, Jan 3, 2017 at 12:32 PM, Jacques Le Roux < [hidden email]> wrote: > Taher, > > Could you please just wait 1 day or 2, maybe more? > > I'm currently working on https://issues.apache.org/jira/browse/OFBIZ-6919 > and its subtasks (a new one is ready but not created). and would prefer to > apply these patch before yours because it's a huge thing and mixing both > will not help. > > Thanks > > Jacques > > > > Le 02/01/2017 à 19:34, Jacques Le Roux a écrit : > >> +1 >> >> Jacques >> >> >> Le 02/01/2017 à 17:45, Taher Alkhateeb a écrit : >> >>> Hello Everyone, >>> >>> In reference to earlier discussions and threads on the above subject, I >>> am >>> hereby proposing renaming the directory "specialpurpose" to "plugins". I >>> have patch ready with all tests passing. >>> >>> Ref discussion: >>> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e >>> 44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E >>> >>> Cheers, >>> >>> Taher Alkhateeb >>> >>> >> >> > |
Re: Proposal to rename specialpurpose to plugins
|
Administrator
|
In reply to this post by Jacques Le Roux
Moreover while svn updating I just got a merge issue with recent lucene changes, then an Eclipse issue (I had it open) and then it seems I have to
remove all Gradle caches, got this https://stackoverflow.com/questions/37919963/gradle-2-10-taskartifacts-cache-properties-lock-access-is-denied-in-android-st Jacques Le 03/01/2017 à 10:32, Jacques Le Roux a écrit : > Taher, > > Could you please just wait 1 day or 2, maybe more? > > I'm currently working on https://issues.apache.org/jira/browse/OFBIZ-6919 and its subtasks (a new one is ready but not created). and would prefer to > apply these patch before yours because it's a huge thing and mixing both will not help. > > Thanks > > Jacques > > > Le 02/01/2017 à 19:34, Jacques Le Roux a écrit : >> +1 >> >> Jacques >> >> >> Le 02/01/2017 à 17:45, Taher Alkhateeb a écrit : >>> Hello Everyone, >>> >>> In reference to earlier discussions and threads on the above subject, I am >>> hereby proposing renaming the directory "specialpurpose" to "plugins". I >>> have patch ready with all tests passing. >>> >>> Ref discussion: >>> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E >>> >>> Cheers, >>> >>> Taher Alkhateeb >>> >> >> > > |
Re: Proposal to rename specialpurpose to plugins
|
|
In reply to this post by Pierre Smits
On Tue, Jan 3, 2017 at 8:57 AM, Pierre Smits <[hidden email]> wrote:
> It will increase the workload on our volunteers > contributing, as the impact is far reaching: not only our documentation > must be revisited, but also elements in JIRA must be renamed. Our potential > adopters, and new comers in the development field will get confused, as > books out there are not in sync anymore. > This is not a direct response to Pierre's message: I am replying to some of the concepts because they are a good representation of a line of thought. Backward compatibility and the impact of change is always a factor for a software with 10+ years history and thousands of consumers. However in general I am not too concerned by the negative impact of change, even if it is about "minor" stuff like improving the name of our artifacts (like in this case): new consumers will judge our products by what they see now and if we have a cleaner system with better names then they will get a better feel. Existing books and materials will still be valid for the versions of the software they have been written for and the new version will open the opportunity to write new and improved versions of them (sell new copies, get new visits etc...). Of course existing consumers, that are used to the current codebase, may get some confusion initially but this community will help them: in fact the change may open drive more active people in the community. Jacopo |
Re: Proposal to rename specialpurpose to plugins
|
Administrator
|
In reply to this post by Jacques Le Roux
This turns to be insane, after deleting the whole Gradle caches and rebooting my machine (was still not working after I DLed the new cache) it was
still not working I have tried to delete C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts\taskArtifacts.lock but then Gradle create it again on "gradlew cleanGradle" C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts>dir Le volume dans le lecteur C s'appelle Système Le numéro de série du volume est 4015-3D33 Répertoire de C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts 03/01/2017 11:28 <REP> . 03/01/2017 11:28 <REP> .. 03/01/2017 11:28 17 taskArtifacts.lock 1 fichier(s) 17 octets 2 Rép(s) 47 975 690 240 octets libres C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts>del *.* C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts\*.*, êtes-vous sûr (O/N) ? o C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts>dir Le volume dans le lecteur C s'appelle Système Le numéro de série du volume est 4015-3D33 Répertoire de C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts 03/01/2017 11:31 <REP> . 03/01/2017 11:31 <REP> .. 0 fichier(s) 0 octets 2 Rép(s) 47 978 377 216 octets libres C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts>cd C:\projectsASF\ofbiz C:\projectsASF\ofbiz>g --stacktrace cleanGradle C:\projectsASF\ofbiz>gradlew --stacktrace cleanGradle :cleanGradle FAILED FAILURE: Build failed with an exception. * Where: Build file 'C:\projectsASF\ofbiz\build.gradle' line: 769 * What went wrong: Execution failed for task ':cleanGradle'. > Unable to delete file: C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts\taskArtifacts.lock * Try: Run with --info or --debug option to get more log output. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':cleanGradle'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:84) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:61) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88) at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:45) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:233) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:74) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:55) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:113) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23) at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30) at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:197) at org.gradle.internal.Factories$1.create(Factories.java:25) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:194) at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:36) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:118) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:112) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:98) at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:66) at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26) at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75) at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49) at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:44) at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:29) at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:47) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74) at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72) at org.gradle.util.Swapper.swap(Swapper.java:38) at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120) at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50) at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:293) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54) at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40) Caused by: org.gradle.api.file.UnableToDeleteFileException: Unable to delete file: C:\projectsASF\ofbiz\.gradle\3.2.1\taskArtifacts\taskArtifacts.lock at org.gradle.api.internal.file.delete.Deleter.handleFailedDelete(Deleter.java:109) at org.gradle.api.internal.file.delete.Deleter.doDeleteInternal(Deleter.java:86) at org.gradle.api.internal.file.delete.Deleter.doDeleteInternal(Deleter.java:81) at org.gradle.api.internal.file.delete.Deleter.doDeleteInternal(Deleter.java:81) at org.gradle.api.internal.file.delete.Deleter.doDeleteInternal(Deleter.java:81) at org.gradle.api.internal.file.delete.Deleter.delete(Deleter.java:66) at org.gradle.api.internal.file.delete.Deleter.delete(Deleter.java:47) at org.gradle.api.internal.file.DefaultFileOperations.delete(DefaultFileOperations.java:137) at org.gradle.api.internal.project.DefaultProject.delete(DefaultProject.java:757) at org.gradle.groovy.scripts.DefaultScript.delete(DefaultScript.java:219) at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:382) at org.gradle.internal.metaobject.BeanDynamicObject.invokeMethod(BeanDynamicObject.java:170) at org.gradle.internal.metaobject.ConfigureDelegate.invokeMethod(ConfigureDelegate.java:80) at build_6doovu22fvyxt2xqr7mryg9wi$_run_closure32$_closure122.doCall(C:\projectsASF\ofbiz\build.gradle:769) at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:588) at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:569) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:95) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:76) ... 69 more BUILD FAILED Total time: 1.552 secs C:\projectsASF\ofbiz> Weird! Jacques Le 03/01/2017 à 10:38, Jacques Le Roux a écrit : > Moreover while svn updating I just got a merge issue with recent lucene changes, then an Eclipse issue (I had it open) and then it seems I have to > remove all Gradle caches, got this > > https://stackoverflow.com/questions/37919963/gradle-2-10-taskartifacts-cache-properties-lock-access-is-denied-in-android-st > > Jacques > > > Le 03/01/2017 à 10:32, Jacques Le Roux a écrit : >> Taher, >> >> Could you please just wait 1 day or 2, maybe more? >> >> I'm currently working on https://issues.apache.org/jira/browse/OFBIZ-6919 and its subtasks (a new one is ready but not created). and would prefer >> to apply these patch before yours because it's a huge thing and mixing both will not help. >> >> Thanks >> >> Jacques >> >> >> Le 02/01/2017 à 19:34, Jacques Le Roux a écrit : >>> +1 >>> >>> Jacques >>> >>> >>> Le 02/01/2017 à 17:45, Taher Alkhateeb a écrit : >>>> Hello Everyone, >>>> >>>> In reference to earlier discussions and threads on the above subject, I am >>>> hereby proposing renaming the directory "specialpurpose" to "plugins". I >>>> have patch ready with all tests passing. >>>> >>>> Ref discussion: >>>> https://lists.apache.org/thread.html/9bb4fba6ec56bd52a5bc55e44ba1672f088ec33eeb8a1af4d16fd6d2@%3Cdev.ofbiz.apache.org%3E >>>> >>>> Cheers, >>>> >>>> Taher Alkhateeb >>>> >>> >>> >> >> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |