[ 
https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851363#comment-15851363
 ] 

Jacques Le Roux commented on OFBIZ-9182:
----------------------------------------

Actually I very well got what you said. I'm just adding that using externals is 
a very simple solution that should be considered for people who are using svn 
to check out things.

bq. * First of all, the pullPluginSource won't stop you from using subversion 
if you want to. It's just a convenience task
Yes got that
bq. * In the first implementation way I described above, you need svn 
installed, in the second you don't
Yes got that too, as I said what I'm suggesting is for people using svn to 
"automatically" have the same that we have now. For instance for committers 
it's very convenient.
bq. * also using my patch we do not rely on a specific version control system. 
We can change it by changing implementation of pullPluginSource
That could be indeed interesting if we move to Git for instance. Note that, as 
I said above, the same than svn externals can also be achieved by Git.
bq. * with pullPluginSource we can easily add the logic to pull dependencies 
which we cannot do with raw subversion. The implementation is already there in 
"pullPlugin".
OK good, not needed if we use svn externals for OOTB plugins. It could 
interesting if pullPluginSource accepted an url parameter for people having 
sources in other repos. This is what I was looking for when I spoke about 
Jitpack.
bq. * activating / deactivating plugins (or any component) can be done using 
ofbiz-component.xml. I don't understand why component-load.xml is needed in 
your argument above.
Yes right, that's a very good point I missed.  Indeed using the enabled 
attribute of the ofbiz-component element is the way.

So I think we can agree that having both solutions is possible. For svn 
externals, after changing the repo structure, it's only a matter of adding the 
property, et voilĂ . Do you think we need to discuss that on dev ML?

> 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)

Reply via email to