The problem still exists. If you had a modules.xml, you're still
supporting building multiple projects at once. As long as you support
building multiple projects at once, you have two options:
1) Support all the possible intricacies of inter-phase dependencies
2) ONLY accept 'install' and higher a possible phases.
The reason uber poms are helpful to our project is that we have code
that needs to be logically separate from each other, but the same
developers work on both modules. working in a 'constantly install'
development paradigm is painful, although I do appreciate the nicety
of not having relative paths, and we have some projects that are
separate enough from out central product that we don't have one uber
pom.
The server, server-integration-tests setup I described below is a good
example. Its confusing for developers to have to install the server,
just to run their integration test. I want them to code their new
server code, code their unit test, and code their integration test,
without having to worry about which version of the snapshot of the
server jar is currently in their local repository, or if they forgot
to install it in the local repository, are they using yesterdays
continuous integration build from the share repository?
That sort of confusion is exactly why I get a lot of the same feedback
Jason was referring to in the other thread, although I haven't gotten
negative feedback in a review because if it. If I did, I'd drop maven
like a hot potato. On that note, I've learned development
infrastructure technology change never wins you friends or gets you
fame. You might be able to prove people are wasting 1/4 of their time
with ant for example, but you'll never recover from the agony of a
year long migration to something better (maven).
-Josh
On Mar 21, 2008, at 10:39 AM, [EMAIL PROTECTED] wrote:
And rip out the <module> functionality from poms too. Instead, have
maven support "module.xml" files which contain a list of <module>
definitions and nothing else. Then the confusion over parent-poms vs
poms that just happen to be in the parent directory would go away too.
[EMAIL PROTECTED] schrieb:
I'd rather go the other way. Rip out the ability to reference parent
poms using relative paths, and these sort of reports would go away,
because it's *clear* that building A3 will not cause B1 or B2 to be
built.
Using relative paths to poms solves a small subset of problems, in
smallish projects. But when projects start to scale up, relative
paths
don't work. And they make people *think* in path-oriented ways,
rather
than thinking in repository-oriented ways.
Regards,
Simon
Joshua ChaitinPollak schrieb:
I've noticed the following behavior, which I find a bit frustrating:
Using Amit's project layout below, if I cd into A3 and run 'mvn
compile', its going to use the B1 and B2 projects from my local
repository, even if I referenced a parent pom in A3. I wish Maven
would use the parent pom to determine if B1 and B2 were available,
and
compile them as well.
In addition, I've noticed that maven gets confused if you have
modules
depend on the test jars (or worse, assemblies) of other modules. For
example, I have this setup:
Root
- server
- server-integration-tests
The server-integration-tests are implemented as tests (so no
production code), but the project has a dependency on the server,
the
server:test-jar, as well as the server:tar.bz2.
But when I run mvn test-compile from root, I get errors saying that
the server:test-jar and server:tar-bz2 cannot be found.
My only option is to run "mvn install", which seems to work.
I guess what I'm saying is that maven only runs the phase you
specified at the commandline, for all modules in the pom, and I wish
it would take phase into consideration when executing
dependencies. If
I run:
mvn test-compile at the root of my project, it should be smart
enough
to run mvn package on the 'server' module and provide that package
to
the 'server-integration-tests' module.
-Josh
On Mar 21, 2008, at 9:31 AM, amit kumar wrote:
How to list that dependency? I do have the dependency of A3 on B1
and
B2(in
the <dependency> tag as jar). But that doesn't seems to make
Maven go to
build B1 and B2 when building A3 because I guess it looks in the
repository,
if not there it throws an error.
If it has been working in this way, it would have been the
solution.
But I
am not able to see that happening.
Is there a different way of mentioning a project As' dependency on
another
projectB that would trigger the build of projectB as soon as it
finds
in the
dependencies? of that project?
Regards,
Amit.
On Wed, Mar 19, 2008 at 6:49 AM, Brian E. Fox <[EMAIL PROTECTED]
>
wrote:
Maven starts with the ordering listed in the poms (A and its
children,
then B and its children, etc) unless there is a dependency. If it
sees a
dependency, then it will automatically reorder by pushing down
modules
that have a dependency so they build after their dep.
I'm wondering why the order matters if you don't have a dependency
listed (I'm assuming you don't or it would be ordered already).
-----Original Message-----
From: amit kumar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2008 4:42 AM
To: Maven Users List
Subject: Customizing Build order
Hi,
I have a multi-module project with the following structure.
Root
-A
-A1
-A2
-A3
-B
-B1
-B2
-B3
-B4
In the Root's pom i have mentioned my modules as:
<module>A</module>
<module>B</module>
Now is there a way that I can change the normal build
order(which is)
-Root
-A
-A1
-A2
-A3
-B
-B1
-B2
-B3
-B4
to something like
-Root
-A
-A1
-A2
-B
-B1
-B2
-A3
-B4
It is actually a requirement. But I doubt that there is a
possibility
that
the CVS structure itself is not competent enough then to handle
inter-module
dependencies.
Any inputs?
Thanks and regards,
Amit Kumar
---------------------------------------------------------------------
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]
--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
