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 <slidingfilame...@gmail.com
> 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 <pierre.sm...@gmail.com>
> 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 <pierre.sm...@gmail.com>
> > 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 <pierre.sm...@gmail.com>
> > > 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 <
> > >> jacopo.cappell...@hotwaxsystems.com> wrote:
> > >>
> > >>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits <
> pierre.sm...@gmail.com>
> > >>> 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 <
> sharan.f...@gmail.com>
> > >>> > 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 <sharan.f...@gmail.com>
> > 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.
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
