You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2013/07/13 14:30:45 UTC
Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging
Plugin - move to proper from sandbox)
<snip/>
I've done some more investigations.
It seems it's not possible to use mvn deploy directly to a dist URL such as
https://dist.apache.org/repos/dist/dev/commons/plugins
Probably because the server does not support WEBDAV or something.
However, there is a workround:
- checkout the URL locally, say to D:/commons-plugins/
- use mvn deploy to apply changes to the checkout (see below)
- check the changes back into SVN
A little bit awkward, but not difficult, and easy to revert.
To prevent accidental deployment of non-SNAPSHOT releases to Nexus,
the url for the apache.releases.https repository can be overridden.
If this is set to the file URL of the local checkout, then "mvn
deploy" will update that instead.
This will vary between RMs so will require a once-off entry in the
RM's settings.xml file - and/or could be defined by a property on the
command-line.
For testing snapshot versions of the plugins, the existing Commons
Snapshots repo could be used. Since there's no QA needed for
snapshots, it seems unnecessary to keep the developer plugins
separate.
To summarise, I'm hoping this is acceptable:
================================
Developer plugin tools will be created and maintained under:
http://svn.apache.org/repos/asf/commons/dev/plugins[trunk/tags/branches]
They will use the package name: o.a.c.dev_plugins.<name>
Maven coords: o.a.c.dev_plugins : commonsdev-<name>-plugin
The plugins will use the pseudo-repository at
https://dist.apache.org/repos/dist/dev/commons/dev_plugins
Note: I added the dev_ prefix/suffix just in case Commons ever decide
to release a Maven plugin.
Unless there are objections/better suggestions I'd like to start
setting up the structure next week.
I propose creating an example plugin which will do very little - maybe
nothing - but should serve as a proof of concept (and hopefully a
template for more useful plugins).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging
Plugin - move to proper from sandbox)
Posted by sebb <se...@gmail.com>.
On 13 July 2013 15:26, Gary Gregory <ga...@gmail.com> wrote:
> On Sat, Jul 13, 2013 at 8:30 AM, sebb <se...@gmail.com> wrote:
>
>> <snip/>
>>
>> I've done some more investigations.
>>
>> It seems it's not possible to use mvn deploy directly to a dist URL such as
>> https://dist.apache.org/repos/dist/dev/commons/plugins
>> Probably because the server does not support WEBDAV or something.
>>
>> However, there is a workround:
>> - checkout the URL locally, say to D:/commons-plugins/
>> - use mvn deploy to apply changes to the checkout (see below)
>> - check the changes back into SVN
>> A little bit awkward, but not difficult, and easy to revert.
>>
>> To prevent accidental deployment of non-SNAPSHOT releases to Nexus,
>> the url for the apache.releases.https repository can be overridden.
>> If this is set to the file URL of the local checkout, then "mvn
>> deploy" will update that instead.
>> This will vary between RMs so will require a once-off entry in the
>> RM's settings.xml file - and/or could be defined by a property on the
>> command-line.
>>
>> For testing snapshot versions of the plugins, the existing Commons
>> Snapshots repo could be used. Since there's no QA needed for
>> snapshots, it seems unnecessary to keep the developer plugins
>> separate.
>>
>> To summarise, I'm hoping this is acceptable:
>> ================================
>>
>> Developer plugin tools will be created and maintained under:
>>
>> http://svn.apache.org/repos/asf/commons/dev/plugins[trunk/tags/branches]
>>
>> They will use the package name: o.a.c.dev_plugins.<name>
>>
>> Maven coords: o.a.c.dev_plugins : commonsdev-<name>-plugin
>>
>> The plugins will use the pseudo-repository at
>>
>> https://dist.apache.org/repos/dist/dev/commons/dev_plugins
>>
>> Note: I added the dev_ prefix/suffix just in case Commons ever decide
>> to release a Maven plugin.
>>
>
> Underscores are pretty unusual in Maven IDs, how about:
>
> o.a.commons.plugins : dev-<name>-plugin
>
> I mean, you do not need "commons" and "dev" in both the group ID and
> artifact ID.
But we do actually do that, for example
o.a.commons:commons-lang3
o.a.commons:commons-math3
I'd prefer to keep commonsdev-<name>-plugin to reduce the chance of
clashes - and clarity - when using pluginGroup shortcuts.
e.g. it seems better to use "mvn commonsdev-example" rather than "mvn
dev-example"
Other projects may also decide to have their own plugins; we don't
want to make it awkard for people who happen to be developers on
multiple projects.
I'd be happy with
o.a.commons.plugins : commonsdev-<name>-plugin
> Gary
>
>>
>> Unless there are objections/better suggestions I'd like to start
>> setting up the structure next week.
>>
>> I propose creating an example plugin which will do very little - maybe
>> nothing - but should serve as a proof of concept (and hopefully a
>> template for more useful plugins).
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging
Plugin - move to proper from sandbox)
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jul 13, 2013 at 8:30 AM, sebb <se...@gmail.com> wrote:
> <snip/>
>
> I've done some more investigations.
>
> It seems it's not possible to use mvn deploy directly to a dist URL such as
> https://dist.apache.org/repos/dist/dev/commons/plugins
> Probably because the server does not support WEBDAV or something.
>
> However, there is a workround:
> - checkout the URL locally, say to D:/commons-plugins/
> - use mvn deploy to apply changes to the checkout (see below)
> - check the changes back into SVN
> A little bit awkward, but not difficult, and easy to revert.
>
> To prevent accidental deployment of non-SNAPSHOT releases to Nexus,
> the url for the apache.releases.https repository can be overridden.
> If this is set to the file URL of the local checkout, then "mvn
> deploy" will update that instead.
> This will vary between RMs so will require a once-off entry in the
> RM's settings.xml file - and/or could be defined by a property on the
> command-line.
>
> For testing snapshot versions of the plugins, the existing Commons
> Snapshots repo could be used. Since there's no QA needed for
> snapshots, it seems unnecessary to keep the developer plugins
> separate.
>
> To summarise, I'm hoping this is acceptable:
> ================================
>
> Developer plugin tools will be created and maintained under:
>
> http://svn.apache.org/repos/asf/commons/dev/plugins[trunk/tags/branches]
>
> They will use the package name: o.a.c.dev_plugins.<name>
>
> Maven coords: o.a.c.dev_plugins : commonsdev-<name>-plugin
>
> The plugins will use the pseudo-repository at
>
> https://dist.apache.org/repos/dist/dev/commons/dev_plugins
>
> Note: I added the dev_ prefix/suffix just in case Commons ever decide
> to release a Maven plugin.
>
Underscores are pretty unusual in Maven IDs, how about:
o.a.commons.plugins : dev-<name>-plugin
I mean, you do not need "commons" and "dev" in both the group ID and
artifact ID.
Gary
>
> Unless there are objections/better suggestions I'd like to start
> setting up the structure next week.
>
> I propose creating an example plugin which will do very little - maybe
> nothing - but should serve as a proof of concept (and hopefully a
> template for more useful plugins).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory