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.
