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

[Sharan-F]

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

[taher]

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 <[hidden email]> 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
>

[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:

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

[taher]

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" <[hidden email]> 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.

[Sharan-F]

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 <[hidden email]> 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" <[hidden email]> 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.
>

[Divesh Dutta-2]

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 <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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.
> >
>

[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 <http://www.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 <
[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> >
> > 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" <[hidden email]> 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.
> > >
> >
>

[Sharan-F]

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 <[hidden email]> 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.
>

[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 <http://www.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 <[hidden email]> 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 <[hidden email]> 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.
> >
>

[Jacopo Cappellato-5]

On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <[hidden email]>
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 <http://www.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 <[hidden email]>
> 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 <[hidden email]> 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.
> > >
> >
>

[Pierre Smits]

I can live with that.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.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 <
[hidden email]> wrote:

> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <[hidden email]>
> 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 <http://www.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 <[hidden email]>
> > 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 <[hidden email]> 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.
> > > >
> > >
> >
>

[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 <http://www.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 <[hidden email]>
wrote:

> I can live with that.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.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 <
> [hidden email]> wrote:
>
>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <[hidden email]>
>> 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 <http://www.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 <[hidden email]>
>> > 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 <[hidden email]> 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.
>> > > >
>> > >
>> >
>>
>
>

[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&focusedCommentId=15356955#comment-15356955

Pierre Smits

ORRTIZ.COM <http://www.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 <[hidden email]>
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 <http://www.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 <[hidden email]>
> wrote:
>
>> I can live with that.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.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 <
>> [hidden email]> wrote:
>>
>>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <[hidden email]>
>>> 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 <http://www.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 <[hidden email]>
>>> > 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 <[hidden email]> 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.
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

[taher]

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 <[hidden email]>
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&focusedCommentId=15356955#comment-15356955
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.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 <[hidden email]>
> 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 <http://www.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 <[hidden email]>
> > wrote:
> >
> >> I can live with that.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM <http://www.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 <
> >> [hidden email]> wrote:
> >>
> >>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <[hidden email]>
> >>> 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 <http://www.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 <[hidden email]>
> >>> > 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 <[hidden email]>
> 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.
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>

[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 <http://www.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 <[hidden email]
> 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.
>   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 <[hidden email]>
> 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&focusedCommentId=15356955#comment-15356955
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.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 <[hidden email]>
> > 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 <http://www.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 <[hidden email]>
> > > wrote:
> > >
> > >> I can live with that.
> > >>
> > >> Best regards,
> > >>
> > >> Pierre Smits
> > >>
> > >> ORRTIZ.COM <http://www.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 <
> > >> [hidden email]> wrote:
> > >>
> > >>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <
> [hidden email]>
> > >>> 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 <http://www.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 <
> [hidden email]>
> > >>> > 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 <[hidden email]>
> > 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.
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

[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.
>
>        - 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 <http://www.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 <[hidden email]
>> 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.
>>    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 <[hidden email]>
>> 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&focusedCommentId=15356955#comment-15356955
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.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 <[hidden email]>
>>> 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 <http://www.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 <[hidden email]>
>>>> wrote:
>>>>
>>>>> I can live with that.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> ORRTIZ.COM <http://www.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 <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <
>> [hidden email]>
>>>>>> 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 <http://www.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 <
>> [hidden email]>
>>>>>>> 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 <[hidden email]>
>>> 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.
>>>>>>>>>
>>>>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[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 <http://www.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 <[hidden email]
>>> 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.
>>>    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 <[hidden email]>
>>> 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&focusedCommentId=15356955#comment-15356955 
>>>
>>>> Pierre Smits
>>>>
>>>> ORRTIZ.COM <http://www.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 <[hidden email]>
>>>> 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 <http://www.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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> I can live with that.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> ORRTIZ.COM <http://www.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 <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <
>>> [hidden email]>
>>>>>>> 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 <http://www.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 <
>>> [hidden email]>
>>>>>>>> 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 <[hidden email]>
>>>> 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.
>>>>>>>>>>
>>>>>>
>
>

[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

[taher]

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 <
[hidden email]> 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
>
>

[Nicolas Malin-2]

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 <
> [hidden email]> 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
>>
>>