[
https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847573#comment-15847573
]
Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:05 PM:
-----------------------------------------------------------------
Hi Taher,
Just thinking out loud for now...
We don't need 2 Buildbot scripts if we can use svn externals
http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html
Note about automation: currently
https://github.com/martoe/gradle-svntools-plugin does not support svn propedit,
we could contribute, it's groovy code after all...
BTW, there is a similar solutions with Git if we need it later
https://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git
I have one worry, what about people relying on branches (evolving with new
features eg R16.11) and not releases (fixed but bugs, eg 16.11.01) ? It seems
they will loose something, don't they? Fortunately svn externals allows to
define specific revisions. For instance we could define a revision for each
plugin. As you said maybe too much, but maybe also convenient. Anyway this
needs at least to be evaluated (ie more than just thinking out loud late in the
evening...)
was (Author: jacques.le.roux):
Hi Taher,
Just thinking out loud for now...
We don't need 2 Buildbot scripts if we can use svn externals
http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html
Note about automation: currently
https://github.com/martoe/gradle-svntools-plugin does not support svn propedit,
we could contribute, it's groovy code after all...
BTW, there is a similar solutions with Git if we need it later
https://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git
I have one worry, what about people relying on branches (eg evolving with new
features R16.11) and not release (fixed but bug 16.11.01) ? It seems they will
loose something, don't they? Fortunately svn externals allows to define
specific revisions. For instance we could define a revision for each plugin. As
you said maybe too much, but maybe also convenient. Anyway this needs at least
to be evaluated (ie more than just thinking out loud late in the evening...)
> 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)
