|
1) that is best practise. But having a module directory 'a' containing a pom with artifactId 'b' should work though.
2) Correct, that is the default. When scanning for parent poms, first ../pom.xml is checked to see if it matches the <parent> tag. If that fails, the local/remote repositories are consulted for that pom. The problem here with the SCM module is that if your CVS/Subversion/Whatever repository layout does In theory, maven should use the <module> definitions to define SCM urls for child modules. I hope this clarifies a lot. There is no easy solution.. One more thing: only <type>pom</type> projects can have modules.
So I don't see any reason not to add a root pom that specifies your four modules. That way you can have a normal tree with the modules as direct children (in the sub-directory-sense) as was intended: master/ Since the master would have packaging pom, it won't get included in eclipse, since it does not Personnaly, I named directory (module and scm) striclty equals (
 ).In fact, I used something like this
root-module as this to edit it with eclipse. I am using CVS and eclipse (workspace). All my projects are CVS modules: parent and moduleA, modulesB, moduleC:
\parent \moduleA \moduleB \moduleC Every project has the section "<scm><developerConnection>xxx</developerConnection></scm>" set to the correct cvs location. Refactoring of the package structure is not possible in my case (legacy system). I donīt see a way to use the multiproject release - any solution would be highly appreciated. At the moment I am forced to release all modules "my hand": Is there any chance to get this bug fixed in the next time?? I agree that making assumptions about the scm url in an eclipse "flat" directory structure is not a good implementation. However if each pom explicitly states the scmurl, why is that not used in the reactor as each child is built? Can that simply be the required behavior in order to fix this bug when using a flat directory structure?
so, the fix here needs to be that we check in every module individually, unless its a subdirectory of some other module?
Hi,
i have found this issue, because i have the same problem with Eclipse and Maven2 multi-projects. Do you plan to make a bugfix for that error ? Do somebody have a work-a-round (without releaseing each project by hand !!!) ? Just zoomin in on the eclipse problem.
There is an easy workaround for the flat project layout. Do not use the src specification in the .classpath file but use the 'link' functionality which is stored in the .project file. I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project.
And to clarify, if the parent POM needs to be updated and installed into the repository, it requires Done. Need to use the 'commitByProject' parameter of prepare mojo
My modules in root-pom-xml looks like:
<modules> The "commitByProject" for prepare goal works well and he does the preparation. But when I then perform the release goal I get a FileNotFoundException for the sub-modules pom.xml. He looks for the sub-module pom.xml in the root-project root/target/checkout folder. Any hints? It's a bug, file a new issue.
As a workaround, you can checkout your sub-modules into the checkout directory, I'm not sure it will work hallo
this bug is linked at http://maven.apache.org/guides/mini/guide-ide-eclipse.html are there any plans to support flat structures? or to refer to modules using groupId and artifactId (so one could create a logical structure which may not be the same as the physical structure)? thanks Dear all, we have converted release 3 plugin to work just fine with flat based multi-modules. The fix works for all maven project structures as it simply changes an invalid assumption made in the existing code base:-
Currently the 'working directory' of the 'execution project' is assumed to be the top 'ancestor' directory for which all projects contained within the reactor will live under. This is obviously incorrect for flat based projects. The fix is simply a case of determining what the directory in the maven module hierarchy is the common owning directory for all the projects with the hierarchy (which for nested projects happens to be of course the same as the execution project's home, or in other words the working directory'). For instance (please excuse ASCII art) A typical nested project hierarchy: D:\TEMP\MYSTUFF <-- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK |+POM.XML | |--B | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML The same logical hierarchy but expressed as a flat maven structure: D:\TEMP\MYSTUFF <-- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML These two are logically equivalent. The observation is that tagging, branching, checkout, checkin etc are version controlled based operations and the majority of VCS systems provide a file system based model (not bothering with object based VC systems here). So when we want to tag the stuff in MYSTUFF/TRUNK what we really want to do is create something under the TAGS in SVN (say) that has the trunk contents, thus: A typical nested project hierarchy: HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/ |+POM.XML | |--B | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML And for the flat structure we want: HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/ |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML By going through the module hierarchy and finding the common directory ancestor we are able to perform all the correct SVN operations (CO, CI, TAG, ETC). i.e. For the nested structure the common ancestor directory IS the current directory: D:\TEMP\MYSTUFF |+POM.XML | |--B | |+POM.XML ... Top common ancestor directory is equal to 'D:\TEMP\MYSTUFF' which happens to be the same as the working directory of the execution project (the top POM.XML). The same approach (of working out the common ancestor) works the on a flat structure but identifies that D:\TEMP\MYSTUFF is the common directory and NOT the execution projects' working directory which is in fact D:\TEMP\MYSTUFF\ROOT\ D:\TEMP\MYSTUFF |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML ... Cool. So now the only problem is in handling the perform operations where the plugin needs no project, simply checks out everything from the tag URL. Checkout works just fine but there is one critical piece of information missing, namely the path into the 'ROOT' project so that the build can start. This extra bit of information is simply added to the ReleaseConfiguration (that is persisted as release.properties). The perform reads this is an makes that the 'working directory' before it calls maven executor and then kicks off the build. Will be provide a patch for this fix shortly against MRELEASE-261 This issue is similar to MRELEASE-261 which is not fixed.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Multiproject Release: No check in
a complete build of all the modules as well, which makes this a bit inconvenient.
1. The artifactId is always the same as the directory-name holding the artifact
2. The parent "lives" always one level up in the hierarchy
So no matter what relative path settings are specified they are ignored in that class which builds various paths during inheritance. I am currently thinking about fixing this class but I would need some guidance to not break anything since I do not know what assumptions have been made further and if it is really only this class to fix.
A workaround for this problem is to not inherit things build from this class by e.g. specifying the SCM-URLs inside every pom and do not let maven build them for you during inheritance which holds true also for URLs.
Would it lead to problems if this class would support the relative paths without changing anything else ?