[
https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306370#comment-306370
]
Ivan commented on MNG-5085:
---------------------------
Yes, this is already what we are doing.
A given developer wants to improve the plugin A which depends on the Core.
He create a branch with that plugin only. (Branching all projects should not be
necessary in my opinion)
In its workspace he has only the plugin A and the "main" project (top parent
project which reference all the modules and the assembly).
If he wants to compile it, no problem, the Core is resolved as jar-artifacts
and retrieved from the maven repository.(local or remote)
Now if he wants someone to test its modifications before requesting integration
to the trunk.
He has to generate a testable version.
That's were he needs to trigger the "main" project which has a reference on all
modules and does the assembly part.
> Right now it will fail unless he checkout the other modules
I'm not sure of how you think I can "workaround" that with hudson:
> Checkout every modules from Trunk except the ones that are in developer's
> branch
> Run mvn package on the main project which will trigger ALL the submodules
> 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
