[
https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851083#comment-15851083
]
Jacques Le Roux commented on OFBIZ-9182:
----------------------------------------
OK, it clear to me now. We don't need pullPluginSource if we set a svn external
for the plugins repo.
Taher said
{quote}
There are two ways to pull a plugin from source: Either have subversion
installed on the machine and use exec
{...}
OR use an embedded subversion based on Java and hence avoid dependence on
environment.
{quote}
Actually people should not have to worry about using "exec" manually. That's
what a svn external for the plugins repo would do automatically for them,
checking out the whole plugins dir without any efforts and even noticing it.
I recap:
# People using released packages use pullPlugin to get the released plugin/s
they want (and more because of plugins interdependencies)
# People not using released packages, ie using checked out working copies,
don't have to worry they get all plugins with the svn externals as it is now.
The dependencies will be resolved while building as it is now
But then for svn externals, what for people who want to use only one or few
plugins? Then maybe we need to reconsider component.load in plugins dir and
de/activatePlugin tasks...
So the decision about using svn external or pullPluginSource is up to the
community.
Maybe pullPluginSource is clearer because you easily get only what you want,
but what about plugins inter-dependencies? Also if you want a lot of plugins
it's kinda a pain. For now we have "only" 19 plugins but what's next?
To summarize, as long as plugins inter-dependencies will not be resolved svn
externals is more convenient.
About resolving plugins inter-dependencies, is it even possible (we finally let
it be in applications)? Consider DLL and Jar hells, even Microsoft and Sun were
not able to cleanly do it. And now you have Java 9 and its modules coming:
http://blog.codefx.org/java/dev/will-there-be-module-hell/
> create a separate svn repository for OFBiz official plugins
> -----------------------------------------------------------
>
> Key: OFBIZ-9182
> URL: https://issues.apache.org/jira/browse/OFBIZ-9182
> Project: OFBiz
> Issue Type: Improvement
> Affects Versions: Upcoming Release
> Reporter: Taher Alkhateeb
> Priority: Minor
> Labels: gradle, plugins, subversion
> Attachments: OFBIZ-9182-subversion-embedded.patch
>
>
> This issue is related to the discussion found in [this
> thread|https://s.apache.org/aohk] in which the community approved
> restructuring our repositories. To achieve this task the following needs to
> be done (in this order)
> # Update the gradle scripts to assume that no plugins exist in the plugins
> directory by default and no component-load.xml exists. It should follow the
> same logic in loading the components as found in the ComponentContainer
> class. Also the activation and deactivation of plugins happens in
> ofbiz-component.xml, not in component-load.xml
> # Add a new task to gradle called pullPluginSource that retrieves a plugin
> from subversion and defaults to the official plugins repository of Apache
> OFBiz. This task mostly serve "Trunk" because it always needs the latest
> source code of the plugins.
> # delete plugins/component-load.xml
> # move all plugins to a new repository called
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins
> # move the core framework to a new repository called
> http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework
> # fix buildbot to point to the new framework location
> # update documentation where applicable including README.md
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
