[jira] [Comment Edited] (OFBIZ-9182) Create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877541#comment-15877541 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/22/17 6:07 AM: - For now no other solutions than https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon Even when completely deleted, somehow the daemons keep a memory of my try to install plugins. was (Author: jacques.le.roux): For now no other solutions than https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon > 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, pluginsList.txt, > pullAllPluginsSource.log > > > 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15852746#comment-15852746 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/4/17 1:27 PM: As I said already, the pb with gradle-svntools-plugin is it does not handle properties (yet?) so I don't see how at this stage. You said: bq. svn externals could be an implementation detail then embedded inside pullPluginSourceAll Morevoer, as setting an svn:externals is only a matter of a property commit (done once), I don't see the need to have that embedded inside pullPluginSourceAll at all IMO pullPluginSource is only interesting if we can pass an URL for non ASF repos. But I agree we can go on with restructuring the OFBiz repo branch, and discuss further on dev ML if we should use svn:externals or not. I think we already put all the arguments on the table. was (Author: jacques.le.roux): As I said already, the pb with gradle-svntools-plugin is it does not handle property (yet?) so I don't see how at this stage bq. svn externals could be an implementation detail then embedded inside pullPluginSourceAll Morevoer as setting an svn:externals is only a matter of a property commit (done once) I don't see the need to have that embedded inside pullPluginSourceAll at all Moreover IMO pullPluginSource is only interesting if we can pass an URL for non ASF repos. But I agree we can go on with restructuring the OFBiz repo branch, and discuss further on dev ML if we should use svn:externals or not. I think we already put all the arguments on the table. > 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15852740#comment-15852740 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/4/17 10:41 AM: - Complexity, that's also my point. With a pullPluginSourceAll you have to maintain it each time you change the content of the plugins folder. While setting svn:externals is done in seconds for "eternity". Committers, users don't need to use pullPluginSourceAll. The plugins are already there checked out with the rest (for now ofbiz-core, later another externals can be set for ofbiz-framework and ofbiz-core as Jacopo suggested, and what-not anyway). For users using working copies, if they don't want to use a plugin they can either deactivate it or simply get rid of it by deleting its folder. was (Author: jacques.le.roux): Complexity, that's also my point. With a pullPluginSourceAll you have to maintain it each time you change the content of the plugins folder. While setting svn:externals is done in seconds for "eternity". Committers, users don't need to use pullPluginSourceAll. The plugins are already there checked out with the rest (for now ofbiz-core, alter another externals can be set for ofbiz-framework and ofbiz-core as Jacopo suggested, and what-not anyway). For users using working copies, if they don't want to use a plugin they can either deactivate it or simply get rid of it by deleting its folder. > 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15852723#comment-15852723 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/4/17 9:56 AM: Taher, Are you sure that's what Nicolas said? Nicolas? Anyway I agree we can go on, adding a svn externals is few seconds... was (Author: jacques.le.roux): Taher, Are you sure that's what Nicolas said? Nicolas? > 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850586#comment-15850586 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:19 PM: - 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... 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. We just miss the automation. Because so far the Gradle plugin has no task for properties. And 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850586#comment-15850586 ] Jacques Le Roux edited comment on OFBIZ-9182 at 2/2/17 10:12 PM: - 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. We just miss the automation. Because so far the Gradle plugin has no task for properties. And 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. You can either use it with a revision (for a published release you can use its tags) or w/o which means taking HEAD. > 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)
[jira] [Comment Edited] (OFBIZ-9182) create a separate svn repository for OFBiz official plugins
[ https://issues.apache.org/jira/browse/OFBIZ-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
