ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
Date Fri, 03 Feb 2017 11:23:51 GMT

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

Mime
View raw message