Phil Housley wrote:
On 15 March 2010 06:46, Jörg Schaible <joerg.schai...@gmx.de> wrote:
Phil Housley wrote at Sonntag, 14. März 2010 22:41:
On 11 March 2010 16:49, Phil Housley <undeconstruc...@gmail.com> wrote:
Hi,
I am (yet again) trying to subvert Maven with a custom plugin and
finding that the special cases in the core are causing problems. What
I'm aiming for is the ability to have a project which combines a
couple of modules as a single "release", and then deploys their
artifacts together, along with some metafiles. The modules also have
custom packaging types, and the deployment means a custom process over
some webservices.
The issue is that only pom package projects are allowed to have
modules, and the pom lifecycle includes the standard install and
deploy plugin, which will fail as there is no distributionManagement
section. Is it possible to either completely inhibit the plugins in
the pom lifecycle, or to create another packaging type which allows
multi-module?
To partly answer my own question, it seems that the checks for multi
module and parent allowed are coded as simply if
("pom".equals(project.getPackaging()), so it doesn't look like I can
use another packaging type there. I'm still looking into a way to get
the install and deploy plugins out of the pom lifecycle, but without
too much hope. I guess I will have to resort to specifying a specific
goal and ignoring the lifecycle altogether...
Why do you want this deployment happening at the parent? Just create another
modules with your custom packaging and declare all the other modules as
dependencies.
It's for convenience of the users mostly. Hopefully people will be
able to create these projects from an archetype, and then run deploy
from the root to push several modules together as a release. Using a
separate meta module is extra work for the users, but is the plan I'm
currently working at.
It is still not clear as to how your situation is so radically different
from any other team of developers.
What are you building that is so different from a normal application?
The main problem is that if the modules are not in the reactor when
"deploy" is run, I have to add an install phase to be able to pick
them up (which doesn't make much sense for the custom packaging I'm
using); while to get them into reactor, I would need to run "mvn
deploy" from the root, which would invoke the standard deploy plugin
on the root pom.
In the higher level projects, you just need to declare your dependencies
and maven will make sure that the right stuff is included automatically.
It is not clear what you are trying to include that is so odd that the
standard Maven lifecycle will not assemble properly.
Maven out-of-the-box supports multiple developers building a
multi-module application with all the essential housekeeping.
I'm thinking currently of a goal "custom-stuff:deploy" which can be
invoked on the root, will force a "package" phase in each module, and
then when invoked (automatically) on each module will ignore all those
without some special packaging type. This adds a requirement for a
new meta project with dependencies on the others, but that isn't too
much overhead to my mind - will have to see how it goes down with
others.
Unless you have a really odd setup, you should be able to greatly
simplify life for everyone without having to resort to odd-ball procedures.
Each library module gets built and deployed into your artifact
repository (really need one if you are multiple developers) as SNAPSHOTS
or releases and when you build an executable
its dependencies are picked up automatically and incorporated into the
build of the executable.
This is the normal Maven way - nothing special needed.
Ron
Thanks for your input.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
