On 15 March 2010 12:05, Ron Wheeler <rwhee...@artifact-software.com>
wrote:
Phil Housley wrote:
On 15 March 2010 06:46, Jörg Schaible <joerg.schai...@gmx.de> wr
ote:
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?
Sorry, I really don't seem to be doing a great job of explaining
things.
The situation is that we have some custom packaging types, call them
bundles, which we generate using Maven and a custom plugin/packaging
type, and are basically tarballs with some special files, plus some
attached artifacts, made in the normal way.
Several of these bundles, plus some common meta files (release notes,
etc) make up a release of a project, which should be deployed at once.
Because each bundle individually isn't complete by itself, there is no
particular sense in which it can be deployed, other than just pushing
it into a Maven repo as a temporary holding place.
The ideal situation would be to have all bundle projects inside
another project, giving roughly
/project/
pom.xml (with custom <packaging>, and <modules>)
bundle-1/
/pom.xml (with bundle-x packaging)
bundle-2/
/pom.xml (with bundle-y packaging)
src/releaseinfo/...
Then "mvn deploy" at the root would do the packaging, merge any common
stuff, and push the whole lot together to the release location.
Unfortunately, only pom packaged projects can have modules, and
running deploy on a pom project will always invoke the
maven-deploy-plugin, which is not appropriate here.
My next plan was to add a "meta" module, which would depend on the
bundles in the reactor. On running "mvn custom-plugin:deploy"
directly from the command line, the bundles would be packaged, and the
meta project would be detected as meaning the deployment should be
done using meta-data contained within it.
That plan is awkward, as you can't run "maven deploy," but works -
excepting some issues, mainly that you can't access the bundle
artifacts unless you run "install" on them, which renames the files.
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.
An alternative to my above plan is to skip the project aggregation
entirely, build and install the bundles separately, and then use a
similar meta project with a real "deploy" phase, which is neater in
some ways, but means you can't do a one step release. Now that I've
found you have to run the install phase even in the same reactor, this
is looking like less of a disadvantage, as some of the overhead would
be required anyway.
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.
I appreciate that, but the "deploy" phase on the bundles shouldn't
really be the standard push to maven repo, it should be a custom
thing, and only done in the context of deploying several modules
together as a project release. If there is no way to do this, I will
drop the plan and do it a more conventional way, if one that maps that
much more awkwardly to the specific situation. But maybe that can't
be helped.
Thanks for your time.
Ron
Thanks for your input.
- Jörg
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
