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

Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:25 PM:
-----------------------------------------------------------------

Nicolas, 

Has Taher suggested, people using releases would have available corresponding 
plugins released. They don't need to use pullPluginSource only pullPlugin

In other cases (relying on checked out sources), svn externals is perfect. 
Because it opens all possibilities svn provides. When associating a plugin, you 
can either use a revision or w/o revision which means taking HEAD.

We though miss the automation. Because so far the Gradle plugin has no task for 
properties. Properties are very powerful features of Svn, often neglected.

Disclaimer: I must say I have not yet a clear picture in mind, just ideas...


was (Author: jacques.le.roux):
Nicolas, that's why svn externals is perfect in this case, because it opens all 
possibilities svn provides. When associating a plugin, you can either use a 
revision (for a published release you can use its tags) or w/o revision which 
means taking HEAD.

Ah yes, answering your point: people not able to use a checkout are indeed in 
another situation. But we could document it by simply suggesting to check out 
using the release tag. It's the same thing, just not packaged, and with the svn 
bagages. The svn bagages can be droppped later by using an export, note that 
the required svn externals (for the used plugins) will be also exported by 
default.

Now it's not an official way to do things... Because only releases are 
published. So we have indeed to think about this aspect. Even if for most 
people using OFBiz it's not really an issue.

We also miss the automation. Because so far the Gradle plugin has no task for 
properties. Properties are very powerful features of Svn, often neglected.

Disclaimer: I must say I have not yet a clear picture in mind, just ideas...

> 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