This is definitely an enhancement request.

Although, I have to say, when you did some changes on P4, you should be building it anyway, right? Because you'll need to run the tests, etc. and make sure that everything's still fine. And when you build P4, you can just type "mvn install" and that would update your local repository. So that when you do try to build P1, mvn will get the latest jar in your local repo.

Just my two cents. ^_^



Christopher Cobb wrote:

Is it expected/preferred that (all?) builds are normally be done from the
top level?  It doesn't seem that this works very well for situations where I
have a specific plugin which should only be used for certain children.  Even
if I configure the plugin at the top level, it may not make sense/not work
to invoke it on all the children.  So I have been changing into the
appropriate child directories to invoke some plugins, which leads to also
doing iterative builds in those child directories.



If it is expected that we will occasionally/frequently change into child
project to invoke parts of the build (like I do now), then it seems like
child-level builds should do transitive build dependency resolution.  So if
I am doing a build in P1, and P1 has some dependencies on P4, and something
in P4 has changed, then P4 should also get built/installed when I am
building P1.  It seems like this could be done by adding something like a
<relativePathToProject> tag within each <dependency> for which you would
like build-time transitive dependency resolution.  Or, I suppose it could
also be figured out by navigating to the parent pom and examining the
children.  Then you could figure out which dependencies are actually
"project siblings" and should be "transitively built".



It looks like sometimes/frequently you need to do child-level builds, and
you may want/need dependent "project siblings" to be build when you do so.


Is there a way to handle this now?  Is this an enhancement request?








-----------------------------------------
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]

Reply via email to