This just means that you could create a couple of "orchestration only"
poms, each with a war project and its dependency components specified as
modules...and with a packaging of "pom" which means it'll organize the
submodules (war and components) according to dependencies, and then
build them.
Aside from the duplication of information in these two (or more) POMs,
you will end up with a couple of dummy poms installed in your local repo.
We're planning to include more features related to the concept of a
project directory context (I mean your project within some larger
context of an application or something), but this will likely have to
wait at least until 2.2, since it's going to require some major design work.
Cheers,
John
Chris Bredesen wrote:
I just tried this, and the problem is that the POM that contains the modules
becomes an aggregator project, and requires <packaging>pom</packaging>.
This precludes us (I think) from using w1 (or any "end result" artifact) as
the driving build. I will play with this some more.
My actual enterprise is quite a bit more complex than w1,w2,c1,c2,c3;
indeed, c1 actually uses c2-c4, and w1 might use c1,c5,c6. It's getting
simpler, but there's always legacy code :)
The point is, any one of the artifacts might be the "interesting" one, i.e.,
the one which I'm attempting to create. That project, whatever level it
might be at, would need to know not only whom he depends on, but how to
build the dependency. It's almost as if we need another level past SNAPSHOT
-- something like SNAPSHOT_LOCAL, which says not only that we depend on the
most recent version, but we should freshen the artifact if it is dirty. I
may be totally off base here, as I'm a Maven newbie, but I think the tool
has immense promise for even complex teams. (It's a real life saver for my
smaller projects).
I will have to look at the source and see if there's something I can glean
from all of this. I'm glad to know I'm not alone in my venture!
To add another log to the fire, I'd also love for the Maven Eclipse plugin
(or the eclipse m2 plugin, heh) to keep my Eclipse environment up to date!
Cheers,
Chris
-----Original Message-----
From: Christopher Cobb [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006 9:41 AM
To: 'Maven Users List'
Subject: RE: Transitive "sibling" builds
That's an interesting idea. I'll give it a try.
But even if it works, it is less than ideal because then you
are putting the same information in twice: once at the top
level to say what its children are, and once at the child
level to say what its siblings are. This violates the
hallowed OnceAndOnlyOnce dictum.
It would be nice if you could just put the information in
(once) at the top level, and it would "just work" at the
sibling level.
-----Original Message-----
From: Scokart Gilles [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006 8:47 AM
To: Maven Users List
Subject: RE: Transitive "sibling" builds
Isn't it possible to use something like that :
For example if w1 use c1 and c3, in the pom of w1 use : <modules>
<module>../c1</module>
<module>../c3</module>
</modules>
I think you could even put that into a profile in order to allow
recursive build or not.
Gilles
-----Original Message-----
From: Chris Bredesen [mailto:[EMAIL PROTECTED]
Sent: 19 January 2006 02:42
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Transitive "sibling" builds
Hello All,
Just subscribed, and I wanted to revisit the discussion that took
place regarding the above topic in this thread:
http://www.mail-archive.com/[email protected]/msg32502.html
There seems to be a lot of resistance from the community (lack of
understanding, maybe) to implementing this sort of
transitive build
mechanism. I, too, do exactly what the original poster does, and
the
lack
of support for this is the only real reason I haven't
adopted Maven2
as
my
build tool of choice. I get closer each time, but since
there's no
way
to
build an entire WAR file in one shot, I have to give it up. I
realize
it
CAN be done, but it seems that the WAR file has to be the
parent of
all its components.
I wanted to add my own experience into this discussion,
and possibly
even
spur enough information to contribute myself. I have my
enterprise
laid out as such, made of webapps (w) and components (c):
w1
w2
w3
c1
c2
c3
c4
c5
Each of the webapps may use any of the components as
dependencies,
along with a slew of off-the-shelf API's. The problem for me is
that these components can have only one parent directory.
I have no
way to separately build w1 and w2. Unless I'm missing,
something,
we'd need sibling communication in order to make this work.
Currently each Ant buildfile knows which components are
needed, but
has
no
idea if they need to be built or not, thus causing me to build
everything
each time I compile. To avoid this, I also maintain Eclipse
projects
(one
per app, not one big one) which have project-level
dependencies on
each other. This makes the local development compilation
very fast,
but I
have
to maintain both the Eclipse metadata AND the Ant buildfiles.
Maven addresses all of this (I really love the Maven2 plugin for
Eclipse),
but since there's no support for sibling transitive
builds, there is
no way to just grab all the source and compile w1 or w2
in one shot.
Eventually
I'd like to use Continuum as well.
If I'm missing something here, I'd sure like to know
about it. If I
can contribute and make this happen, I'd love to, when
time permits.
I fear I'd have a lot of catching up to do, though.
Perhaps I can
work on some documentation at the very least.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----------------------------------------
Attention:
Any views expressed in this message are those of the
individual sender, except where the message states otherwise
and the sender is authorized to state them to be the views of
any such entity. The information contained in this message
and or attachments is intended only for the person or entity
to which it is addressed and may contain confidential and/or
privileged material. If you received this in error, please
contact the sender and delete the material from any system
and destroy any copies.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
