A few things came up in this thread, I'll try and attack them all here
in point form.
- the tools should live as close to their source as possible. I'd even
suggest keeping it in the plugin until makes sense to factor it out
- if something gets factored out, it should be independant of Maven
tools as much as possible. This makes it reusable elsewhere, and perhaps
can go to being a general library like plexus-archiver, stale source
scanners, classloading, etc. These would probably move to commons
eventually. Others, like maven-archiver which have maven specifics,
should be in the Maven SVN (see below).
- if everything that uses the library is not at Maven, then it shouldn't
be here (so mojo.codehaus.org might have a similar setup)
- extensions (new resolvers, etc) should be in the Maven SVN. Most would
be in the core distribution in fact.
Proposal: Let's add a "maven-shared" area of SVN, like maven-plugins in
the new structure. Each will be an independantly versioned and developed
lib, for use in other plugins.
Thanks for championing this John :)
Cheers,
Brett
John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I have developed a few tools projects that I'm using to support multiple
plugins, etc. I wanted to add the plugins to the mojo project, but I'm
unsure of the proper place for these supporting projects.
I'm not really inclined to add this type of project to the main maven
project, since it really has very little to do with Maven itself, except
tangentially. Besides, these sorts of projects should be available for
development by the same group that maintains the mojo project, where the
plugins themselves will eventually land.
Specifically, the two projects I've developed are a RPM name-formatter
utility and an Ant-task convenience API (sets up and manages the Project
/Target instance used to programmatically use Ant tasks). The latter was
factored out of the antrun plugin, and I'd like to eventually re-merge
them, with the antrun plugin using the antcall (new) API...but that's up
to Kenney. :) The RPM-naming utility is also used by an RPM artifact
resolver, which I'm *really* unsure where to park.
At any rate, I believe this problem isn't going to go away, and we need
to address the question of supporting projects for mojos and other maven
components. For this last item (components), it might not even make
sense to house these projects in the mojo.codehaus.org project...
Ideas?
Thanks,
- -john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDZnvpK3h2CZwO/4URAi5HAJ0R62HYs+9OzbNhffkzPpFstSFuLACfWgvc
WR9se5rIMfHM7QVVsimuM00=
=qhsm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
