subject:"\[DISCUSSION\] Proposed Task List for Moving Forward with Gradle and the Trunk"

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-28 Thread Taher Alkhateeb

Great, I'll continue discussion over there referring to this conversation.

On Thu, Jul 28, 2016 at 10:03 AM, Sharan Foga  wrote:

> Hi
>
> If we are talking about Jira and ways to handle or improve it for the
> project then I did start a discussion thread a few days ago (link below)
>
>
> https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E
>
> It might be good to take this suggestion into that thread rather than
> start an off-topic discussion here.
>
> Thanks
> Sharan
>
>
> On 28/07/16 08:54, Taher Alkhateeb wrote:
>
>> Hi Pierre and Everyone,
>>
>> I gather you might be currently preoccupied to work on this JIRA. If my
>> understanding is correct, then may I suggest to close this JIRA and other
>> similar JIRAs and allow those interested in implementing the work to
>> create
>> their own JIRAs for the following reasons:
>>
>> 1- It is confusing to have too many JIRAs open that no one is working on
>> which is likely to create duplicates.
>> 2- I think it is fair for those who make the effort of designing,
>> implementing, testing and patching to have their name on the JIRA as the
>> Reporter as a recognition of their efforts.
>>
>> Taher Alkhateeb
>>
>> On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb <
>> slidingfilame...@gmail.com
>>
>>> wrote:
>>> Would you be willing to take care of that task Pierre?
>>>
>>> On Jul 27, 2016 6:36 PM, "Pierre Smits"  wrote:
>>>
>>> An issue regarding the move of data up the stack already exists:
 https://issues.apache.org/jira/browse/OFBIZ-7016

 Best regards,

 Pierre Smits

 ORRTIZ.COM 
 OFBiz based solutions & services

 OFBiz Extensions Marketplace
 http://oem.ofbizci.net/oci-2/

 On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
 jacopo.cappell...@hotwaxsystems.com> wrote:

 Initially ecommerce was part of the "core" applications, then it was
>
 moved

> to specialpurpose because as it it is a "template" for the
>
 implementation

> of an ecommerce store rather than a ready to be used application.
> I must admit that the same could apply to the other backend
>
 applications so

> there is definitely a grey area...
> For the short term we could consider to move the demo data up the
> stack.
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
>
>> wrote:
>> Hi Jacopo,
>>
>> You got it 100% right, it was indeed the ecommerce component. Wow!
>>
> This

> means one of two things should happen, either we move ecommerce as a
>>
> core

> application, or we untangle this mess. I'm not very familiar with the
>> history, is there a reason why ecommerce is a specialpurpose
>>
> application?

> it seems to be highly integrated within the framework.
>>
>> Taher Alkhateeb
>>
>> On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>>
>> I think that the core reason for the failure is that most of the
>>>
>> tests

> need
>>
>>> the demo data that is loaded with the ecommerce component; if you
>>>
>> disable
>
>> it the data is not loaded.
>>> Could you please try to enable ecommerce and run them again?
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>> On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com
>>>
 wrote:
 Hi everyone,

 In continuation with the above discussion, I just made a little

>>> experiment
>>>
 which gave me scary results. What did I do?

 1 - Disabled all specialpurpose components (except example, to

>>> make

> it
>
>> a
>>
>>> valid XML file) in specialpurpose/component-load.xml
 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
 3 - Got 100 failing tests

 So upon investigating a little I believe these tests fail due to

>>> multiple
>>
>>> issues:
 - When we disable specialpurpose, the dependency graph for Jars

>>> changes
>
>> and
>>>
 that breaks some system behavior
 - I suspect also some data loading is disabled which fails some of

>>> the
>
>> tests
 - hidden dependencies exist from framework / applications to
 specialpurpose.

 What does that mean? It means our framework is brittle and

>>> depends on

> specialpurpose, and without it being active the system does not

>>> run

> properly.

 If we are serious about improving the system and making it

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-28 Thread Sharan Foga


Hi

If we are talking about Jira and ways to handle or improve it for the 
project then I did start a discussion thread a few days ago (link below)


https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E

It might be good to take this suggestion into that thread rather than 
start an off-topic discussion here.


Thanks
Sharan

On 28/07/16 08:54, Taher Alkhateeb wrote:

Hi Pierre and Everyone,

I gather you might be currently preoccupied to work on this JIRA. If my
understanding is correct, then may I suggest to close this JIRA and other
similar JIRAs and allow those interested in implementing the work to create
their own JIRAs for the following reasons:

1- It is confusing to have too many JIRAs open that no one is working on
which is likely to create duplicates.
2- I think it is fair for those who make the effort of designing,
implementing, testing and patching to have their name on the JIRA as the
Reporter as a recognition of their efforts.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb  wrote:


An issue regarding the move of data up the stack already exists:
https://issues.apache.org/jira/browse/OFBIZ-7016

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


Initially ecommerce was part of the "core" applications, then it was

moved

to specialpurpose because as it it is a "template" for the

implementation

of an ecommerce store rather than a ready to be used application.
I must admit that the same could apply to the other backend

applications so

there is definitely a grey area...
For the short term we could consider to move the demo data up the stack.

Jacopo

On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:
Hi Jacopo,

You got it 100% right, it was indeed the ecommerce component. Wow!

This

means one of two things should happen, either we move ecommerce as a

core

application, or we untangle this mess. I'm not very familiar with the
history, is there a reason why ecommerce is a specialpurpose

application?

it seems to be highly integrated within the framework.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


I think that the core reason for the failure is that most of the

tests

need

the demo data that is loaded with the ecommerce component; if you

disable

it the data is not loaded.
Could you please try to enable ecommerce and run them again?

Thanks,

Jacopo

On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:
Hi everyone,

In continuation with the above discussion, I just made a little

experiment

which gave me scary results. What did I do?

1 - Disabled all specialpurpose components (except example, to

make

it

a

valid XML file) in specialpurpose/component-load.xml
2 - Attempted ./gradlew cleanAll loadDefault testIntegration
3 - Got 100 failing tests

So upon investigating a little I believe these tests fail due to

multiple

issues:
- When we disable specialpurpose, the dependency graph for Jars

changes

and

that breaks some system behavior
- I suspect also some data loading is disabled which fails some of

the

tests
- hidden dependencies exist from framework / applications to
specialpurpose.

What does that mean? It means our framework is brittle and

depends on

specialpurpose, and without it being active the system does not

run

properly.

If we are serious about improving the system and making it

modular,

then

I

find it very important to start with disabling all specialpurpose
components or at least having a second build in buildbot for those
components in isolation of the framework.

I don't think this is a luxury, I highly recommend that we stop

the

specialpurpose components from being active by default to protect

and

isolate the framework and core applications. Actually we need help

from

everyone who is willing to help to volunteer in getting a working

build

with tests passing while all specialpurpose components are

disabled.

Taher Alkhateeb

On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Taher, Gil,

Exactly my thoughts. Nothing (ethically and technically) should

force

an

user to share his/her/its personal plugins. This assumption

must be

part

of

the specifications (assumption as in a theory)

Thanks Taher!



Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :


Hi Gil,

Thank you for sharing past experiences. It seems we are

tackling

something

that was attempted multiple times before. I am a bit optimistic

though

because

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-28 Thread Taher Alkhateeb

Hi Pierre and Everyone,

I gather you might be currently preoccupied to work on this JIRA. If my
understanding is correct, then may I suggest to close this JIRA and other
similar JIRAs and allow those interested in implementing the work to create
their own JIRAs for the following reasons:

1- It is confusing to have too many JIRAs open that no one is working on
which is likely to create duplicates.
2- I think it is fair for those who make the effort of designing,
implementing, testing and patching to have their name on the JIRA as the
Reporter as a recognition of their efforts.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb  wrote:

> Would you be willing to take care of that task Pierre?
>
> On Jul 27, 2016 6:36 PM, "Pierre Smits"  wrote:
>
>> An issue regarding the move of data up the stack already exists:
>> https://issues.apache.org/jira/browse/OFBIZ-7016
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>>
>> > Initially ecommerce was part of the "core" applications, then it was
>> moved
>> > to specialpurpose because as it it is a "template" for the
>> implementation
>> > of an ecommerce store rather than a ready to be used application.
>> > I must admit that the same could apply to the other backend
>> applications so
>> > there is definitely a grey area...
>> > For the short term we could consider to move the demo data up the stack.
>> >
>> > Jacopo
>> >
>> > On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
>> > slidingfilame...@gmail.com
>> > > wrote:
>> >
>> > > Hi Jacopo,
>> > >
>> > > You got it 100% right, it was indeed the ecommerce component. Wow!
>> This
>> > > means one of two things should happen, either we move ecommerce as a
>> core
>> > > application, or we untangle this mess. I'm not very familiar with the
>> > > history, is there a reason why ecommerce is a specialpurpose
>> application?
>> > > it seems to be highly integrated within the framework.
>> > >
>> > > Taher Alkhateeb
>> > >
>> > > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
>> > > jacopo.cappell...@hotwaxsystems.com> wrote:
>> > >
>> > > > I think that the core reason for the failure is that most of the
>> tests
>> > > need
>> > > > the demo data that is loaded with the ecommerce component; if you
>> > disable
>> > > > it the data is not loaded.
>> > > > Could you please try to enable ecommerce and run them again?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Jacopo
>> > > >
>> > > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
>> > > > slidingfilame...@gmail.com
>> > > > > wrote:
>> > > >
>> > > > > Hi everyone,
>> > > > >
>> > > > > In continuation with the above discussion, I just made a little
>> > > > experiment
>> > > > > which gave me scary results. What did I do?
>> > > > >
>> > > > > 1 - Disabled all specialpurpose components (except example, to
>> make
>> > it
>> > > a
>> > > > > valid XML file) in specialpurpose/component-load.xml
>> > > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
>> > > > > 3 - Got 100 failing tests
>> > > > >
>> > > > > So upon investigating a little I believe these tests fail due to
>> > > multiple
>> > > > > issues:
>> > > > > - When we disable specialpurpose, the dependency graph for Jars
>> > changes
>> > > > and
>> > > > > that breaks some system behavior
>> > > > > - I suspect also some data loading is disabled which fails some of
>> > the
>> > > > > tests
>> > > > > - hidden dependencies exist from framework / applications to
>> > > > > specialpurpose.
>> > > > >
>> > > > > What does that mean? It means our framework is brittle and
>> depends on
>> > > > > specialpurpose, and without it being active the system does not
>> run
>> > > > > properly.
>> > > > >
>> > > > > If we are serious about improving the system and making it
>> modular,
>> > > then
>> > > > I
>> > > > > find it very important to start with disabling all specialpurpose
>> > > > > components or at least having a second build in buildbot for those
>> > > > > components in isolation of the framework.
>> > > > >
>> > > > > I don't think this is a luxury, I highly recommend that we stop
>> the
>> > > > > specialpurpose components from being active by default to protect
>> and
>> > > > > isolate the framework and core applications. Actually we need help
>> > from
>> > > > > everyone who is willing to help to volunteer in getting a working
>> > build
>> > > > > with tests passing while all specialpurpose components are
>> disabled.
>> > > > >
>> > > > > Taher Alkhateeb
>> > > > >
>> > > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
>> > > > > jacques.le.r...@les7arts.com> wrote:
>> > > > >
>> > > > > > Hi Taher, Gil,
>> > > > > >
>> > > > > > Exactly my thoughts. Nothing

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Pierre Smits

An issue regarding the move of data up the stack already exists:
https://issues.apache.org/jira/browse/OFBIZ-7016

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Initially ecommerce was part of the "core" applications, then it was moved
> to specialpurpose because as it it is a "template" for the implementation
> of an ecommerce store rather than a ready to be used application.
> I must admit that the same could apply to the other backend applications so
> there is definitely a grey area...
> For the short term we could consider to move the demo data up the stack.
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > Hi Jacopo,
> >
> > You got it 100% right, it was indeed the ecommerce component. Wow! This
> > means one of two things should happen, either we move ecommerce as a core
> > application, or we untangle this mess. I'm not very familiar with the
> > history, is there a reason why ecommerce is a specialpurpose application?
> > it seems to be highly integrated within the framework.
> >
> > Taher Alkhateeb
> >
> > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > I think that the core reason for the failure is that most of the tests
> > need
> > > the demo data that is loaded with the ecommerce component; if you
> disable
> > > it the data is not loaded.
> > > Could you please try to enable ecommerce and run them again?
> > >
> > > Thanks,
> > >
> > > Jacopo
> > >
> > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > > slidingfilame...@gmail.com
> > > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > In continuation with the above discussion, I just made a little
> > > experiment
> > > > which gave me scary results. What did I do?
> > > >
> > > > 1 - Disabled all specialpurpose components (except example, to make
> it
> > a
> > > > valid XML file) in specialpurpose/component-load.xml
> > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > > 3 - Got 100 failing tests
> > > >
> > > > So upon investigating a little I believe these tests fail due to
> > multiple
> > > > issues:
> > > > - When we disable specialpurpose, the dependency graph for Jars
> changes
> > > and
> > > > that breaks some system behavior
> > > > - I suspect also some data loading is disabled which fails some of
> the
> > > > tests
> > > > - hidden dependencies exist from framework / applications to
> > > > specialpurpose.
> > > >
> > > > What does that mean? It means our framework is brittle and depends on
> > > > specialpurpose, and without it being active the system does not run
> > > > properly.
> > > >
> > > > If we are serious about improving the system and making it modular,
> > then
> > > I
> > > > find it very important to start with disabling all specialpurpose
> > > > components or at least having a second build in buildbot for those
> > > > components in isolation of the framework.
> > > >
> > > > I don't think this is a luxury, I highly recommend that we stop the
> > > > specialpurpose components from being active by default to protect and
> > > > isolate the framework and core applications. Actually we need help
> from
> > > > everyone who is willing to help to volunteer in getting a working
> build
> > > > with tests passing while all specialpurpose components are disabled.
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > > jacques.le.r...@les7arts.com> wrote:
> > > >
> > > > > Hi Taher, Gil,
> > > > >
> > > > > Exactly my thoughts. Nothing (ethically and technically) should
> force
> > > an
> > > > > user to share his/her/its personal plugins. This assumption must be
> > > part
> > > > of
> > > > > the specifications (assumption as in a theory)
> > > > >
> > > > > Thanks Taher!
> > > > >
> > > > >
> > > > >
> > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > > >
> > > > >> Hi Gil,
> > > > >>
> > > > >> Thank you for sharing past experiences. It seems we are tackling
> > > > something
> > > > >> that was attempted multiple times before. I am a bit optimistic
> > though
> > > > >> because having the plugin system integrated into the build system
> > is a
> > > > >> different approach that solves multiple problems I think.
> > > > >>
> > > > >> I would like to note that I think it is okay to use the same
> plugin
> > > > system
> > > > >> even for proprietary customer solutions. In fact I think customers
> > > would
> > > > >> understand it more easily than the concept of hot-deploy. Even if
> > the
> > > > >> solution is for one customer and not intended to be shared you can
> > > still
> > > > >> have a sensible command like ./gradlew installPlugin
> > > > >> -PpluginName=customerPlugin

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Taher Alkhateeb

Would you be willing to take care of that task Pierre?

On Jul 27, 2016 6:36 PM, "Pierre Smits"  wrote:

> An issue regarding the move of data up the stack already exists:
> https://issues.apache.org/jira/browse/OFBIZ-7016
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > Initially ecommerce was part of the "core" applications, then it was
> moved
> > to specialpurpose because as it it is a "template" for the implementation
> > of an ecommerce store rather than a ready to be used application.
> > I must admit that the same could apply to the other backend applications
> so
> > there is definitely a grey area...
> > For the short term we could consider to move the demo data up the stack.
> >
> > Jacopo
> >
> > On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
> > slidingfilame...@gmail.com
> > > wrote:
> >
> > > Hi Jacopo,
> > >
> > > You got it 100% right, it was indeed the ecommerce component. Wow! This
> > > means one of two things should happen, either we move ecommerce as a
> core
> > > application, or we untangle this mess. I'm not very familiar with the
> > > history, is there a reason why ecommerce is a specialpurpose
> application?
> > > it seems to be highly integrated within the framework.
> > >
> > > Taher Alkhateeb
> > >
> > > On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> > > jacopo.cappell...@hotwaxsystems.com> wrote:
> > >
> > > > I think that the core reason for the failure is that most of the
> tests
> > > need
> > > > the demo data that is loaded with the ecommerce component; if you
> > disable
> > > > it the data is not loaded.
> > > > Could you please try to enable ecommerce and run them again?
> > > >
> > > > Thanks,
> > > >
> > > > Jacopo
> > > >
> > > > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > > > slidingfilame...@gmail.com
> > > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > In continuation with the above discussion, I just made a little
> > > > experiment
> > > > > which gave me scary results. What did I do?
> > > > >
> > > > > 1 - Disabled all specialpurpose components (except example, to make
> > it
> > > a
> > > > > valid XML file) in specialpurpose/component-load.xml
> > > > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > > > 3 - Got 100 failing tests
> > > > >
> > > > > So upon investigating a little I believe these tests fail due to
> > > multiple
> > > > > issues:
> > > > > - When we disable specialpurpose, the dependency graph for Jars
> > changes
> > > > and
> > > > > that breaks some system behavior
> > > > > - I suspect also some data loading is disabled which fails some of
> > the
> > > > > tests
> > > > > - hidden dependencies exist from framework / applications to
> > > > > specialpurpose.
> > > > >
> > > > > What does that mean? It means our framework is brittle and depends
> on
> > > > > specialpurpose, and without it being active the system does not run
> > > > > properly.
> > > > >
> > > > > If we are serious about improving the system and making it modular,
> > > then
> > > > I
> > > > > find it very important to start with disabling all specialpurpose
> > > > > components or at least having a second build in buildbot for those
> > > > > components in isolation of the framework.
> > > > >
> > > > > I don't think this is a luxury, I highly recommend that we stop the
> > > > > specialpurpose components from being active by default to protect
> and
> > > > > isolate the framework and core applications. Actually we need help
> > from
> > > > > everyone who is willing to help to volunteer in getting a working
> > build
> > > > > with tests passing while all specialpurpose components are
> disabled.
> > > > >
> > > > > Taher Alkhateeb
> > > > >
> > > > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > > > jacques.le.r...@les7arts.com> wrote:
> > > > >
> > > > > > Hi Taher, Gil,
> > > > > >
> > > > > > Exactly my thoughts. Nothing (ethically and technically) should
> > force
> > > > an
> > > > > > user to share his/her/its personal plugins. This assumption must
> be
> > > > part
> > > > > of
> > > > > > the specifications (assumption as in a theory)
> > > > > >
> > > > > > Thanks Taher!
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > > > >
> > > > > >> Hi Gil,
> > > > > >>
> > > > > >> Thank you for sharing past experiences. It seems we are tackling
> > > > > something
> > > > > >> that was attempted multiple times before. I am a bit optimistic
> > > though
> > > > > >> because having the plugin system integrated into the build
> system
> > > is a
> > > > > >> different approach that solves multiple problems I think.
> > > > > >>
> > > > > >> I would like to note that I think it is okay to use

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Jacopo Cappellato

On Wed, Jul 27, 2016 at 3:47 PM, Pierre Smits 
wrote:

> ...
> But when code is already available in the OFBiz repo - and made available
> through releases - such an enabler/disabler is as much overkill to an
> adopter as a convenience script to download JDBC libraries (to paraphrase

another contributor).
>

I disagree based on the feedback I have received from several adopters over
the years (including, but not limited to, the company I work for): the
ability to deploy/enable only the required components is one of the most
frequently requested; on the other hand no one ever asked me an automation
script to download the JDBC driver of the database... but as I said in
another comment, every adopter is different from the others.

Jacopo

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Jacopo Cappellato

Initially ecommerce was part of the "core" applications, then it was moved
to specialpurpose because as it it is a "template" for the implementation
of an ecommerce store rather than a ready to be used application.
I must admit that the same could apply to the other backend applications so
there is definitely a grey area...
For the short term we could consider to move the demo data up the stack.

Jacopo

On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb  wrote:

> Hi Jacopo,
>
> You got it 100% right, it was indeed the ecommerce component. Wow! This
> means one of two things should happen, either we move ecommerce as a core
> application, or we untangle this mess. I'm not very familiar with the
> history, is there a reason why ecommerce is a specialpurpose application?
> it seems to be highly integrated within the framework.
>
> Taher Alkhateeb
>
> On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > I think that the core reason for the failure is that most of the tests
> need
> > the demo data that is loaded with the ecommerce component; if you disable
> > it the data is not loaded.
> > Could you please try to enable ecommerce and run them again?
> >
> > Thanks,
> >
> > Jacopo
> >
> > On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> > slidingfilame...@gmail.com
> > > wrote:
> >
> > > Hi everyone,
> > >
> > > In continuation with the above discussion, I just made a little
> > experiment
> > > which gave me scary results. What did I do?
> > >
> > > 1 - Disabled all specialpurpose components (except example, to make it
> a
> > > valid XML file) in specialpurpose/component-load.xml
> > > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > > 3 - Got 100 failing tests
> > >
> > > So upon investigating a little I believe these tests fail due to
> multiple
> > > issues:
> > > - When we disable specialpurpose, the dependency graph for Jars changes
> > and
> > > that breaks some system behavior
> > > - I suspect also some data loading is disabled which fails some of the
> > > tests
> > > - hidden dependencies exist from framework / applications to
> > > specialpurpose.
> > >
> > > What does that mean? It means our framework is brittle and depends on
> > > specialpurpose, and without it being active the system does not run
> > > properly.
> > >
> > > If we are serious about improving the system and making it modular,
> then
> > I
> > > find it very important to start with disabling all specialpurpose
> > > components or at least having a second build in buildbot for those
> > > components in isolation of the framework.
> > >
> > > I don't think this is a luxury, I highly recommend that we stop the
> > > specialpurpose components from being active by default to protect and
> > > isolate the framework and core applications. Actually we need help from
> > > everyone who is willing to help to volunteer in getting a working build
> > > with tests passing while all specialpurpose components are disabled.
> > >
> > > Taher Alkhateeb
> > >
> > > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > > jacques.le.r...@les7arts.com> wrote:
> > >
> > > > Hi Taher, Gil,
> > > >
> > > > Exactly my thoughts. Nothing (ethically and technically) should force
> > an
> > > > user to share his/her/its personal plugins. This assumption must be
> > part
> > > of
> > > > the specifications (assumption as in a theory)
> > > >
> > > > Thanks Taher!
> > > >
> > > >
> > > >
> > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > > >
> > > >> Hi Gil,
> > > >>
> > > >> Thank you for sharing past experiences. It seems we are tackling
> > > something
> > > >> that was attempted multiple times before. I am a bit optimistic
> though
> > > >> because having the plugin system integrated into the build system
> is a
> > > >> different approach that solves multiple problems I think.
> > > >>
> > > >> I would like to note that I think it is okay to use the same plugin
> > > system
> > > >> even for proprietary customer solutions. In fact I think customers
> > would
> > > >> understand it more easily than the concept of hot-deploy. Even if
> the
> > > >> solution is for one customer and not intended to be shared you can
> > still
> > > >> have a sensible command like ./gradlew installPlugin
> > > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > > >>
> > > >> Having one solution instead of two solutions I think would unify
> > efforts
> > > >> and thinking processes and terminology used. We have only one way of
> > > >> extending OFBiz which is called plugins, and any changes we do
> happen
> > in
> > > >> this unified architecture.
> > > >>
> > > >> So ... food for thought.
> > > >>
> > > >> Taher Alkhateeb
> > > >>
> > > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > > gil.portensei...@nereide.fr>
> > > >> wrote:
> > > >>
> > > >> Hi all,
> > > >>>
> > > >>> First, I like the idea of gradle being the plugin solution endebbed
> >

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Taher Alkhateeb

Hi Jacopo,

You got it 100% right, it was indeed the ecommerce component. Wow! This
means one of two things should happen, either we move ecommerce as a core
application, or we untangle this mess. I'm not very familiar with the
history, is there a reason why ecommerce is a specialpurpose application?
it seems to be highly integrated within the framework.

Taher Alkhateeb

On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> I think that the core reason for the failure is that most of the tests need
> the demo data that is loaded with the ecommerce component; if you disable
> it the data is not loaded.
> Could you please try to enable ecommerce and run them again?
>
> Thanks,
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > Hi everyone,
> >
> > In continuation with the above discussion, I just made a little
> experiment
> > which gave me scary results. What did I do?
> >
> > 1 - Disabled all specialpurpose components (except example, to make it a
> > valid XML file) in specialpurpose/component-load.xml
> > 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> > 3 - Got 100 failing tests
> >
> > So upon investigating a little I believe these tests fail due to multiple
> > issues:
> > - When we disable specialpurpose, the dependency graph for Jars changes
> and
> > that breaks some system behavior
> > - I suspect also some data loading is disabled which fails some of the
> > tests
> > - hidden dependencies exist from framework / applications to
> > specialpurpose.
> >
> > What does that mean? It means our framework is brittle and depends on
> > specialpurpose, and without it being active the system does not run
> > properly.
> >
> > If we are serious about improving the system and making it modular, then
> I
> > find it very important to start with disabling all specialpurpose
> > components or at least having a second build in buildbot for those
> > components in isolation of the framework.
> >
> > I don't think this is a luxury, I highly recommend that we stop the
> > specialpurpose components from being active by default to protect and
> > isolate the framework and core applications. Actually we need help from
> > everyone who is willing to help to volunteer in getting a working build
> > with tests passing while all specialpurpose components are disabled.
> >
> > Taher Alkhateeb
> >
> > On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Hi Taher, Gil,
> > >
> > > Exactly my thoughts. Nothing (ethically and technically) should force
> an
> > > user to share his/her/its personal plugins. This assumption must be
> part
> > of
> > > the specifications (assumption as in a theory)
> > >
> > > Thanks Taher!
> > >
> > >
> > >
> > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> > >
> > >> Hi Gil,
> > >>
> > >> Thank you for sharing past experiences. It seems we are tackling
> > something
> > >> that was attempted multiple times before. I am a bit optimistic though
> > >> because having the plugin system integrated into the build system is a
> > >> different approach that solves multiple problems I think.
> > >>
> > >> I would like to note that I think it is okay to use the same plugin
> > system
> > >> even for proprietary customer solutions. In fact I think customers
> would
> > >> understand it more easily than the concept of hot-deploy. Even if the
> > >> solution is for one customer and not intended to be shared you can
> still
> > >> have a sensible command like ./gradlew installPlugin
> > >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> > >>
> > >> Having one solution instead of two solutions I think would unify
> efforts
> > >> and thinking processes and terminology used. We have only one way of
> > >> extending OFBiz which is called plugins, and any changes we do happen
> in
> > >> this unified architecture.
> > >>
> > >> So ... food for thought.
> > >>
> > >> Taher Alkhateeb
> > >>
> > >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> > gil.portensei...@nereide.fr>
> > >> wrote:
> > >>
> > >> Hi all,
> > >>>
> > >>> First, I like the idea of gradle being the plugin solution endebbed
> > >>> within
> > >>> OFBiz.
> > >>>
> > >>> This could allow OFBiz integrators to share their specific
> improvments
> > >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> > >>> Pierre's
> > >>> OEM initiatives to name a few).
> > >>>
> > >>> Then, from what i understand about what Nicolas said, is that it'd be
> > >>> good
> > >>> to keep hot-deploy and create-component tasks for customer projects.
> > >>>
> > >>> Why not using plugin into customer project ? It is because that is a
> > >>> private, specific and complete new application using core and plugin
> > >>> functionnalities. It has to be separated since it is not a plugin
> (not
> > >>> intended to be shared). The plugin dependency could be solved with a
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Pierre Smits

The perception is growing that 2 different solutions are mixed into one...

One solution is about jump starting development, the other is about
on-boarding existing components into an OFBiz deployment.

If this plugin API/solution was intended for components existing outside of
the OFBiz repo (either publicly available in repos like GitHub, or in
private repos), I would understand the need for it.

But when code is already available in the OFBiz repo - and made available
through releases - such an enabler/disabler is as much overkill to an
adopter as a convenience script to download JDBC libraries (to paraphrase
another contributor).

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Jul 23, 2016 at 7:44 PM, Taher Alkhateeb  wrote:

> Hi Gil,
>
> Thank you for sharing past experiences. It seems we are tackling something
> that was attempted multiple times before. I am a bit optimistic though
> because having the plugin system integrated into the build system is a
> different approach that solves multiple problems I think.
>
> I would like to note that I think it is okay to use the same plugin system
> even for proprietary customer solutions. In fact I think customers would
> understand it more easily than the concept of hot-deploy. Even if the
> solution is for one customer and not intended to be shared you can still
> have a sensible command like ./gradlew installPlugin
> -PpluginName=customerPlugin -Prepository=localFileSystem.
>
> Having one solution instead of two solutions I think would unify efforts
> and thinking processes and terminology used. We have only one way of
> extending OFBiz which is called plugins, and any changes we do happen in
> this unified architecture.
>
> So ... food for thought.
>
> Taher Alkhateeb
>
> On Jul 23, 2016 7:34 PM, "gil portenseigne" 
> wrote:
>
> > Hi all,
> >
> > First, I like the idea of gradle being the plugin solution endebbed
> within
> > OFBiz.
> >
> > This could allow OFBiz integrators to share their specific improvments
> > with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> Pierre's
> > OEM initiatives to name a few).
> >
> > Then, from what i understand about what Nicolas said, is that it'd be
> good
> > to keep hot-deploy and create-component tasks for customer projects.
> >
> > Why not using plugin into customer project ? It is because that is a
> > private, specific and complete new application using core and plugin
> > functionnalities. It has to be separated since it is not a plugin (not
> > intended to be shared). The plugin dependency could be solved with a
> > build.gradle within the hot-deploy component, checking the installation
> > state of the dependent plugin (and installing if needed).
> >
> > And last, for your information, Nereide do not use addons anymore, this
> > system created more problems than it helped, the original idea was good,
> > but some design flaws did showed up...
> > Gil
> >
> >
> >
> > Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> >
> >
> >
> > Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> >
> > Hi,
> >
> > Taher I like you proposal, and I wish to add some complement :)
> >
> > hot-deploy is to manage specific customer site component with the
> business
> > logic specific to each, Apache OFBiz can help to prepare this but do not
> > more (I will like to have this as best practice)
> >
> >
> > I think plugins could do that also
> >
> >
> > I agree to add a new directory plugins and structure it for the future
> > vision :
> > * add capacity to download a plugin from the asf repo
> > * support extension to download from a third plateform (like the
> > /etc/apt/source.list on debian)
> > * manage namespace and as you said dependencies. Need give some coding
> > contions
> >
> >
> > This should be in the specifications indeed, Taher already answered
> >
> >
> > We can create the plugins directory, and keep specialpurpose on a first
> > step and move step by step each component present.
> >
> >
> > This is a very important point and we have to be very careful about the
> > transition!
> >
> > Jacques
> >
> >
> > I imagine a process like this :
> > * ./gradlew installPlugin org.apache.ofbiz.framework.birt :
> >  -> check if birt is present on the plugins directory, if not download
> > from
> >
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
> >  -> enable it on component-load
> >  -> compile, load init date and run init service
> >
> > When you run ./gradlew installAllPlugin :
> > * Realize installPlugin on all know plugins, with the official apache
> > ofbiz release, only plugins present on
> >
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/
> >
> > Nicolas
> >
> > Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
> >
> > Hi Pierre, all,
> >
> > I

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Jacopo Cappellato

I think that the core reason for the failure is that most of the tests need
the demo data that is loaded with the ecommerce component; if you disable
it the data is not loaded.
Could you please try to enable ecommerce and run them again?

Thanks,

Jacopo

On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb  wrote:

> Hi everyone,
>
> In continuation with the above discussion, I just made a little experiment
> which gave me scary results. What did I do?
>
> 1 - Disabled all specialpurpose components (except example, to make it a
> valid XML file) in specialpurpose/component-load.xml
> 2 - Attempted ./gradlew cleanAll loadDefault testIntegration
> 3 - Got 100 failing tests
>
> So upon investigating a little I believe these tests fail due to multiple
> issues:
> - When we disable specialpurpose, the dependency graph for Jars changes and
> that breaks some system behavior
> - I suspect also some data loading is disabled which fails some of the
> tests
> - hidden dependencies exist from framework / applications to
> specialpurpose.
>
> What does that mean? It means our framework is brittle and depends on
> specialpurpose, and without it being active the system does not run
> properly.
>
> If we are serious about improving the system and making it modular, then I
> find it very important to start with disabling all specialpurpose
> components or at least having a second build in buildbot for those
> components in isolation of the framework.
>
> I don't think this is a luxury, I highly recommend that we stop the
> specialpurpose components from being active by default to protect and
> isolate the framework and core applications. Actually we need help from
> everyone who is willing to help to volunteer in getting a working build
> with tests passing while all specialpurpose components are disabled.
>
> Taher Alkhateeb
>
> On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi Taher, Gil,
> >
> > Exactly my thoughts. Nothing (ethically and technically) should force an
> > user to share his/her/its personal plugins. This assumption must be part
> of
> > the specifications (assumption as in a theory)
> >
> > Thanks Taher!
> >
> >
> >
> > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
> >
> >> Hi Gil,
> >>
> >> Thank you for sharing past experiences. It seems we are tackling
> something
> >> that was attempted multiple times before. I am a bit optimistic though
> >> because having the plugin system integrated into the build system is a
> >> different approach that solves multiple problems I think.
> >>
> >> I would like to note that I think it is okay to use the same plugin
> system
> >> even for proprietary customer solutions. In fact I think customers would
> >> understand it more easily than the concept of hot-deploy. Even if the
> >> solution is for one customer and not intended to be shared you can still
> >> have a sensible command like ./gradlew installPlugin
> >> -PpluginName=customerPlugin -Prepository=localFileSystem.
> >>
> >> Having one solution instead of two solutions I think would unify efforts
> >> and thinking processes and terminology used. We have only one way of
> >> extending OFBiz which is called plugins, and any changes we do happen in
> >> this unified architecture.
> >>
> >> So ... food for thought.
> >>
> >> Taher Alkhateeb
> >>
> >> On Jul 23, 2016 7:34 PM, "gil portenseigne" <
> gil.portensei...@nereide.fr>
> >> wrote:
> >>
> >> Hi all,
> >>>
> >>> First, I like the idea of gradle being the plugin solution endebbed
> >>> within
> >>> OFBiz.
> >>>
> >>> This could allow OFBiz integrators to share their specific improvments
> >>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
> >>> Pierre's
> >>> OEM initiatives to name a few).
> >>>
> >>> Then, from what i understand about what Nicolas said, is that it'd be
> >>> good
> >>> to keep hot-deploy and create-component tasks for customer projects.
> >>>
> >>> Why not using plugin into customer project ? It is because that is a
> >>> private, specific and complete new application using core and plugin
> >>> functionnalities. It has to be separated since it is not a plugin (not
> >>> intended to be shared). The plugin dependency could be solved with a
> >>> build.gradle within the hot-deploy component, checking the installation
> >>> state of the dependent plugin (and installing if needed).
> >>>
> >>> And last, for your information, Nereide do not use addons anymore, this
> >>> system created more problems than it helped, the original idea was
> good,
> >>> but some design flaws did showed up...
> >>> Gil
> >>>
> >>>
> >>>
> >>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
> >>>
> >>>
> >>>
> >>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
> >>>
> >>> Hi,
> >>>
> >>> Taher I like you proposal, and I wish to add some complement :)
> >>>
> >>> hot-deploy is to manage specific customer site component with the
> >>> business
> >>> logic specific to

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-27 Thread Taher Alkhateeb

Hi everyone,

In continuation with the above discussion, I just made a little experiment
which gave me scary results. What did I do?

1 - Disabled all specialpurpose components (except example, to make it a
valid XML file) in specialpurpose/component-load.xml
2 - Attempted ./gradlew cleanAll loadDefault testIntegration
3 - Got 100 failing tests

So upon investigating a little I believe these tests fail due to multiple
issues:
- When we disable specialpurpose, the dependency graph for Jars changes and
that breaks some system behavior
- I suspect also some data loading is disabled which fails some of the tests
- hidden dependencies exist from framework / applications to specialpurpose.

What does that mean? It means our framework is brittle and depends on
specialpurpose, and without it being active the system does not run
properly.

If we are serious about improving the system and making it modular, then I
find it very important to start with disabling all specialpurpose
components or at least having a second build in buildbot for those
components in isolation of the framework.

I don't think this is a luxury, I highly recommend that we stop the
specialpurpose components from being active by default to protect and
isolate the framework and core applications. Actually we need help from
everyone who is willing to help to volunteer in getting a working build
with tests passing while all specialpurpose components are disabled.

Taher Alkhateeb

On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Taher, Gil,
>
> Exactly my thoughts. Nothing (ethically and technically) should force an
> user to share his/her/its personal plugins. This assumption must be part of
> the specifications (assumption as in a theory)
>
> Thanks Taher!
>
>
>
> Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
>
>> Hi Gil,
>>
>> Thank you for sharing past experiences. It seems we are tackling something
>> that was attempted multiple times before. I am a bit optimistic though
>> because having the plugin system integrated into the build system is a
>> different approach that solves multiple problems I think.
>>
>> I would like to note that I think it is okay to use the same plugin system
>> even for proprietary customer solutions. In fact I think customers would
>> understand it more easily than the concept of hot-deploy. Even if the
>> solution is for one customer and not intended to be shared you can still
>> have a sensible command like ./gradlew installPlugin
>> -PpluginName=customerPlugin -Prepository=localFileSystem.
>>
>> Having one solution instead of two solutions I think would unify efforts
>> and thinking processes and terminology used. We have only one way of
>> extending OFBiz which is called plugins, and any changes we do happen in
>> this unified architecture.
>>
>> So ... food for thought.
>>
>> Taher Alkhateeb
>>
>> On Jul 23, 2016 7:34 PM, "gil portenseigne" 
>> wrote:
>>
>> Hi all,
>>>
>>> First, I like the idea of gradle being the plugin solution endebbed
>>> within
>>> OFBiz.
>>>
>>> This could allow OFBiz integrators to share their specific improvments
>>> with a easy to use, OOTB tool (thinking about OfbizExtra addons or
>>> Pierre's
>>> OEM initiatives to name a few).
>>>
>>> Then, from what i understand about what Nicolas said, is that it'd be
>>> good
>>> to keep hot-deploy and create-component tasks for customer projects.
>>>
>>> Why not using plugin into customer project ? It is because that is a
>>> private, specific and complete new application using core and plugin
>>> functionnalities. It has to be separated since it is not a plugin (not
>>> intended to be shared). The plugin dependency could be solved with a
>>> build.gradle within the hot-deploy component, checking the installation
>>> state of the dependent plugin (and installing if needed).
>>>
>>> And last, for your information, Nereide do not use addons anymore, this
>>> system created more problems than it helped, the original idea was good,
>>> but some design flaws did showed up...
>>> Gil
>>>
>>>
>>>
>>> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>>>
>>>
>>>
>>> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>>>
>>> Hi,
>>>
>>> Taher I like you proposal, and I wish to add some complement :)
>>>
>>> hot-deploy is to manage specific customer site component with the
>>> business
>>> logic specific to each, Apache OFBiz can help to prepare this but do not
>>> more (I will like to have this as best practice)
>>>
>>>
>>> I think plugins could do that also
>>>
>>>
>>> I agree to add a new directory plugins and structure it for the future
>>> vision :
>>> * add capacity to download a plugin from the asf repo
>>> * support extension to download from a third plateform (like the
>>> /etc/apt/source.list on debian)
>>> * manage namespace and as you said dependencies. Need give some coding
>>> contions
>>>
>>>
>>> This should be in the specifications indeed, Taher already answered
>>>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-23 Thread Jacques Le Roux

Hi Taher, Gil,

Exactly my thoughts. Nothing (ethically and technically) should force an user to share his/her/its personal plugins. This assumption must be part of
the specifications (assumption as in a theory)

Thanks Taher!

Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :

Hi Gil,

Thank you for sharing past experiences. It seems we are tackling something
that was attempted multiple times before. I am a bit optimistic though
because having the plugin system integrated into the build system is a
different approach that solves multiple problems I think.

I would like to note that I think it is okay to use the same plugin system
even for proprietary customer solutions. In fact I think customers would
understand it more easily than the concept of hot-deploy. Even if the
solution is for one customer and not intended to be shared you can still
have a sensible command like ./gradlew installPlugin
-PpluginName=customerPlugin -Prepository=localFileSystem.

Having one solution instead of two solutions I think would unify efforts
and thinking processes and terminology used. We have only one way of
extending OFBiz which is called plugins, and any changes we do happen in
this unified architecture.

So ... food for thought.

Taher Alkhateeb

On Jul 23, 2016 7:34 PM, "gil portenseigne"
wrote:

Hi all,

First, I like the idea of gradle being the plugin solution endebbed within
OFBiz.

This could allow OFBiz integrators to share their specific improvments
with a easy to use, OOTB tool (thinking about OfbizExtra addons or Pierre's
OEM initiatives to name a few).

Then, from what i understand about what Nicolas said, is that it'd be good
to keep hot-deploy and create-component tasks for customer projects.

Why not using plugin into customer project ? It is because that is a
private, specific and complete new application using core and plugin
functionnalities. It has to be separated since it is not a plugin (not
intended to be shared). The plugin dependency could be solved with a
build.gradle within the hot-deploy component, checking the installation
state of the dependent plugin (and installing if needed).

And last, for your information, Nereide do not use addons anymore, this
system created more problems than it helped, the original idea was good,
but some design flaws did showed up...
Gil

Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :

Le 22/07/2016 à 15:31, Nicolas Malin a écrit :

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the business
logic specific to each, Apache OFBiz can help to prepare this but do not
more (I will like to have this as best practice)

I think plugins could do that also

I agree to add a new directory plugins and structure it for the future
vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding
contions

This should be in the specifications indeed, Taher already answered

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

This is a very important point and we have to be very careful about the
transition!

Jacques

I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
-> check if birt is present on the plugins directory, if not download
from
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
-> enable it on component-load
-> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache
ofbiz release, only plugins present on
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned
above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like
install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a
component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-23 Thread Taher Alkhateeb

Hi Gil,

Thank you for sharing past experiences. It seems we are tackling something
that was attempted multiple times before. I am a bit optimistic though
because having the plugin system integrated into the build system is a
different approach that solves multiple problems I think.

I would like to note that I think it is okay to use the same plugin system
even for proprietary customer solutions. In fact I think customers would
understand it more easily than the concept of hot-deploy. Even if the
solution is for one customer and not intended to be shared you can still
have a sensible command like ./gradlew installPlugin
-PpluginName=customerPlugin -Prepository=localFileSystem.

Having one solution instead of two solutions I think would unify efforts
and thinking processes and terminology used. We have only one way of
extending OFBiz which is called plugins, and any changes we do happen in
this unified architecture.

So ... food for thought.

Taher Alkhateeb

On Jul 23, 2016 7:34 PM, "gil portenseigne" 
wrote:

> Hi all,
>
> First, I like the idea of gradle being the plugin solution endebbed within
> OFBiz.
>
> This could allow OFBiz integrators to share their specific improvments
> with a easy to use, OOTB tool (thinking about OfbizExtra addons or Pierre's
> OEM initiatives to name a few).
>
> Then, from what i understand about what Nicolas said, is that it'd be good
> to keep hot-deploy and create-component tasks for customer projects.
>
> Why not using plugin into customer project ? It is because that is a
> private, specific and complete new application using core and plugin
> functionnalities. It has to be separated since it is not a plugin (not
> intended to be shared). The plugin dependency could be solved with a
> build.gradle within the hot-deploy component, checking the installation
> state of the dependent plugin (and installing if needed).
>
> And last, for your information, Nereide do not use addons anymore, this
> system created more problems than it helped, the original idea was good,
> but some design flaws did showed up...
> Gil
>
>
>
> Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
>
>
>
> Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
>
> Hi,
>
> Taher I like you proposal, and I wish to add some complement :)
>
> hot-deploy is to manage specific customer site component with the business
> logic specific to each, Apache OFBiz can help to prepare this but do not
> more (I will like to have this as best practice)
>
>
> I think plugins could do that also
>
>
> I agree to add a new directory plugins and structure it for the future
> vision :
> * add capacity to download a plugin from the asf repo
> * support extension to download from a third plateform (like the
> /etc/apt/source.list on debian)
> * manage namespace and as you said dependencies. Need give some coding
> contions
>
>
> This should be in the specifications indeed, Taher already answered
>
>
> We can create the plugins directory, and keep specialpurpose on a first
> step and move step by step each component present.
>
>
> This is a very important point and we have to be very careful about the
> transition!
>
> Jacques
>
>
> I imagine a process like this :
> * ./gradlew installPlugin org.apache.ofbiz.framework.birt :
>  -> check if birt is present on the plugins directory, if not download
> from
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
>  -> enable it on component-load
>  -> compile, load init date and run init service
>
> When you run ./gradlew installAllPlugin :
> * Realize installPlugin on all know plugins, with the official apache
> ofbiz release, only plugins present on
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/
>
> Nicolas
>
> Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
>
> Hi Pierre, all,
>
> I think perhaps my proposal was short and therefore your understanding of
> it is a bit different than what I had in mind. So I list below more
> specifically what I mean about each point from the ones you mentioned
> above
> to further fine-tune the discussion.
>
> - The difference between createComponent and createPlugin is that the
> plugin resides in /plugins instead of hot-deploy and added to
> component-load.xml and also contains a build.gradle file designed
> specifically for plugins. This script contains standard tasks like
> install,
> uninstall, perhaps even upgrade. The magic work for plugins will be in
> their build scripts to integrate tightly with OFBiz.
>
> - The activate/deactivate tasks are just a little convenience tasks that
> add/remove components to the component-load.xml instead of editing it by
> hand so it is just using what exists. Gradle completely ignores a
> component
> if it does not exist in component-load.xml and would not even compile it.
> So you can think of this as just providing more ease to the end-user,
> similar to your suggestion with the createComponent.
>
> - The

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-23 Thread gil portenseigne


Hi all,

First, I like the idea of gradle being the plugin solution endebbed 
within OFBiz.


This could allow OFBiz integrators to share their specific improvments 
with a easy to use, OOTB tool (thinking about OfbizExtra addons or 
Pierre's OEM initiatives to name a few).


Then, from what i understand about what Nicolas said, is that it'd be 
good to keep hot-deploy and create-component tasks for customer projects.


Why not using plugin into customer project ? It is because that is a 
private, specific and complete new application using core and plugin 
functionnalities. It has to be separated since it is not a plugin (not 
intended to be shared). The plugin dependency could be solved with a 
build.gradle within the hot-deploy component, checking the installation 
state of the dependent plugin (and installing if needed).


And last, for your information, Nereide do not use addons anymore, this 
system created more problems than it helped, the original idea was good, 
but some design flaws did showed up...


Gil



Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :



Le 22/07/2016 à 15:31, Nicolas Malin a écrit :

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the 
business logic specific to each, Apache OFBiz can help to prepare 
this but do not more (I will like to have this as best practice)


I think plugins could do that also



I agree to add a new directory plugins and structure it for the 
future vision :

* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some 
coding contions


This should be in the specifications indeed, Taher already answered



We can create the plugins directory, and keep specialpurpose on a 
first step and move step by step each component present.


This is a very important point and we have to be very careful about 
the transition!


Jacques



I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not 
download from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt

 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache 
ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/


Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your 
understanding of

it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you 
mentioned above

to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like 
install,

uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks 
that
add/remove components to the component-load.xml instead of editing 
it by
hand so it is just using what exists. Gradle completely ignores a 
component
if it does not exist in component-load.xml and would not even 
compile it.

So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for 
that
plugin). For example, it might apply patches on some core 
applications (and

reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this 
feature

I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use 
for the
existing components and at the same time a general purpose plugin 
system.
We might even have a task like say "updatePlugin" in the future and 
it is

also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should 
definitely
tackle, however what I am suggesting right now is some foundational 
work

that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly 
needed
to protect the core framework and applications and to provide an

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-23 Thread Jacques Le Roux

Taher, Nicolas,

I like you plan Taher.

I had a small discussion with Nicolas by phone on this subject before he wrote his answer. I told me that he prefers to separate the OOTB things (aka
specialpurpose now) from the outside things (aka hot-deploy now)

I still think that if we have real plugins (a sole plugins folder with sub-folders for plugins - still to be clearly defined -, ie not current
components) he does not make sense to separate these two aspects.

But I'd need Nicolas to clarify why he thinks so.

Is it for legacy reasons (due to Neereides addons for instance)?

Does he has another plan?

Or does he have other reasons?

I know Nicolas has a long experience with addons, so it's worth to listen his
opinion before engaging to specify OFBiz plugins.

IIRW Neereides addons were using Ivy and patches, and we are proposing something new with Gradle and its jars dependencies engine + a specific DSL +
Groovy and the possibility to call Ant targets (eg for legacy transition). Did I miss something :) ?

Thanks

Jacques

Le 22/07/2016 à 15:58, Taher Alkhateeb a écrit :

Hi Nicolas,

Actually as I was discussing this with Jacques in one of the JIRAs he
mentioned something which I found very interesting:

If we create a full plugin API for creating a new plugin from templates and
we provide everything necessary for updating then perhaps hot-deploy is
even not that necessary anymore! it could simply be replaced with ./gradlew
installPlugin -PpluginName=thePluginExistingInFolder.

Also .. a lot of customization can be done with flags. So using your
example we can perhaps say something like:

./gradlew installPlugin -PpluginName=birt -Prepository=org.apache.ofbiz
or
./gradlew installPlugin -PpluginName=MyPlugin -Prepository=local
or
./gradlew installPlugin -PpluginName=commercialPlugin
-Prepository=com.someCompany

first one is default which is official OFBiz plugin, second one is local
file system, third one is commercial plugin for a company. Also we can
define a task in every plugin called "installDependencies" or something
like that which checks for dependent plugins and install them.

We can go crazy with this :) A lot of ideas are ringing in my head.

Taher Alkhateeb

On Friday, 22 July 2016, Nicolas Malin wrote:

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the business
logic specific to each, Apache OFBiz can help to prepare this but do not
more (I will like to have this as best practice)

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-23 Thread Jacques Le Roux




Le 22/07/2016 à 15:31, Nicolas Malin a écrit :

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the business logic specific to each, Apache OFBiz can help to prepare this but do not 
more (I will like to have this as best practice)


I think plugins could do that also



I agree to add a new directory plugins and structure it for the future vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding contions


This should be in the specifications indeed, Taher already answered



We can create the plugins directory, and keep specialpurpose on a first step 
and move step by step each component present.


This is a very important point and we have to be very careful about the 
transition!

Jacques



I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not download from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt

 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/


Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications (and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly needed
to protect the core framework and applications and to provide an eco-system
around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :


the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model


Sorry, I have noticed I have the bad tendency of using the word
"introduced" instead of "put" or "add" (due to "introduire" false friend in
French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Ron Wheeler

This is a great step forward.

Thanks
Ron

On 22/07/2016 11:49 AM, Taher Alkhateeb wrote:

Oh I see Ron, this is already implemented. Every plugin can have a
build.gradle file. This file declares the dependencies specific to that
plugin (which actually points to jcenter).

So that part is already done for you :) now we need to figure out the
plugin API which was being discussed in the last few emails.

On Fri, Jul 22, 2016 at 5:53 PM, Ron Wheeler
wrote:

For 3rd party libraries, would Maven Central be a good source?

Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the
business logic specific to each, Apache OFBiz can help to prepare this
but
do not more (I will like to have this as best practice)

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
-> check if birt is present on the plugins directory, if not download
from

svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
-> enable it on component-load
-> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache
ofbiz release, only plugins present on

svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding
of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned
above
to further fine-tune the discussion.

- The activate/deactivate tasks are just a little convenience tasks
that
add/remove components to the component-load.xml instead of editing it
by
hand so it is just using what exists. Gradle completely ignores a
component
if it does not exist in component-load.xml and would not even compile
it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for
that
plugin). For example, it might apply patches on some core applications
(and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this
feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for
the
existing components and at the same time a general purpose plugin
system.
We might even

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Taher Alkhateeb

Oh I see Ron, this is already implemented. Every plugin can have a
build.gradle file. This file declares the dependencies specific to that
plugin (which actually points to jcenter).

So that part is already done for you :) now we need to figure out the
plugin API which was being discussed in the last few emails.

On Fri, Jul 22, 2016 at 5:53 PM, Ron Wheeler  wrote:

> I was thinking more about the 3rd party artifacts that can not be included
> in releases but need to be installed before OFBiz can run.
>
> I guess that I am assuming that eventually a user will get some sort of
> installer that will take all of the various components developed by OFBiz,
> find all of the (OFBiz and3rd-party libraries) libraries required to run
> the options (plug-ins or core features) selected during the installation
> dialogue and organize them in a folder structure and run the required setup
> processes to load the seed data and load any industry or
> application-specific seed data selected.
>
> I am also looking forward to the day that the framework will be available
> as a separate product  with no dependencies on the ERP and the ERP will
> have a number of modules with a hierarchy of dependencies rather than a web.
>
>
>  Ron
>
>
> On 22/07/2016 10:12 AM, Taher Alkhateeb wrote:
>
>> Hi Ron,
>>
>> Maven and Jcenter are jar repositories. OFBiz components are not jars, so
>> I
>> am not sure but I think it would not fit, unless perhaps we can jar and
>> unjar the folder not sure.
>>
>> On Friday, 22 July 2016, Ron Wheeler 
>> wrote:
>>
>> For 3rd party libraries, would Maven Central be a good source?
>>> Everything is there that does not need a license to access
>>> There is a well defined and well supported service for getting artifacts.
>>>
>>> Ron
>>>
>>> On 22/07/2016 9:31 AM, Nicolas Malin wrote:
>>>
>>> Hi,

 Taher I like you proposal, and I wish to add some complement :)

 hot-deploy is to manage specific customer site component with the
 business logic specific to each, Apache OFBiz can help to prepare this
 but
 do not more (I will like to have this as best practice)

 I agree to add a new directory plugins and structure it for the future
 vision :
 * add capacity to download a plugin from the asf repo
 * support extension to download from a third plateform (like the
 /etc/apt/source.list on debian)
 * manage namespace and as you said dependencies. Need give some coding
 contions

 We can create the plugins directory, and keep specialpurpose on a first
 step and move step by step each component present.

 I imagine a process like this :
 * ./gradlew installPlugin org.apache.ofbiz.framework.birt :
   -> check if birt is present on the plugins directory, if not download
 from

 svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
   -> enable it on component-load
   -> compile, load init date and run init service

 When you run ./gradlew installAllPlugin :
 * Realize installPlugin on all know plugins, with the official apache
 ofbiz release, only plugins present on

 svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

 Nicolas

 Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

 Hi Pierre, all,
>
> I think perhaps my proposal was short and therefore your understanding
> of
> it is a bit different than what I had in mind. So I list below more
> specifically what I mean about each point from the ones you mentioned
> above
> to further fine-tune the discussion.
>
> - The difference between createComponent and createPlugin is that the
> plugin resides in /plugins instead of hot-deploy and added to
> component-load.xml and also contains a build.gradle file designed
> specifically for plugins. This script contains standard tasks like
> install,
> uninstall, perhaps even upgrade. The magic work for plugins will be in
> their build scripts to integrate tightly with OFBiz.
>
> - The activate/deactivate tasks are just a little convenience tasks
> that
> add/remove components to the component-load.xml instead of editing it
> by
> hand so it is just using what exists. Gradle completely ignores a
> component
> if it does not exist in component-load.xml and would not even compile
> it.
> So you can think of this as just providing more ease to the end-user,
> similar to your suggestion with the createComponent.
>
> - The install/uninstall tasks are not just a copy-paste of folders. It
> actually executes business logic (optionally) for any plugin author who
> wishes to execute it (by calling specific tasks in build.gradle for
> that
> plugin). For example, it might apply patches on some core applications
> (and

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Ron Wheeler

I was thinking more about the 3rd party artifacts that can not be 
included in releases but need to be installed before OFBiz can run.


I guess that I am assuming that eventually a user will get some sort of 
installer that will take all of the various components developed by 
OFBiz, find all of the (OFBiz and3rd-party libraries) libraries required 
to run the options (plug-ins or core features) selected during the 
installation dialogue and organize them in a folder structure and run 
the required setup processes to load the seed data and load any industry 
or application-specific seed data selected.


I am also looking forward to the day that the framework will be 
available as a separate product  with no dependencies on the ERP and the 
ERP will have a number of modules with a hierarchy of dependencies 
rather than a web.



 Ron

On 22/07/2016 10:12 AM, Taher Alkhateeb wrote:

Hi Ron,

Maven and Jcenter are jar repositories. OFBiz components are not jars, so I
am not sure but I think it would not fit, unless perhaps we can jar and
unjar the folder not sure.

On Friday, 22 July 2016, Ron Wheeler  wrote:


For 3rd party libraries, would Maven Central be a good source?
Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:


Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the
business logic specific to each, Apache OFBiz can help to prepare this but
do not more (I will like to have this as best practice)

I agree to add a new directory plugins and structure it for the future
vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding
contions

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
  -> check if birt is present on the plugins directory, if not download
from
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
  -> enable it on component-load
  -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache
ofbiz release, only plugins present on
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :


Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned
above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like
install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a
component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications
(and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this
feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should
definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly
needed
to protect the core framework and

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Taher Alkhateeb

Hi Ron,

Maven and Jcenter are jar repositories. OFBiz components are not jars, so I
am not sure but I think it would not fit, unless perhaps we can jar and
unjar the folder not sure.

On Friday, 22 July 2016, Ron Wheeler  wrote:

> For 3rd party libraries, would Maven Central be a good source?
> Everything is there that does not need a license to access
> There is a well defined and well supported service for getting artifacts.
>
> Ron
>
> On 22/07/2016 9:31 AM, Nicolas Malin wrote:
>
>> Hi,
>>
>> Taher I like you proposal, and I wish to add some complement :)
>>
>> hot-deploy is to manage specific customer site component with the
>> business logic specific to each, Apache OFBiz can help to prepare this but
>> do not more (I will like to have this as best practice)
>>
>> I agree to add a new directory plugins and structure it for the future
>> vision :
>> * add capacity to download a plugin from the asf repo
>> * support extension to download from a third plateform (like the
>> /etc/apt/source.list on debian)
>> * manage namespace and as you said dependencies. Need give some coding
>> contions
>>
>> We can create the plugins directory, and keep specialpurpose on a first
>> step and move step by step each component present.
>>
>> I imagine a process like this :
>> * ./gradlew installPlugin org.apache.ofbiz.framework.birt :
>>  -> check if birt is present on the plugins directory, if not download
>> from
>> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
>>  -> enable it on component-load
>>  -> compile, load init date and run init service
>>
>> When you run ./gradlew installAllPlugin :
>> * Realize installPlugin on all know plugins, with the official apache
>> ofbiz release, only plugins present on
>> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/
>>
>> Nicolas
>>
>> Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
>>
>>> Hi Pierre, all,
>>>
>>> I think perhaps my proposal was short and therefore your understanding of
>>> it is a bit different than what I had in mind. So I list below more
>>> specifically what I mean about each point from the ones you mentioned
>>> above
>>> to further fine-tune the discussion.
>>>
>>> - The difference between createComponent and createPlugin is that the
>>> plugin resides in /plugins instead of hot-deploy and added to
>>> component-load.xml and also contains a build.gradle file designed
>>> specifically for plugins. This script contains standard tasks like
>>> install,
>>> uninstall, perhaps even upgrade. The magic work for plugins will be in
>>> their build scripts to integrate tightly with OFBiz.
>>>
>>> - The activate/deactivate tasks are just a little convenience tasks that
>>> add/remove components to the component-load.xml instead of editing it by
>>> hand so it is just using what exists. Gradle completely ignores a
>>> component
>>> if it does not exist in component-load.xml and would not even compile it.
>>> So you can think of this as just providing more ease to the end-user,
>>> similar to your suggestion with the createComponent.
>>>
>>> - The install/uninstall tasks are not just a copy-paste of folders. It
>>> actually executes business logic (optionally) for any plugin author who
>>> wishes to execute it (by calling specific tasks in build.gradle for that
>>> plugin). For example, it might apply patches on some core applications
>>> (and
>>> reverse patches in case of uninstall). Now our standard plugins do not
>>> touch applications or framework, but since we are introducing this
>>> feature
>>> I'm trying to also combine a unified solution for all plugins (Apache
>>> supported and 3rd party). So in one shot we have both ease of use for the
>>> existing components and at the same time a general purpose plugin system.
>>> We might even have a task like say "updatePlugin" in the future and it is
>>> also possible to introduce rudimentary dependency management (Gradle is
>>> really good at this).
>>>
>>> Finally, what to do about specialpurpose is something we should
>>> definitely
>>> tackle, however what I am suggesting right now is some foundational work
>>> that gives you easy choices when you need to make them, and it has the
>>> added bonus of introducing a plugin system for OFBiz which is badly
>>> needed
>>> to protect the core framework and applications and to provide an
>>> eco-system
>>> around it. I'm trying to reach a win-win solution if you will.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :

 the graph needs to be checked/amended to possibly remove components
> dependencies only introduced by the data model
>
> Sorry, I have noticed I have the bad tendency of using the word
 "introduced" instead of "put" or "add" (due to "introduire" false
 friend in

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Ron Wheeler


For 3rd party libraries, would Maven Central be a good source?
Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the 
business logic specific to each, Apache OFBiz can help to prepare this 
but do not more (I will like to have this as best practice)


I agree to add a new directory plugins and structure it for the future 
vision :

* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding 
contions


We can create the plugins directory, and keep specialpurpose on a 
first step and move step by step each component present.


I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not download 
from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt

 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache 
ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/


Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your 
understanding of

it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned 
above

to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like 
install,

uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a 
component
if it does not exist in component-load.xml and would not even compile 
it.

So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core 
applications (and

reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this 
feature

I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for 
the
existing components and at the same time a general purpose plugin 
system.
We might even have a task like say "updatePlugin" in the future and 
it is

also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should 
definitely

tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly 
needed
to protect the core framework and applications and to provide an 
eco-system

around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :


the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model


Sorry, I have noticed I have the bad tendency of using the word
"introduced" instead of "put" or "add" (due to "introduire" false 
friend in

French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Taher Alkhateeb

Hi Nicolas,

Actually as I was discussing this with Jacques in one of the JIRAs he
mentioned something which I found very interesting:

If we create a full plugin API for creating a new plugin from templates and
we provide everything necessary for updating then perhaps hot-deploy is
even not that necessary anymore! it could simply be replaced with ./gradlew
installPlugin -PpluginName=thePluginExistingInFolder.

Also .. a lot of customization can be done with flags. So using your
example we can perhaps say something like:

./gradlew installPlugin -PpluginName=birt -Prepository=org.apache.ofbiz
or
./gradlew installPlugin -PpluginName=MyPlugin -Prepository=local
or
./gradlew installPlugin -PpluginName=commercialPlugin
-Prepository=com.someCompany

first one is default which is official OFBiz plugin, second one is local
file system, third one is commercial plugin for a company. Also we can
define a task in every plugin called "installDependencies" or something
like that which checks for dependent plugins and install them.

We can go crazy with this :) A lot of ideas are ringing in my head.

Taher Alkhateeb

On Friday, 22 July 2016, Nicolas Malin  wrote:

> Hi,
>
> Taher I like you proposal, and I wish to add some complement :)
>
> hot-deploy is to manage specific customer site component with the business
> logic specific to each, Apache OFBiz can help to prepare this but do not
> more (I will like to have this as best practice)
>
> I agree to add a new directory plugins and structure it for the future
> vision :
> * add capacity to download a plugin from the asf repo
> * support extension to download from a third plateform (like the
> /etc/apt/source.list on debian)
> * manage namespace and as you said dependencies. Need give some coding
> contions
>
> We can create the plugins directory, and keep specialpurpose on a first
> step and move step by step each component present.
>
> I imagine a process like this :
> * ./gradlew installPlugin org.apache.ofbiz.framework.birt :
>  -> check if birt is present on the plugins directory, if not download
> from
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
>  -> enable it on component-load
>  -> compile, load init date and run init service
>
> When you run ./gradlew installAllPlugin :
> * Realize installPlugin on all know plugins, with the official apache
> ofbiz release, only plugins present on
> svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/
>
> Nicolas
>
> Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
>
>> Hi Pierre, all,
>>
>> I think perhaps my proposal was short and therefore your understanding of
>> it is a bit different than what I had in mind. So I list below more
>> specifically what I mean about each point from the ones you mentioned
>> above
>> to further fine-tune the discussion.
>>
>> - The difference between createComponent and createPlugin is that the
>> plugin resides in /plugins instead of hot-deploy and added to
>> component-load.xml and also contains a build.gradle file designed
>> specifically for plugins. This script contains standard tasks like
>> install,
>> uninstall, perhaps even upgrade. The magic work for plugins will be in
>> their build scripts to integrate tightly with OFBiz.
>>
>> - The activate/deactivate tasks are just a little convenience tasks that
>> add/remove components to the component-load.xml instead of editing it by
>> hand so it is just using what exists. Gradle completely ignores a
>> component
>> if it does not exist in component-load.xml and would not even compile it.
>> So you can think of this as just providing more ease to the end-user,
>> similar to your suggestion with the createComponent.
>>
>> - The install/uninstall tasks are not just a copy-paste of folders. It
>> actually executes business logic (optionally) for any plugin author who
>> wishes to execute it (by calling specific tasks in build.gradle for that
>> plugin). For example, it might apply patches on some core applications
>> (and
>> reverse patches in case of uninstall). Now our standard plugins do not
>> touch applications or framework, but since we are introducing this feature
>> I'm trying to also combine a unified solution for all plugins (Apache
>> supported and 3rd party). So in one shot we have both ease of use for the
>> existing components and at the same time a general purpose plugin system.
>> We might even have a task like say "updatePlugin" in the future and it is
>> also possible to introduce rudimentary dependency management (Gradle is
>> really good at this).
>>
>> Finally, what to do about specialpurpose is something we should definitely
>> tackle, however what I am suggesting right now is some foundational work
>> that gives you easy choices when you need to make them, and it has the
>> added bonus of introducing a plugin system for OFBiz which is badly needed
>> to protect the core framework and applications and to provide an

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-22 Thread Nicolas Malin


Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the 
business logic specific to each, Apache OFBiz can help to prepare this 
but do not more (I will like to have this as best practice)


I agree to add a new directory plugins and structure it for the future 
vision :

* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding 
contions


We can create the plugins directory, and keep specialpurpose on a first 
step and move step by step each component present.


I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not download 
from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt

 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache 
ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/


Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications (and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly needed
to protect the core framework and applications and to provide an eco-system
around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :


the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model


Sorry, I have noticed I have the bad tendency of using the word
"introduced" instead of "put" or "add" (due to "introduire" false friend in
French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Taher Alkhateeb

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications (and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly needed
to protect the core framework and applications and to provide an eco-system
around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :
>
>> the graph needs to be checked/amended to possibly remove components
>> dependencies only introduced by the data model
>>
> Sorry, I have noticed I have the bad tendency of using the word
> "introduced" instead of "put" or "add" (due to "introduire" false friend in
> French) please replace for me when you see it, thanks! :)
> Here the right word would have been "due to" instead of "introduced by"
>
> Jacques
>
> PS: http://www.etymonline.com/index.php?term=introduction
>
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Jacques Le Roux


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :
the graph needs to be checked/amended to possibly remove components  dependencies only introduced by the data model 
Sorry, I have noticed I have the bad tendency of using the word "introduced" instead of "put" or "add" (due to "introduire" false friend in French) 
please replace for me when you see it, thanks! :)

Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Jacques Le Roux

Thanks Ron,

To All, note that, as mentioned in my last comment
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies#comment-thread-61331450,

the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model

Jacques

Le 19/07/2016 à 22:20, Ron Wheeler a écrit :

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
This might need updating to clarify some of the dependencies within OFBiz and
add in the important components that are missing.

Ron

On 19/07/2016 3:19 PM, Pierre Smits wrote:

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

- We have a few components for which we don't see external libraries in
the download repo's (MavenCentral, et al). These components are:
- birt
- ebaystore
- ldap
- pos (and as a dependent: webpos

I suggest we either work on resolving the issues with the external
libraries (getting them in or work with alternatives) before next release
in, or we invoke the attic procedure for these components.

- Activating/deactivating components (any variant):
We have a mechanism that activates the components in a particular order
as defined in component-load.xml in the specialpurpose folder. And why is
that? Because there are dependencies in components in the other stacks on
components in the special purpose stack.

Specialpurpose components like:
- lucene
- bi

If components in the lower stacks are dependent on other components in this
folder, then we should solve that (before next release. Either by
duplication of code (creating containment) or by integration of the
functionalities of the particular specialpurpose components into the
component(s) at the lower level.

When we have containment, the adopter can - as a suggestion - move the
component from special purpose to hot-deploy and after a rebuild it works.
If he doesn't want the component, he can delete from the hot-deploy
component. We don't need a hammer for that.

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

This is where it went wrong with the r13.7 fiasco. They were not in the
releases. Now if we want to revisit that discussion again, then we should
start a new thread. And not just present opposing viewpoints regarding
workload on the contributor with privileges, but start working towards an
acceptable compromise.

So looking at the suggestions made by Taher:

1. new task createPlugin:
A createPlugin task needs to provide the same skeleton as the
createComponent task, but delivers the component into the specialpurpose
folder (this is what I understand).
More information needs to be provided before the added value to the
OFBiz community can be established, especially regarding who will use this
and what would the difference be compared to createComponent.
2. New task installPlugin (plus variants)
Since we not have a true hot-deployment solution, installing components
is as simple as copying from one location to another. The build process
needs to be run and data (seed at least needs to be loaded, followed by a
start command before the component can be used by an OFBiz user.

I would see (some minor) added value when this task would accept a uri
(file location, or download page of a website, or ) and then would
download from that location and deploy it in the hot-deploy component (as a
convenience for DEV and OPS - for OPS in CD processes). Does the adopter
need this hammer for something as simple as copy/paste?
3. New task activatePlugin
We don't have a hot-deployment solution that would benefit from such.
Each activation requires a restart. I see little added value in this
solution - what at first sight appears to be complex - to just adjust the
component-load.xml file in the specialpurpose folder. Again: does the
adopter need this hammer?
4. New task uninstallPlugin (plus variants)
Delete from folder works just as fine.

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Ron Wheeler

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
This might need updating to clarify some of the dependencies within
OFBiz and add in the important components that are missing.

Ron

On 19/07/2016 3:19 PM, Pierre Smits wrote:

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

- We have a few components for which we don't see external libraries in
the download repo's (MavenCentral, et al). These components are:
- birt
- ebaystore
- ldap
- pos (and as a dependent: webpos

I suggest we either work on resolving the issues with the external
libraries (getting them in or work with alternatives) before next release
in, or we invoke the attic procedure for these components.

Specialpurpose components like:
- lucene
- bi

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

So looking at the suggestions made by Taher:

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Pierre Smits

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

   - We have a few components for which we don't see external libraries in
   the download repo's (MavenCentral, et al). These components are:
   - birt
  - ebaystore
  - ldap
  - pos (and as a dependent: webpos

  I suggest we either work on resolving the issues with the external
  libraries (getting them in or work with alternatives) before next release
  in, or we invoke the attic procedure for these components.

  - Activating/deactivating components (any variant):
   We have a mechanism that activates the components in a particular order
   as defined in component-load.xml in the specialpurpose folder. And why is
   that? Because there are dependencies in components in the other stacks on
   components in the special purpose stack.

   Specialpurpose components like:
  - lucene
  - bi

If components in the lower stacks are dependent on other components in this
folder, then we should solve that (before next release. Either by
duplication of code (creating containment) or by integration of the
functionalities of the particular specialpurpose components into the
component(s) at the lower level.

When we have containment, the adopter can - as a suggestion - move the
component from special purpose to hot-deploy and after a rebuild it works.
If he doesn't want the component, he can delete from the hot-deploy
component. We don't need a hammer for that.

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

This is where it went wrong with the r13.7 fiasco. They were not in the
releases. Now if we want to revisit that discussion again, then we should
start a new thread. And not just present opposing viewpoints regarding
workload on the contributor with privileges, but start working towards an
acceptable compromise.

So looking at the suggestions made by Taher:

   1. new task createPlugin:
   A createPlugin task needs to provide the same skeleton as the
   createComponent task, but delivers the component into the specialpurpose
   folder (this is what I understand).
   More information needs to be provided before the added value to the
   OFBiz community can be established, especially regarding who will use this
   and what would the difference be compared to createComponent.
   2. New task installPlugin (plus variants)
   Since we not have a true hot-deployment solution, installing components
   is as simple as copying from one location to another. The build process
   needs to be run and data (seed at least needs to be loaded, followed by a
   start command before the component can be used by an OFBiz user.

   I would see (some minor) added value when this task would accept a uri
   (file location, or download page of a website, or ) and then would
   download from that location and deploy it in the hot-deploy component (as a
   convenience for DEV and OPS - for OPS in CD processes). Does the adopter
   need this hammer for something as simple as copy/paste?
   3. New task activatePlugin
   We don't have a hot-deployment solution that would benefit from such.
   Each activation requires a restart. I see little added value in this
   solution - what at first sight appears to be complex - to just adjust the
   component-load.xml file in the specialpurpose folder. Again: does the
   adopter need this hammer?
   4. New task uninstallPlugin (plus variants)
   Delete from folder works just as fine.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb  wrote:

> Hello Everyone,
>
> As you all know, we are still faced with the issue of releasing OFBiz
> without binary packages. Furthermore, we are still stuck with taking a
> decision on the specialpurpose components and how to move forward with
> them.
>
> Therefore, I propose the following action points.
>
> - rename specialpurpose to plugins
> - Introduce the following tasks to the build system:
>   1 - createPlugin: creates a new plugin based on a template very similar
> to createComponent
>   2 - installPlugin: if a plugin comes with a build script that has an
> "install" task, then that task would execute. The task could contain any
> business logic that the author of the plugin wants to run.
>   3 - uninstallPlugin: if a plugin comes with a build script that has an
> "uninstall" task, then the that task would execute. The task could contain
> any business logic that the author of the plugin wants to run
>   4 - activatePlugin: if a plugin is not already added to
> component-load.xml in /plugins, then add it to it.
>   5 - deactivatePlugin: remove a plugin from component-load.xml if it
> exists in it.
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Taher Alkhateeb

Hello Everyone,

As you all know, we are still faced with the issue of releasing OFBiz
without binary packages. Furthermore, we are still stuck with taking a
decision on the specialpurpose components and how to move forward with them.

Therefore, I propose the following action points.

- rename specialpurpose to plugins
- Introduce the following tasks to the build system:
  1 - createPlugin: creates a new plugin based on a template very similar
to createComponent
  2 - installPlugin: if a plugin comes with a build script that has an
"install" task, then that task would execute. The task could contain any
business logic that the author of the plugin wants to run.
  3 - uninstallPlugin: if a plugin comes with a build script that has an
"uninstall" task, then the that task would execute. The task could contain
any business logic that the author of the plugin wants to run
  4 - activatePlugin: if a plugin is not already added to
component-load.xml in /plugins, then add it to it.
  5 - deactivatePlugin: remove a plugin from component-load.xml if it
exists in it.
  6 - activateAllPlugins: A convenience task to activate all plugins that
exist in /plugins
  7 - installAllPlugins: A convenience task to install all plugins that
exist in /plugins
- By default, installPlugin activates it.
- By default, uninstallPlugin deactivates it.

The above solution would give us a choice in taking whatever direction we
want. If we want to activate the plugins then we can, if we want to
deactivate them then we can, if we want to deactivate them but maintain
them, then individual developers would issue the below command:

./gradlew cleanAll activateAllPlugins loadDefault testIntegration

I'm not suggesting we will deactivate anything, I'm just stating that we
will have choices which is a good thing and we can move forward with this
lingering issue.

What is your opinion?

Taher Alkhateeb

On Thu, Jul 14, 2016 at 7:00 PM, Pierre Smits 
wrote:

> Ahh. I found where they were hidden in the component, with the help of [1].
>
> [1]
>
> https://issues.apache.org/jira/browse/OFBIZ-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356955#comment-15356955
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jul 14, 2016 at 4:49 PM, Pierre Smits 
> wrote:
>
> > As I am a user of the cmssite I did have a look at what external
> libraries
> > are included in that component. I have found none. Not in trunk, not in
> any
> > of the older release branches.
> >
> > Are we sure that this then needs to be disabled?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Thu, Jul 14, 2016 at 4:43 PM, Pierre Smits 
> > wrote:
> >
> >> I can live with that.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM 
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Thu, Jul 14, 2016 at 4:30 PM, Jacopo Cappellato <
> >> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>
> >>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
> >>> wrote:
> >>>
> >>> > Hi Sharan,
> >>> >
> >>> > I guess all accepted proposals can now be transformed into JIRA
> >>> issues, for
> >>> > follow-up and tracking purposes.
> >>> >
> >>> > Also, with respect to the failing components) I suggest that we
> >>> postpone
> >>> > the ultimate decision of activation/deactivation until the moment of
> >>> > cutting a release. Until then, contributors can work on those issues,
> >>> and
> >>> > if they can't resolve the issues by the time the decision needs to be
> >>> taken
> >>> > we know what to deactivate precisely.
> >>> >
> >>>
> >>> I suggest the opposite :-) if we disable them sooner than later
> >>> contributors will be more aware of the work required and there be less
> >>> surprises when they will be excluded from releases; disabling them
> sooner
> >>> would probably increase the chances of fixing them because it will
> catch
> >>> attention; if otherwise no one will care about them being disabled it
> >>> could
> >>> be an indicator that there is not enough interest.
> >>>
> >>> Jacopo
> >>>
> >>>
> >>>
> >>> > Best regards,
> >>> >
> >>> >
> >>> > Pierre Smits
> >>> >
> >>> > ORRTIZ.COM 
> >>> > OFBiz based solutions & services
> >>> >
> >>> > OFBiz Extensions Marketplace
> >>> > http://oem.ofbizci.net/oci-2/
> >>> >
> >>> > On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
> >>> > wrote:
> >>> >
> >>> > > Hi Everyone
> >>> > >
> >>> > > Thanks responding to these 3 proposals. Based on your feedback and
> >>> > > comments we can move ahead with 2 of

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Pierre Smits

Ahh. I found where they were hidden in the component, with the help of [1].

[1]
https://issues.apache.org/jira/browse/OFBIZ-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356955#comment-15356955

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jul 14, 2016 at 4:49 PM, Pierre Smits 
wrote:

> As I am a user of the cmssite I did have a look at what external libraries
> are included in that component. I have found none. Not in trunk, not in any
> of the older release branches.
>
> Are we sure that this then needs to be disabled?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jul 14, 2016 at 4:43 PM, Pierre Smits 
> wrote:
>
>> I can live with that.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Thu, Jul 14, 2016 at 4:30 PM, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>>
>>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
>>> wrote:
>>>
>>> > Hi Sharan,
>>> >
>>> > I guess all accepted proposals can now be transformed into JIRA
>>> issues, for
>>> > follow-up and tracking purposes.
>>> >
>>> > Also, with respect to the failing components) I suggest that we
>>> postpone
>>> > the ultimate decision of activation/deactivation until the moment of
>>> > cutting a release. Until then, contributors can work on those issues,
>>> and
>>> > if they can't resolve the issues by the time the decision needs to be
>>> taken
>>> > we know what to deactivate precisely.
>>> >
>>>
>>> I suggest the opposite :-) if we disable them sooner than later
>>> contributors will be more aware of the work required and there be less
>>> surprises when they will be excluded from releases; disabling them sooner
>>> would probably increase the chances of fixing them because it will catch
>>> attention; if otherwise no one will care about them being disabled it
>>> could
>>> be an indicator that there is not enough interest.
>>>
>>> Jacopo
>>>
>>>
>>>
>>> > Best regards,
>>> >
>>> >
>>> > Pierre Smits
>>> >
>>> > ORRTIZ.COM 
>>> > OFBiz based solutions & services
>>> >
>>> > OFBiz Extensions Marketplace
>>> > http://oem.ofbizci.net/oci-2/
>>> >
>>> > On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
>>> > wrote:
>>> >
>>> > > Hi Everyone
>>> > >
>>> > > Thanks responding to these 3 proposals. Based on your feedback and
>>> > > comments we can move ahead with 2 of these for the changes to the
>>> > directory
>>> > > structure for java and the renaming of specialpurpose to 'plugins'
>>> > >
>>> > > For the third, Pierre highlighted that he was against this proposal
>>> so we
>>> > > won't be deactivating the all the specialpurpose components by
>>> default.
>>> > >
>>> > > However as mentioned previously, we are having library migration
>>> problems
>>> > > with some of the components so we can only activate the ones that
>>> don't
>>> > > have any issues; the others will not be activated and will need
>>> > additional
>>> > > work to manage the changeover to remote libraries and the resolution
>>> of
>>> > any
>>> > > startup conflicts.
>>> > >
>>> > > (Just for information the components with issues are BIRT, Ebaystore,
>>> > > ldap, POS and cmssite.)
>>> > >
>>> > > We are also looking for help with these migrations so if you would
>>> like
>>> > to
>>> > > help out fixing the issues with these specialpurpose components then
>>> > please
>>> > > let me know.
>>> > >
>>> > > Thanks
>>> > > Sharan
>>> > >
>>> > > On 2016-07-11 17:56 (+0200), Sharan-F  wrote:
>>> > > > Hi Everyone
>>> > > >
>>> > > > Another update on the task list for moving forward with Gradle and
>>> the
>>> > > > Trunk. We would also like to get community feedback and comments on
>>> > each
>>> > > of
>>> > > > the following 3 proposals:
>>> > > >
>>> > > > Task 1 “Replace all the current jars in OFBiz with appropriate
>>> remote
>>> > > > libraries from a download repository
>>> > > >
>>> > >
>>> >
>>> --
>>> > > > The work to replace the jars is ongoing and we have already
>>> removed 169
>>> > > of
>>> > > > them. These libraries will now be automatically downloaded by
>>> Gradle.
>>> > > Work
>>> > > > will continue to remove the remaining files. As we are working
>>> through,
>>> > > we
>>> > > > are finding library migration issues with some of the
>>> specialpurpose
>>> > > > components so would like *to propose to deactivate all
>>> specialpurpose
>>> > > > components by

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Pierre Smits

As I am a user of the cmssite I did have a look at what external libraries
are included in that component. I have found none. Not in trunk, not in any
of the older release branches.

Are we sure that this then needs to be disabled?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jul 14, 2016 at 4:43 PM, Pierre Smits 
wrote:

> I can live with that.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jul 14, 2016 at 4:30 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
>> wrote:
>>
>> > Hi Sharan,
>> >
>> > I guess all accepted proposals can now be transformed into JIRA issues,
>> for
>> > follow-up and tracking purposes.
>> >
>> > Also, with respect to the failing components) I suggest that we postpone
>> > the ultimate decision of activation/deactivation until the moment of
>> > cutting a release. Until then, contributors can work on those issues,
>> and
>> > if they can't resolve the issues by the time the decision needs to be
>> taken
>> > we know what to deactivate precisely.
>> >
>>
>> I suggest the opposite :-) if we disable them sooner than later
>> contributors will be more aware of the work required and there be less
>> surprises when they will be excluded from releases; disabling them sooner
>> would probably increase the chances of fixing them because it will catch
>> attention; if otherwise no one will care about them being disabled it
>> could
>> be an indicator that there is not enough interest.
>>
>> Jacopo
>>
>>
>>
>> > Best regards,
>> >
>> >
>> > Pierre Smits
>> >
>> > ORRTIZ.COM 
>> > OFBiz based solutions & services
>> >
>> > OFBiz Extensions Marketplace
>> > http://oem.ofbizci.net/oci-2/
>> >
>> > On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
>> > wrote:
>> >
>> > > Hi Everyone
>> > >
>> > > Thanks responding to these 3 proposals. Based on your feedback and
>> > > comments we can move ahead with 2 of these for the changes to the
>> > directory
>> > > structure for java and the renaming of specialpurpose to 'plugins'
>> > >
>> > > For the third, Pierre highlighted that he was against this proposal
>> so we
>> > > won't be deactivating the all the specialpurpose components by
>> default.
>> > >
>> > > However as mentioned previously, we are having library migration
>> problems
>> > > with some of the components so we can only activate the ones that
>> don't
>> > > have any issues; the others will not be activated and will need
>> > additional
>> > > work to manage the changeover to remote libraries and the resolution
>> of
>> > any
>> > > startup conflicts.
>> > >
>> > > (Just for information the components with issues are BIRT, Ebaystore,
>> > > ldap, POS and cmssite.)
>> > >
>> > > We are also looking for help with these migrations so if you would
>> like
>> > to
>> > > help out fixing the issues with these specialpurpose components then
>> > please
>> > > let me know.
>> > >
>> > > Thanks
>> > > Sharan
>> > >
>> > > On 2016-07-11 17:56 (+0200), Sharan-F  wrote:
>> > > > Hi Everyone
>> > > >
>> > > > Another update on the task list for moving forward with Gradle and
>> the
>> > > > Trunk. We would also like to get community feedback and comments on
>> > each
>> > > of
>> > > > the following 3 proposals:
>> > > >
>> > > > Task 1 “Replace all the current jars in OFBiz with appropriate
>> remote
>> > > > libraries from a download repository
>> > > >
>> > >
>> >
>> --
>> > > > The work to replace the jars is ongoing and we have already removed
>> 169
>> > > of
>> > > > them. These libraries will now be automatically downloaded by
>> Gradle.
>> > > Work
>> > > > will continue to remove the remaining files. As we are working
>> through,
>> > > we
>> > > > are finding library migration issues with some of the specialpurpose
>> > > > components so would like *to propose to deactivate all
>> specialpurpose
>> > > > components by default.*
>> > > >
>> > > >
>> > > > Task 4. “ Move all java source files
>> to\u2002$component/src/main/java
>> > and
>> > > > introduce all unit tests in\u2002\u2002$component/src/test/java”
>> > > >
>> > >
>> >
>> -
>> > > > Another area we need to progress is the re-design and changing of
>> the
>> > > > directory structure so that we can separate the Java files between
>> main
>> > > and
>> > > > test. This will help us

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Pierre Smits

I can live with that.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jul 14, 2016 at 4:30 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
> wrote:
>
> > Hi Sharan,
> >
> > I guess all accepted proposals can now be transformed into JIRA issues,
> for
> > follow-up and tracking purposes.
> >
> > Also, with respect to the failing components) I suggest that we postpone
> > the ultimate decision of activation/deactivation until the moment of
> > cutting a release. Until then, contributors can work on those issues, and
> > if they can't resolve the issues by the time the decision needs to be
> taken
> > we know what to deactivate precisely.
> >
>
> I suggest the opposite :-) if we disable them sooner than later
> contributors will be more aware of the work required and there be less
> surprises when they will be excluded from releases; disabling them sooner
> would probably increase the chances of fixing them because it will catch
> attention; if otherwise no one will care about them being disabled it could
> be an indicator that there is not enough interest.
>
> Jacopo
>
>
>
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
> > wrote:
> >
> > > Hi Everyone
> > >
> > > Thanks responding to these 3 proposals. Based on your feedback and
> > > comments we can move ahead with 2 of these for the changes to the
> > directory
> > > structure for java and the renaming of specialpurpose to 'plugins'
> > >
> > > For the third, Pierre highlighted that he was against this proposal so
> we
> > > won't be deactivating the all the specialpurpose components by default.
> > >
> > > However as mentioned previously, we are having library migration
> problems
> > > with some of the components so we can only activate the ones that don't
> > > have any issues; the others will not be activated and will need
> > additional
> > > work to manage the changeover to remote libraries and the resolution of
> > any
> > > startup conflicts.
> > >
> > > (Just for information the components with issues are BIRT, Ebaystore,
> > > ldap, POS and cmssite.)
> > >
> > > We are also looking for help with these migrations so if you would like
> > to
> > > help out fixing the issues with these specialpurpose components then
> > please
> > > let me know.
> > >
> > > Thanks
> > > Sharan
> > >
> > > On 2016-07-11 17:56 (+0200), Sharan-F  wrote:
> > > > Hi Everyone
> > > >
> > > > Another update on the task list for moving forward with Gradle and
> the
> > > > Trunk. We would also like to get community feedback and comments on
> > each
> > > of
> > > > the following 3 proposals:
> > > >
> > > > Task 1 “Replace all the current jars in OFBiz with appropriate remote
> > > > libraries from a download repository
> > > >
> > >
> >
> --
> > > > The work to replace the jars is ongoing and we have already removed
> 169
> > > of
> > > > them. These libraries will now be automatically downloaded by Gradle.
> > > Work
> > > > will continue to remove the remaining files. As we are working
> through,
> > > we
> > > > are finding library migration issues with some of the specialpurpose
> > > > components so would like *to propose to deactivate all specialpurpose
> > > > components by default.*
> > > >
> > > >
> > > > Task 4. “ Move all java source files to\u2002$component/src/main/java
> > and
> > > > introduce all unit tests in\u2002\u2002$component/src/test/java”
> > > >
> > >
> >
> -
> > > > Another area we need to progress is the re-design and changing of the
> > > > directory structure so that we can separate the Java files between
> main
> > > and
> > > > test. This will help us simplify the implementation of a testing
> > > framework.
> > > > *The proposal for the directory structure is as follows:
> > > >
> > > >componentname/src/main/java
> > > >componentname/src/test/java*
> > > >
> > > >
> > > > Task 10. “Propose the renaming specialpurpose to plugins or such an
> > > > appropriate name for clarity”
> > > >
> > >
> >
> -
> > > > We would like * to propose changing the name of the specialpurpose
> > > folder to
> > > > 'plugins'*
> > > >
> > > > These are the 3 areas we would

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Jacopo Cappellato

On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
wrote:

> Hi Sharan,
>
> I guess all accepted proposals can now be transformed into JIRA issues, for
> follow-up and tracking purposes.
>
> Also, with respect to the failing components) I suggest that we postpone
> the ultimate decision of activation/deactivation until the moment of
> cutting a release. Until then, contributors can work on those issues, and
> if they can't resolve the issues by the time the decision needs to be taken
> we know what to deactivate precisely.
>

I suggest the opposite :-) if we disable them sooner than later
contributors will be more aware of the work required and there be less
surprises when they will be excluded from releases; disabling them sooner
would probably increase the chances of fixing them because it will catch
attention; if otherwise no one will care about them being disabled it could
be an indicator that there is not enough interest.

Jacopo



> Best regards,
>
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
> wrote:
>
> > Hi Everyone
> >
> > Thanks responding to these 3 proposals. Based on your feedback and
> > comments we can move ahead with 2 of these for the changes to the
> directory
> > structure for java and the renaming of specialpurpose to 'plugins'
> >
> > For the third, Pierre highlighted that he was against this proposal so we
> > won't be deactivating the all the specialpurpose components by default.
> >
> > However as mentioned previously, we are having library migration problems
> > with some of the components so we can only activate the ones that don't
> > have any issues; the others will not be activated and will need
> additional
> > work to manage the changeover to remote libraries and the resolution of
> any
> > startup conflicts.
> >
> > (Just for information the components with issues are BIRT, Ebaystore,
> > ldap, POS and cmssite.)
> >
> > We are also looking for help with these migrations so if you would like
> to
> > help out fixing the issues with these specialpurpose components then
> please
> > let me know.
> >
> > Thanks
> > Sharan
> >
> > On 2016-07-11 17:56 (+0200), Sharan-F  wrote:
> > > Hi Everyone
> > >
> > > Another update on the task list for moving forward with Gradle and the
> > > Trunk. We would also like to get community feedback and comments on
> each
> > of
> > > the following 3 proposals:
> > >
> > > Task 1 “Replace all the current jars in OFBiz with appropriate remote
> > > libraries from a download repository
> > >
> >
> --
> > > The work to replace the jars is ongoing and we have already removed 169
> > of
> > > them. These libraries will now be automatically downloaded by Gradle.
> > Work
> > > will continue to remove the remaining files. As we are working through,
> > we
> > > are finding library migration issues with some of the specialpurpose
> > > components so would like *to propose to deactivate all specialpurpose
> > > components by default.*
> > >
> > >
> > > Task 4. “ Move all java source files to\u2002$component/src/main/java
> and
> > > introduce all unit tests in\u2002\u2002$component/src/test/java”
> > >
> >
> -
> > > Another area we need to progress is the re-design and changing of the
> > > directory structure so that we can separate the Java files between main
> > and
> > > test. This will help us simplify the implementation of a testing
> > framework.
> > > *The proposal for the directory structure is as follows:
> > >
> > >componentname/src/main/java
> > >componentname/src/test/java*
> > >
> > >
> > > Task 10. “Propose the renaming specialpurpose to plugins or such an
> > > appropriate name for clarity”
> > >
> >
> -
> > > We would like * to propose changing the name of the specialpurpose
> > folder to
> > > 'plugins'*
> > >
> > > These are the 3 areas we would like to progress so please feel free to
> > > respond with your feedback and comments.
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> > > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> > >
> >
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Pierre Smits

Hi Sharan,

I guess all accepted proposals can now be transformed into JIRA issues, for
follow-up and tracking purposes.

Also, with respect to the failing components) I suggest that we postpone
the ultimate decision of activation/deactivation until the moment of
cutting a release. Until then, contributors can work on those issues, and
if they can't resolve the issues by the time the decision needs to be taken
we know what to deactivate precisely.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga  wrote:

> Hi Everyone
>
> Thanks responding to these 3 proposals. Based on your feedback and
> comments we can move ahead with 2 of these for the changes to the directory
> structure for java and the renaming of specialpurpose to 'plugins'
>
> For the third, Pierre highlighted that he was against this proposal so we
> won't be deactivating the all the specialpurpose components by default.
>
> However as mentioned previously, we are having library migration problems
> with some of the components so we can only activate the ones that don't
> have any issues; the others will not be activated and will need additional
> work to manage the changeover to remote libraries and the resolution of any
> startup conflicts.
>
> (Just for information the components with issues are BIRT, Ebaystore,
> ldap, POS and cmssite.)
>
> We are also looking for help with these migrations so if you would like to
> help out fixing the issues with these specialpurpose components then please
> let me know.
>
> Thanks
> Sharan
>
> On 2016-07-11 17:56 (+0200), Sharan-F  wrote:
> > Hi Everyone
> >
> > Another update on the task list for moving forward with Gradle and the
> > Trunk. We would also like to get community feedback and comments on each
> of
> > the following 3 proposals:
> >
> > Task 1 “Replace all the current jars in OFBiz with appropriate remote
> > libraries from a download repository
> >
> --
> > The work to replace the jars is ongoing and we have already removed 169
> of
> > them. These libraries will now be automatically downloaded by Gradle.
> Work
> > will continue to remove the remaining files. As we are working through,
> we
> > are finding library migration issues with some of the specialpurpose
> > components so would like *to propose to deactivate all specialpurpose
> > components by default.*
> >
> >
> > Task 4. “ Move all java source files to\u2002$component/src/main/java and
> > introduce all unit tests in\u2002\u2002$component/src/test/java”
> >
> -
> > Another area we need to progress is the re-design and changing of the
> > directory structure so that we can separate the Java files between main
> and
> > test. This will help us simplify the implementation of a testing
> framework.
> > *The proposal for the directory structure is as follows:
> >
> >componentname/src/main/java
> >componentname/src/test/java*
> >
> >
> > Task 10. “Propose the renaming specialpurpose to plugins or such an
> > appropriate name for clarity”
> >
> -
> > We would like * to propose changing the name of the specialpurpose
> folder to
> > 'plugins'*
> >
> > These are the 3 areas we would like to progress so please feel free to
> > respond with your feedback and comments.
> >
> > Thanks
> > Sharan
> >
> >
> >
> >
> > --
> > View this message in context:
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> >
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-14 Thread Sharan Foga

Hi Everyone

Thanks responding to these 3 proposals. Based on your feedback and comments we 
can move ahead with 2 of these for the changes to the directory structure for 
java and the renaming of specialpurpose to 'plugins'

For the third, Pierre highlighted that he was against this proposal so we won't 
be deactivating the all the specialpurpose components by default. 

However as mentioned previously, we are having library migration problems with 
some of the components so we can only activate the ones that don't have any 
issues; the others will not be activated and will need additional work to 
manage the changeover to remote libraries and the resolution of any startup 
conflicts. 

(Just for information the components with issues are BIRT, Ebaystore, ldap, POS 
and cmssite.)

We are also looking for help with these migrations so if you would like to help 
out fixing the issues with these specialpurpose components then please let me 
know.

Thanks
Sharan

On 2016-07-11 17:56 (+0200), Sharan-F  wrote: 
> Hi Everyone
> 
> Another update on the task list for moving forward with Gradle and the
> Trunk. We would also like to get community feedback and comments on each of
> the following 3 proposals:
> 
> Task 1 âReplace all the current jars in OFBiz with appropriate remote
> libraries from a download repository
> --
> The work to replace the jars is ongoing and we have already removed 169 of
> them. These libraries will now be automatically downloaded by Gradle. Work
> will continue to remove the remaining files. As we are working through, we
> are finding library migration issues with some of the specialpurpose
> components so would like *to propose to deactivate all specialpurpose
> components by default.*
> 
> 
> Task 4. â Move all java source files to\u2002$component/src/main/java and
> introduce all unit tests in\u2002\u2002$component/src/test/javaâ
> -
> Another area we need to progress is the re-design and changing of the
> directory structure so that we can separate the Java files between main and
> test. This will help us simplify the implementation of a testing framework.
> *The proposal for the directory structure is as follows:
> 
>componentname/src/main/java
>componentname/src/test/java*
> 
> 
> Task 10. âPropose the renaming specialpurpose to plugins or such an
> appropriate name for clarityâ
> -
> We would like * to propose changing the name of the specialpurpose folder to
> 'plugins'*
> 
> These are the 3 areas we would like to progress so please feel free to
> respond with your feedback and comments.
> 
> Thanks
> Sharan
> 
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-13 Thread Pierre Smits

For now,I can't agree with the proposal to deactivate all special-purpose
components by default, merely because we can't seem to be able to work
around the inability to define download specifications for certain external
libraries in specific components.

Deactivations by default will lead to the same troubles we had with the
convenience packages of the 13.07 releases.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jul 13, 2016 at 12:37 PM, Divesh Dutta <
divesh.du...@hotwaxsystems.com> wrote:

> I agree with all the proposals. Also I like the idea of making all the
> special purpose components to plugins which will be deactivated by default
> and you can active them.
>
> Thanks
> --
> Divesh Dutta.
>
> On Wed, Jul 13, 2016 at 12:55 PM, Sharan Foga 
> wrote:
>
> > Hi All
> >
> > Thanks Taher for your feedback. As I havent had many responses to this
> > post and we need to move forward as quickly as possible I'm going to
> change
> > each of these proposals to lazy consensus. This means if you are against
> > any of them then please speak up.
> >
> > If I haven't had any more responses by this time tomorrow – we'll plan to
> > go ahead with each of them.
> >
> > Thanks
> > Sharan
> >
> > On 2016-07-11 20:01 (+0200), Taher Alkhateeb  >
> > wrote:
> > > Hi Sharan and everyone.
> > >
> > > I propose in complement and summarizing your points the following:
> > >
> > > 1- deactivate by default all specialpurpose components. Possibly with a
> > > convenience task called activateAllPlugins
> > > 2- redesign the directory structure to separate main classes from test
> > > classes
> > > 3- rename the specialpurpose folder to plugins
> > >
> > > The migration of remote libs is already on its way.
> > >
> > > Taher Alkhateeb
> > > On Jul 11, 2016 7:38 PM, "Sharan-F"  wrote:
> > >
> > > Hi Everyone
> > >
> > > Another update on the task list for moving forward with Gradle and the
> > > Trunk. We would also like to get community feedback and comments on
> each
> > of
> > > the following 3 proposals:
> > >
> > > Task 1 “Replace all the current jars in OFBiz with appropriate remote
> > > libraries from a download repository
> > >
> >
> --
> > > The work to replace the jars is ongoing and we have already removed 169
> > of
> > > them. These libraries will now be automatically downloaded by Gradle.
> > Work
> > > will continue to remove the remaining files. As we are working through,
> > we
> > > are finding library migration issues with some of the specialpurpose
> > > components so would like *to propose to deactivate all specialpurpose
> > > components by default.*
> > >
> > >
> > > Task 4. “ Move all java source files to\u2002$component/src/main/java
> and
> > > introduce all unit tests in\u2002\u2002$component/src/test/java”
> > >
> >
> -
> > > Another area we need to progress is the re-design and changing of the
> > > directory structure so that we can separate the Java files between main
> > and
> > > test. This will help us simplify the implementation of a testing
> > framework.
> > > *The proposal for the directory structure is as follows:
> > >
> > >componentname/src/main/java
> > >componentname/src/test/java*
> > >
> > >
> > > Task 10. “Propose the renaming specialpurpose to plugins or such an
> > > appropriate name for clarity”
> > >
> >
> -
> > > We would like * to propose changing the name of the specialpurpose
> > folder to
> > > 'plugins'*
> > >
> > > These are the 3 areas we would like to progress so please feel free to
> > > respond with your feedback and comments.
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> > > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> > >
> >
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-13 Thread Divesh Dutta

I agree with all the proposals. Also I like the idea of making all the
special purpose components to plugins which will be deactivated by default
and you can active them.

Thanks
--
Divesh Dutta.

On Wed, Jul 13, 2016 at 12:55 PM, Sharan Foga  wrote:

> Hi All
>
> Thanks Taher for your feedback. As I havent had many responses to this
> post and we need to move forward as quickly as possible I'm going to change
> each of these proposals to lazy consensus. This means if you are against
> any of them then please speak up.
>
> If I haven't had any more responses by this time tomorrow – we'll plan to
> go ahead with each of them.
>
> Thanks
> Sharan
>
> On 2016-07-11 20:01 (+0200), Taher Alkhateeb 
> wrote:
> > Hi Sharan and everyone.
> >
> > I propose in complement and summarizing your points the following:
> >
> > 1- deactivate by default all specialpurpose components. Possibly with a
> > convenience task called activateAllPlugins
> > 2- redesign the directory structure to separate main classes from test
> > classes
> > 3- rename the specialpurpose folder to plugins
> >
> > The migration of remote libs is already on its way.
> >
> > Taher Alkhateeb
> > On Jul 11, 2016 7:38 PM, "Sharan-F"  wrote:
> >
> > Hi Everyone
> >
> > Another update on the task list for moving forward with Gradle and the
> > Trunk. We would also like to get community feedback and comments on each
> of
> > the following 3 proposals:
> >
> > Task 1 “Replace all the current jars in OFBiz with appropriate remote
> > libraries from a download repository
> >
> --
> > The work to replace the jars is ongoing and we have already removed 169
> of
> > them. These libraries will now be automatically downloaded by Gradle.
> Work
> > will continue to remove the remaining files. As we are working through,
> we
> > are finding library migration issues with some of the specialpurpose
> > components so would like *to propose to deactivate all specialpurpose
> > components by default.*
> >
> >
> > Task 4. “ Move all java source files to\u2002$component/src/main/java and
> > introduce all unit tests in\u2002\u2002$component/src/test/java”
> >
> -
> > Another area we need to progress is the re-design and changing of the
> > directory structure so that we can separate the Java files between main
> and
> > test. This will help us simplify the implementation of a testing
> framework.
> > *The proposal for the directory structure is as follows:
> >
> >componentname/src/main/java
> >componentname/src/test/java*
> >
> >
> > Task 10. “Propose the renaming specialpurpose to plugins or such an
> > appropriate name for clarity”
> >
> -
> > We would like * to propose changing the name of the specialpurpose
> folder to
> > 'plugins'*
> >
> > These are the 3 areas we would like to progress so please feel free to
> > respond with your feedback and comments.
> >
> > Thanks
> > Sharan
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> >
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-13 Thread Sharan Foga

Hi All

Thanks Taher for your feedback. As I havent had many responses to this post and 
we need to move forward as quickly as possible I'm going to change each of 
these proposals to lazy consensus. This means if you are against any of them 
then please speak up.

If I haven't had any more responses by this time tomorrow â we'll plan to go 
ahead with each of them.

Thanks
Sharan

On 2016-07-11 20:01 (+0200), Taher Alkhateeb  
wrote: 
> Hi Sharan and everyone.
> 
> I propose in complement and summarizing your points the following:
> 
> 1- deactivate by default all specialpurpose components. Possibly with a
> convenience task called activateAllPlugins
> 2- redesign the directory structure to separate main classes from test
> classes
> 3- rename the specialpurpose folder to plugins
> 
> The migration of remote libs is already on its way.
> 
> Taher Alkhateeb
> On Jul 11, 2016 7:38 PM, "Sharan-F"  wrote:
> 
> Hi Everyone
> 
> Another update on the task list for moving forward with Gradle and the
> Trunk. We would also like to get community feedback and comments on each of
> the following 3 proposals:
> 
> Task 1 âReplace all the current jars in OFBiz with appropriate remote
> libraries from a download repository
> --
> The work to replace the jars is ongoing and we have already removed 169 of
> them. These libraries will now be automatically downloaded by Gradle. Work
> will continue to remove the remaining files. As we are working through, we
> are finding library migration issues with some of the specialpurpose
> components so would like *to propose to deactivate all specialpurpose
> components by default.*
> 
> 
> Task 4. â Move all java source files to\u2002$component/src/main/java and
> introduce all unit tests in\u2002\u2002$component/src/test/javaâ
> -
> Another area we need to progress is the re-design and changing of the
> directory structure so that we can separate the Java files between main and
> test. This will help us simplify the implementation of a testing framework.
> *The proposal for the directory structure is as follows:
> 
>componentname/src/main/java
>componentname/src/test/java*
> 
> 
> Task 10. âPropose the renaming specialpurpose to plugins or such an
> appropriate name for clarityâ
> -
> We would like * to propose changing the name of the specialpurpose folder to
> 'plugins'*
> 
> These are the 3 areas we would like to progress so please feel free to
> respond with your feedback and comments.
> 
> Thanks
> Sharan
> 
> 
> 
> 
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-11 Thread Taher Alkhateeb

Hi Sharan and everyone.

I propose in complement and summarizing your points the following:

1- deactivate by default all specialpurpose components. Possibly with a
convenience task called activateAllPlugins
2- redesign the directory structure to separate main classes from test
classes
3- rename the specialpurpose folder to plugins

The migration of remote libs is already on its way.

Taher Alkhateeb
On Jul 11, 2016 7:38 PM, "Sharan-F" wrote:

Hi Everyone

Another update on the task list for moving forward with Gradle and the
Trunk. We would also like to get community feedback and comments on each of
the following 3 proposals:

Task 1 “Replace all the current jars in OFBiz with appropriate remote
libraries from a download repository
--
The work to replace the jars is ongoing and we have already removed 169 of
them. These libraries will now be automatically downloaded by Gradle. Work
will continue to remove the remaining files. As we are working through, we
are finding library migration issues with some of the specialpurpose
components so would like *to propose to deactivate all specialpurpose
components by default.*

Task 4. “ Move all java source files to\u2002$component/src/main/java and
introduce all unit tests in\u2002\u2002$component/src/test/java”
-
Another area we need to progress is the re-design and changing of the
directory structure so that we can separate the Java files between main and
test. This will help us simplify the implementation of a testing framework.
*The proposal for the directory structure is as follows:

componentname/src/main/java
componentname/src/test/java*

Task 10. “Propose the renaming specialpurpose to plugins or such an
appropriate name for clarity”
-
We would like * to propose changing the name of the specialpurpose folder to
'plugins'*

These are the 3 areas we would like to progress so please feel free to
respond with your feedback and comments.

Thanks
Sharan

--
View this message in context:
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-11 Thread Sharan-F

Hi Everyone

Another update on the task list for moving forward with Gradle and the
Trunk. We would also like to get community feedback and comments on each of
the following 3 proposals:

componentname/src/main/java
componentname/src/test/java*

Task 10. “Propose the renaming specialpurpose to plugins or such an
appropriate name for clarity”
-
We would like * to propose changing the name of the specialpurpose folder to
'plugins'*

These are the 3 areas we would like to progress so please feel free to
respond with your feedback and comments.

Thanks
Sharan

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-05 Thread Taher Alkhateeb

Hi Sharan,

Thank you for wonderfully coordinating and organizing this project.

+1 for all points from my side.

One more thing ! I suggest that we make the specialpurpose components
(plugins!) deactivated by default! Those who are interested in a certain
plugin would issue the appropriate gradle command to activate and test them
and run them and make sure they are updated correctly with the framework.

This would be the first step towards creating the plugins eco-system. Ideas?

Taher Alkhateeb

On Tue, Jul 5, 2016 at 4:35 PM, Sharan Foga  wrote:

> Hi Everyone
>
> A brief update and also some ideas for moving forward with Gradle and the
> trunk.
>
> For those who missed it, the patch (OFBIZ-7534) to use Gradle in the trunk
> was committed to the trunk yesterday in revision 1751309.  Huge thanks to
> Taher for working so hard and also co-ordinating it. Also thanks very much
> to everyone that contributed, tested and generally gave up some of their
> time to help out.
>
> This commit is the first step in a series of things that need to be done
> to stabilise the trunk and remove the external dependencies. Once we have
> done this, we will be able to look at creating a new branch.
>
> To achieve that stabilisation,  the following is a suggested current task
> list (in no particular order) :
>
> 1. Replace all the current jars in OFBiz with appropriate remote libraries
> from a download repository (NOTE: There are currently 229 of these and work
> is progressing using a framacalc spreadsheet)
> 2. Replace all the scripts in /tools with one build.gradle file where each
> task represents the work done by a certain script
> 3. Change the buildbot to use Gradle (instead of Ant) and deactivate Ant
> 4. Move all java source files to $component/src/main/java and introduce
> all unit tests in $component/src/test/java
> 5. Design and implement the plugin system API. Ideas for things to do:
>  -  Create plugin tasks like installPlugin, activatePlugin,
> deactivatePlugin, uninstallPlugin
>  - Create a template file for a standard new plugin for developers
>  - Create a task called createPlugin which uses the above mentioned
> template file(s) for generating a plugin
> 6. Investigate how to create a plugin repository with dependencies clearly
> defined, not only on external libraries but also other plugins!
> 7. Investigate and propose a methodology for maintaining plugins and
> versioning compatibility with OFBiz.
> 8. Investigate and propose a methodology for upgrading plugins within OFBiz
> 9. Remove unnecessary build scripts (There is a list of around 60!)
> 10. Propose the renaming specialpurpose to plugins or such an appropriate
> name for clarity
>
> These are the main things that we are proposing that we focus on, so are
> happy to get any community feedback, help, comments and suggestions.
>
> Thanks
> Sharan
>

[DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-05 Thread Sharan Foga

Hi Everyone

A brief update and also some ideas for moving forward with Gradle and the trunk.

For those who missed it, the patch (OFBIZ-7534) to use Gradle in the trunk was 
committed to the trunk yesterday in revision 1751309.  Huge thanks to Taher for 
working so hard and also co-ordinating it. Also thanks very much to everyone 
that contributed, tested and generally gave up some of their time to help out.

This commit is the first step in a series of things that need to be done to 
stabilise the trunk and remove the external dependencies. Once we have done 
this, we will be able to look at creating a new branch.

To achieve that stabilisation,  the following is a suggested current task list 
(in no particular order) : 

1. Replace all the current jars in OFBiz with appropriate remote libraries from 
a download repository (NOTE: There are currently 229 of these and work is 
progressing using a framacalc spreadsheet)
2. Replace all the scripts in /tools with one build.gradle file where each task 
represents the work done by a certain script
3. Change the buildbot to use Gradle (instead of Ant) and deactivate Ant
4. Move all java source files toâ$component/src/main/java and introduce all 
unit tests inââ$component/src/test/java
5. Design and implement the plugin system API. Ideas for things to do:
 -  Create plugin tasks like installPlugin, activatePlugin, 
deactivatePlugin, uninstallPlugin
 - Create a template file for a standard new plugin for developers
 - Create a task called createPlugin which uses the above mentioned 
template file(s) for generating a plugin
6. Investigate how to create a plugin repository with dependencies clearly 
defined, not only on external libraries but also other plugins!
7. Investigate and propose a methodology for maintaining plugins and versioning 
compatibility with OFBiz.
8. Investigate and propose a methodology for upgrading plugins within OFBiz
9. Remove unnecessary build scripts (There is a list of around 60!)
10. Propose the renaming specialpurpose to plugins or such an appropriate name 
for clarity

These are the main things that we are proposing that we focus on, so are happy 
to get any community feedback, help, comments and suggestions.

Thanks
Sharan

42 matches

Mail list logo