On 13 July 2013 15:26, Gary Gregory <garydgreg...@gmail.com> wrote: > On Sat, Jul 13, 2013 at 8:30 AM, sebb <seb...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
