[
https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306510#comment-306510
]
Stephan Pauxberger commented on MNG-5085:
-----------------------------------------
Let me add another thought:
I do mainly cross-functional work, so there are a many situations where I am
forced to quickly correct problems in many different projects that I don't have
present in my working copy (multiply by various branches).
So let's look at a typical scenario:
a hotfix is needed for project X, which I do not have on my hd yet. X consists
of 100 modules right now (in multiple layers). Our developers usually can work
on a partition of that directory tree using all available features. However, my
hotfix (or the debug session) requires changes in mutliple partitions.
Right now, I have to checkout all partitions that i need to change code in
(which costs a lot of time). Then I either build the whole project - which
takes even longer, or I decide only to build that changed modules and their
dependants. For that, I can use Mavens -pl and -amd options, but I have to list
a changed modules (10, 15?) -> this is the way that hudson/jenkins does when
building incrementally.
Now, with my proposal, I would work like this:
I check out only those modules relevant to me (which, BTW, is a brilliant
feature of TortoiseSVN 1.7). I make my changes, build the whole thing with the
new proposed -imm switch which tells Maven to ignore missing modules, i.e. the
reactor is built correctly, it simply does not contain any missing modules.
Dependencies to those modules are naturally resolved via the normal mechanisms
(local repo, remote repos). The nice thing about this is: once I notice that I
need an additional module, I can simply materialize it using subversion, and
from that moment, it is simply included.
Actually, this would work a lot like m2e using workspace resolution, since m2e
ignores the reactor. Right now I can work perfectly using this setup while
using eclipse. As long as I do not try to start an actual Maven build.
Once again, let me raise some important points:
- I do not want to change the default behaviour of Maven
- This mode of work is strongest with Subversion, the speed factor is simply no
longer relevant using Mercurial or Git, however I already encountered similar
situations using Git where I could have used this feature
- The proposed mechanism would work very similar to Maven's parent resolution
(i.e. look in the relative path, if the parent is there, use it, if not, ask
repositories)
> Add a CLI option to ignore missing modules
> ------------------------------------------
>
> Key: MNG-5085
> URL: https://jira.codehaus.org/browse/MNG-5085
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Reactor and workspace
> Reporter: Stephan Pauxberger
>
> Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e.
> we do not checkout the whole project. Example:
> Full Project (as in Repository):
> Parent
> pom.xml (contains A and B as modules)
> --> A
> pom.xml
> --> B
> pom.xml
> Now, do a checkout (svn co xxx --depth children; svn update --set-depth
> inifity A)
> Working Copy:
> Parent
> pom.xml (contains A and B as modules)
> --> A
> pom.xml
> --> B (no pom!!, since we only did a sparse checkout)
> Now, this setup is not buildable, since maven complains (rightfully) about a
> missing pom for B.
> What I propose is an option to change this behaviour with a command-line
> option (-imm, --ignore-missing-modules) that would simply ignore missing
> modules during pom resolution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
