Re: Progress on support for large projects
On Sat, May 16, 2009 at 5:17 AM, Joerg Hohwiller jo...@j-hohwiller.de wrote: Off topic. Actually I believe this isn't true anymore. See http://jira.codehaus.org/browse/MECLIPSE-344 [del] mvn eclipse:eclipse will make sure my module pA references the eclipse project for module cA (and not the jar of cA in the repo) Thanks for the hint! But only works if eclipse-plugin knows where my workspace is. The location may be different for each developer so I can NOT truly automate. Anyhow I will start using this. At least better solution than what I had before. With 2.6 (http://maven.apache.org/plugins/maven-eclipse-plugin-2.6/eclipse-mojo.html#workspace) if the workspace variable is not defined then m-e-p will walk up the directory hierarchy attempting to locate your workspace. As a general rule people checkout their projects underneath an eclipse workspace so it will find it automatically. Otherwise you will need to specify it manually. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Do you need simple IT-projects that I shall attach to MNG-4161 and related? Sample ITs for sure, and some level of detail in a proposal like these: http://docs.codehaus.org/display/MAVENUSER/User+Proposals here is my proposal: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance Let me know if somethings missing or wrong. BTW: is there a chance to have such feature running in a usable version of maven (NOT a official release) in a couple of month? If we are talking about something that will go into 3.x and is NOT usable before 2010, I rather put my energy in a simple front-end that handles this feature and then delegates to maven. Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoPH6UACgkQmPuec2Dcv/8JrgCfQXNZXlA/c/NcA+aJywZ7s8bt LJMAnjyKgoyEfhPk8k299FjJvLS7l8j3 =xAY4 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/Model is
just a stupid POJO and various plugins manipulate it with side effects.
Sounds a little hacky to me but thats the way it is. So my serialization
idea is nuts though.
Anyhow I think that if you have some information in memory, you should
NOT have to write it to the disc so that someone else can copy (read
and write)
it again. I thought that you store the transformed XML in that new string
attribute (was it alternativeRepresentation) so the Installer/Deployer
could write this string if available instead of copying the pom.xml as
is.
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
A big problem could be the encoding issue if you store XML in a string
and then want to save it with some Writer, you need to know the encoding
from the XML-header or you run into trouble.
My fix didn't store the XML in a string, it modified the DOM.
After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on the new
pom).
Regards
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoPJrQACgkQmPuec2Dcv/+ZMwCeNp/rE8KTH0sNeVuDHQ1zeOuD
mtYAn0B6p8XlqT7oan9na/POHJ4LZ4qW
=JvQY
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/
Model is
just a stupid POJO and various plugins manipulate it with side
effects.
Sounds a little hacky to me but thats the way it is. So my
serialization
idea is nuts though.
Anyhow I think that if you have some information in memory, you
should
NOT have to write it to the disc so that someone else can copy (read
and write)
it again. I thought that you store the transformed XML in that new
string
attribute (was it alternativeRepresentation) so the Installer/
Deployer
could write this string if available instead of copying the
pom.xml as
is.
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
A big problem could be the encoding issue if you store XML in a
string
and then want to save it with some Writer, you need to know the
encoding
from the XML-header or you run into trouble.
My fix didn't store the XML in a string, it modified the DOM.
After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on
the new pom).
Yup. That is exactly what it does, except the fix currently doesn't
use ${project.build.directory} but just uses trunk. This needs to be
fixed. And as Brian mentioned it doesn't look at the -f option. If
those two issues are resolved then this fix would just need to be
integrated into the current 2.1 or 2.2 branch. You are welcome to
look at it and propose a way to fix those issues.
Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Also be aware that 2.1/2.2 already do some pom transformations, so this
would have to extend instead of replicate what's already there.
On Sat, May 16, 2009 at 5:14 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/Model is
just a stupid POJO and various plugins manipulate it with side effects.
Sounds a little hacky to me but thats the way it is. So my serialization
idea is nuts though.
Anyhow I think that if you have some information in memory, you should
NOT have to write it to the disc so that someone else can copy (read
and write)
it again. I thought that you store the transformed XML in that new
string
attribute (was it alternativeRepresentation) so the Installer/Deployer
could write this string if available instead of copying the pom.xml as
is.
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
A big problem could be the encoding issue if you store XML in a string
and then want to save it with some Writer, you need to know the encoding
from the XML-header or you run into trouble.
My fix didn't store the XML in a string, it modified the DOM.
After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on the
new pom).
Yup. That is exactly what it does, except the fix currently doesn't use
${project.build.directory} but just uses trunk. This needs to be fixed.
And as Brian mentioned it doesn't look at the -f option. If those two issues
are resolved then this fix would just need to be integrated into the current
2.1 or 2.2 branch. You are welcome to look at it and propose a way to fix
those issues.
Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Ralph Goers schrieb: They just shouldn't change things significantly without good arguments. Which are only the ones you agree with? I am really just trying to warn you about doing something dangerous. Mixing release versions with snapshot versions. The release plugin takes care of this - validation rules you want to bypass for whatever reason you may have. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. Thats all I am fighting for. No fighting required, just make a patch. If it's truly backwards compatible, then there wouldn't be much reason for it to be declined. I'm interested in the use cases because during training I run into this a lot. Generally if you can move your process to one that works with Maven then it's not an issue. If you can't, well then it is. I've got ideas for how to make the release process better, but not enough time to tackle it now. Just updating the tools to support ASF policy is keeping me busy enough. I searched JIRA: It was already requested in MNG-2576 so it seems the idea and usecase is common and therefor good. The issue is closed/fixed but I could NOT get it working... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNub8ACgkQmPuec2Dcv//RVQCgiqgQEvovdbDo+LHWBxbzOebn jUYAn0d4lIFFM1dTNa7A3dWeC1Q+OsgD =9QN4 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, By inheriting the version, groupId, etc. from the parent - yes. The release plugin still handles the pom transformations and the tagging (SCM URLs, snapshot to release version, release to next snapshot version, etc.) But there is nothing to change in the POM if the version is a variable. Maven will (as suggested in this thread - or also in my usecase via xslt-plugin) replace the variable when installing. All I need to change is one variable (e.g. in settings.xml). I do not need a releas-plugin for that but others may want to. I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. I would try splitting those steady modules from the rest of the structure since they seem to not share a common development/release cycle. I would even consider moving these to another svn repository. Without a real example to analyze, hard to tell. Once again: the release-plugin guys think in a specific way and there are others that have a different oppinion. For me the architecture of the system is the main criteria for structuring my pom-tree. Imagine that everybody makes it the way you describe because of release-plugin. The other day another cool plugin arises that forces you to structure your poms and scm by some other criteria. What if you want both plugins? I think it is a bad idea that a plugin gives a philosophy about how users should structure their project. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6 pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F =HnyW -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, By inheriting the version, groupId, etc. from the parent - yes. The release plugin still handles the pom transformations and the tagging (SCM URLs, snapshot to release version, release to next snapshot version, etc.) But there is nothing to change in the POM if the version is a variable. Maven will (as suggested in this thread - or also in my usecase via xslt-plugin) replace the variable when installing. All I need to change is one variable (e.g. in settings.xml). I do not need a releas-plugin for that but others may want to. I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. I would try splitting those steady modules from the rest of the structure since they seem to not share a common development/release cycle. I would even consider moving these to another svn repository. Without a real example to analyze, hard to tell. Once again: the release-plugin guys think in a specific way and there are others that have a different oppinion. For me the architecture of the system is the main criteria for structuring my pom-tree. Imagine that everybody makes it the way you describe because of release-plugin. The other day another cool plugin arises that forces you to structure your poms and scm by some other criteria. What if you want both plugins? I wouldn't say it's the release plugin that dictates the layout, its what makes sense in the scm. Generally you take a tree of things and tag it and release it. I think it is a bad idea that a plugin gives a philosophy about how users should structure their project. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6 pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F =HnyW -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stephen, If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT) which is subject to change... which means that a released pom does not have a definitive content... bad karma I agree and cant speak for Ralph, but I do NOT change versions (or anything else that is relevant for deploying) of container-modules at all. Why should I release a new version of my parent POMs if just some leave changed or even if some internal site-report-setting changed. People that want to use my deployed artifacts do NOT care about such changes. But in my case every developer always checks out the entire head (or tag/branch) of SCM. So there are different aspects of a deployed POM. If you ask me, all stuff like reporting, scm, issueManagement, distributionManagement, etc. is nuts for deployed POMs. But others may have a different view of the world. But this might be the point where we do not get together with relase-plugin. We simply have to accept that maven gives us flexibility to do things different ways and release-plugin maybe can NOT address all of these ways and thats just OK. -Stephen Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNxdIACgkQmPuec2Dcv/8SEgCgl/9Hnv5vfFAaRpz3noNdZuW1 x/IAn0AOXx3MSnC9xWvWFZKrZURU7OcR =aIQF -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Off topic. Actually I believe this isn't true anymore. See http://jira.codehaus.org/browse/MECLIPSE-344 all dependent artefacts that are available in your eclipse-workspace will be attached as project references even if they are not in the reactor. It was fixed in 2.5 Can you try it on your project structure and confirm? I know it works for me. I have this structure common projects - module cA ... - module cZ My project - module pA ... - module pZ (where some of these projects depend upon projects from commons) mvn eclipse:eclipse will make sure my module pA references the eclipse project for module cA (and not the jar of cA in the repo) Thanks for the hint! But only works if eclipse-plugin knows where my workspace is. The location may be different for each developer so I can NOT truly automate. Anyhow I will start using this. At least better solution than what I had before. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNxrQACgkQmPuec2Dcv/8VrQCdGu/eWpZnifkPYdW/u+6RqsKx +eMAnRv5/EHXo0895onKGsmExxxtoC70 =gj/Z -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think you are referring to one of the other patches that was submitted, not what I committed to the MNG-624 branch. MNG-624 or maven-2.1.x-MNG-624 ? A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. My fix didn't store the XML in a string, it modified the DOM. OK. But the existing parsing is done by XPP right? Do we want parsing the POMs twice with different parsers? Is there some general strategy decision about POM-transformation design by the core developers of maven? Do Brett and Jason care about this? Sorry for the stupid question, but your patch/branch seems to be the second solution so this means to me that the first has failed already. I now see that is was Eric Brown who wasted his time already and he seemed somewhat disappointed. As the problem of doing a POM-transformation which is NOT only relevant for MNG-624 is quite general. So I just want to avoid that the second approach will fail again. I would not mind to invest some of my very little time as well in this but only if there is a clear chance that we are going towards a solution that fits well into the architecture of maven and will therefore be accepted to be integrated in 2.1.x. Ralph Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66 vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku =xUpi -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Fri, May 15, 2009 at 4:10 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think you are referring to one of the other patches that was submitted, not what I committed to the MNG-624 branch. MNG-624 or maven-2.1.x-MNG-624 ? A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. My fix didn't store the XML in a string, it modified the DOM. OK. But the existing parsing is done by XPP right? Do we want parsing the POMs twice with different parsers? Is there some general strategy decision about POM-transformation design by the core developers of maven? Do Brett and Jason care about this? Sorry for the stupid question, but your patch/branch seems to be the second solution so this means to me that the first has failed already. I now see that is was Eric Brown who wasted his time already and he seemed somewhat disappointed. As the problem of doing a POM-transformation which is NOT only relevant for MNG-624 is quite general. So I just want to avoid that the second approach will fail again. I would not mind to invest some of my very little time as well in this but only if there is a clear chance that we are going towards a solution that fits well into the architecture of maven and will therefore be accepted to be integrated in 2.1.x. Your better bet will be to try and get this documented so it can be implemented in 3.x. Ralph Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66 vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku =xUpi -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Your better bet will be to try and get this documented so it can be implemented in 3.x. I would surely NOT mind. What do you expect? A new xdoc? Or a diff to the actual source of http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Content somewhat like the level of detail in MNG-4161 but with nice examples? Do you need simple IT-projects that I shall attach to MNG-4161 and related? Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoN0p4ACgkQmPuec2Dcv/8TnwCfRZXQ8Wz1OOMwq4B8MXKanWyo 4qUAn0vYofuQCDUjS+PjOQ46VvgfpUUN =GiG2 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Your better bet will be to try and get this documented so it can be implemented in 3.x. no change to see some improvement about version maintenance in 2.x? See the list of issues I just posted and also look at the votes. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoN0zkACgkQmPuec2Dcv/+QagCgiQd4XEKgBWh4c98TkflW3Bek 2GcAnRdoBJSi3wWoLHEA6jJB3N8pvSAr =l02j -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Do you need simple IT-projects that I shall attach to MNG-4161 and related? Sample ITs for sure, and some level of detail in a proposal like these: http://docs.codehaus.org/display/MAVENUSER/User+Proposals
Re: Progress on support for large projects
On May 15, 2009, at 1:10 PM, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think you are referring to one of the other patches that was submitted, not what I committed to the MNG-624 branch. MNG-624 or maven-2.1.x-MNG-624 ? I think it was maven-2.1.x-MNG-624. Its been a long time since I worked on this. A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. My fix didn't store the XML in a string, it modified the DOM. OK. But the existing parsing is done by XPP right? I believe so. Do we want parsing the POMs twice with different parsers? Is there some general strategy decision about POM-transformation design by the core developers of maven? Maven 2.x is a mess with this. It is one of the things I believe they worked really hard to change in Maven 3. Again, I haven't reviewed the new code so I don't know how successful they were. Do Brett and Jason care about this? Everybody cares about this. The way Maven 2.x was implemented is very brittle. Almost every change made to the project builder ends up having nasty side effects. Sorry for the stupid question, but your patch/branch seems to be the second solution so this means to me that the first has failed already. I now see that is was Eric Brown who wasted his time already and he seemed somewhat disappointed. As the problem of doing a POM-transformation which is NOT only relevant for MNG-624 is quite general. So I just want to avoid that the second approach will fail again. I would not mind to invest some of my very little time as well in this but only if there is a clear chance that we are going towards a solution that fits well into the architecture of maven and will therefore be accepted to be integrated in 2.1.x. I seemed to be the only committer interested in fixing these issues. I did not like Eric's patch because it added logic the the artifact handler that it had no business knowing about. As I recall I documented my reasons in one of the Jira issues. You have to understand that although the problem might seem trivial, fixes for problems like this can't break existing builds. That makes even the simplest fix challenging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
You have to understand that although the problem might seem trivial, fixes for problems like this can't break existing builds. That makes even the simplest fix challenging. Not only that, it needs to cooperate with other functionality... just like we found with the previous patch. It would work in some cases but it couldn't function if the build.outputDirectory was changed. (or -f was used for a different pom name).
Re: Progress on support for large projects
Ralph Goers schrieb: On May 13, 2009, at 5:09 PM, Christian Schulte wrote: Ralph Goers schrieb: So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. What stops a developer from making changes to A(1.0) on trunk, rebuilding locally - that is - overwriting release artifacts with something different in the local repository, and then later on even commit those changes forgetting to increase the version to a snapshot ? Discipline ? Actually, this isn't at all the way we do releases. This was my response to David's hypothetical scenario which didn't make any sense to me. All I did was clean it up. What we actually do looks more like: +tags +library-1.0.0 (on branch-library-1.0) pom version is 1.0.0 +A(1.0.0) +B(1.0.0) +C(1.0.0) +library-1.0.1 (on branch-library-1.0) pom version is 1.0.1 +A(1.0.0) +B(1.0.1) +C(1.0.0) +library-1.1.0 (on branch-library-1.1) pom version is 1.1.0 +A(1.0.0) +B(1.1.0) +C(1.1.0) +branches +branch-library-1.0 (pom is still 1.0.1 - no work in progress on branch) +A(1.0.0) +B(1.0.0) +C(1.0.0) +branch-library-1.1 (pom is 1.1.0-SNAPSHOT) (work in progress) +A(1.0.0) +B(1.1.0) +C(1.1.1-SNAPSHOT) /trunk (library-1.2-SNAPSHOT) (Work in progress) +A(1.1.0-SNAPSHOT) (new work) +B(1.1.0) +C(1.2.0-SNAPSHOT) (work from branch-library-1.1 has been merged) The point here is not to debate the right or wrong way to manage projects. It is what it is and it accomplishes our goals. The issue is that the release plugin (at least the last time I reviewed it) mandates that there is only one right way to do a release. As the debate on Legal discuss last week shows this isn't necessarily the case. I would suggest that the release plugin almost needs a lifecycle of its own where the actual work is accomplished through plugins. If things have changed significantly let me know and I'd be happy to look at it again. Ralph Some developers of the release-manager can better answer this. The release manager uses its own phases internally, I think. http://svn.apache.org/viewvc/maven/release/tags/maven-release-2.0-beta-9/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ Hooking something in there may already be possible easily but I don't know for sure. My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that. So a developer would at least have to ask someone for permission to do so. I just don't get the point for what all this additional effort is good for. Really only to not release artifacts whose code did not change ? As I see it, that only introduces additional complexity without any advantage. Indeed it introduces some disadvantages every developer must be made aware of and you cannot use quite well working maven tooling that way. Not because this tooling behaves wrong, IMHO. The same applies to automatically discovering the parent pom. That's constantly changing artifacts without anyone noticing it, somehow. At least in all local repositories. It does not matter if there are any code changes. Changing poms is the same as changing code, IMHO. I would just say that it takes less than a week until every developer has its own releases in the local repository and noticing that is really not that easy. For me such setup would not work at all since the CI server not only builds artifacts whenever someone committed something, but forcibly runs builds every few days or so. So for me that would just mean that the CI server would constantly deploy differing release artifacts. Even worse, those release artifacts contain a reference to a snapshot parent pom which introduces additional problems. Non-reproducible. Don't get me wrong. I still think you have really good reasons for doing things the way they are done. I just don't get it. I don't even see a single advantage but a lot of disadvantages. I am not saying that there may not be any advantages. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chistian, What stops a developer from making changes to A(1.0) on trunk, rebuilding locally - that is - overwriting release artifacts with something different in the local repository, and then later on even commit those changes forgetting to increase the version to a snapshot ? Discipline ? Simply at a pre-commit hook that only allows to commit pom.xml in some tree that has a non-snapshot version. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoMj8AACgkQmPuec2Dcv/+KugCgiacqSwnZayMjGJa8ZxT05Gtt zJ8Ani67Nf5LSK8u9dww8XpDaFcSepN9 =kKR3 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Christian, My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that. So a developer would at least have to ask someone for permission to do so. I just don't get the point for what all this additional effort is good for. Really only to not release artifacts whose code did not change ? As I see it, that only introduces additional complexity without any advantage. I totally disagree. If your project is large and maybe offers components that will be used by others, you can get into version conflicts and will cause a lot of overhead in the repos. Anyways if you say it is just additional complexity and you should always release everything, then why do you have individual versions per module at all? Simply use one variable in every module and your process is so simple that there is no need for release-plugin anymore at all. I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. Indeed it introduces some disadvantages every developer must be made aware of and you cannot use quite well working maven tooling that way. Not because this tooling behaves wrong, IMHO. The same applies to automatically discovering the parent pom. That's constantly changing artifacts without anyone noticing it, somehow. At least in all local repositories. It does not matter if there are any code changes. Changing poms is the same as changing code, IMHO. I would just say that it takes less than a week until every developer has its own releases in the local repository and noticing that is really not that easy. For me such setup would not work at all since the CI server not only builds artifacts whenever someone committed something, but forcibly runs builds every few days or so. So for me that would just mean that the CI server would constantly deploy differing release artifacts. Even worse, those release artifacts contain a reference to a snapshot parent pom which introduces additional problems. Non-reproducible. Why? In SCM there should never be a non-snapshot module with snapshot dependencies. Further a non-snapshot module should not be modified except for pom.xml Don't get me wrong. I still think you have really good reasons for doing things the way they are done. I just don't get it. I don't even see a single advantage but a lot of disadvantages. I am not saying that there may not be any advantages. OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. Thats all I am fighting for. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoMkq4ACgkQmPuec2Dcv/9CxgCfXlKe4c7C0QtVPKY1kW4iUzQH IZ0AoJA//ENI/jHk000ELe3oN73g5nyW =zvjI -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. Thats all I am fighting for. No fighting required, just make a patch. If it's truly backwards compatible, then there wouldn't be much reason for it to be declined. I'm interested in the use cases because during training I run into this a lot. Generally if you can move your process to one that works with Maven then it's not an issue. If you can't, well then it is. I've got ideas for how to make the release process better, but not enough time to tackle it now. Just updating the tools to support ASF policy is keeping me busy enough.
Re: Progress on support for large projects
Ask someone why you have to invoke eclipse:eclipse on toplevel everytime. If the dependency of some-module has changed, you can NOT invoke eclipse:eclipse just on some-module since the plugin then wants to resolve the dependencies from the repository and adds JAR-Dependencies to the IDE project. Off topic. Actually I believe this isn't true anymore. See http://jira.codehaus.org/browse/MECLIPSE-344 all dependent artefacts that are available in your eclipse-workspace will be attached as project references even if they are not in the reactor. It was fixed in 2.5 Can you try it on your project structure and confirm? I know it works for me. I have this structure common projects - module cA ... - module cZ My project - module pA ... - module pZ (where some of these projects depend upon projects from commons) mvn eclipse:eclipse will make sure my module pA references the eclipse project for module cA (and not the jar of cA in the repo) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Joerg Hohwiller schrieb: Hi Christian, My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that. So a developer would at least have to ask someone for permission to do so. I just don't get the point for what all this additional effort is good for. Really only to not release artifacts whose code did not change ? As I see it, that only introduces additional complexity without any advantage. I totally disagree. If your project is large and maybe offers components that will be used by others, you can get into version conflicts and will cause a lot of overhead in the repos. Anyways if you say it is just additional complexity and you should always release everything, then why do you have individual versions per module at all? If the parent is released every time just a single module is, _then_ I suggest releasing all modules with that parent together. Simply use one variable in every module and your process is so simple that there is no need for release-plugin anymore at all. By inheriting the version, groupId, etc. from the parent - yes. The release plugin still handles the pom transformations and the tagging (SCM URLs, snapshot to release version, release to next snapshot version, etc.) I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. I would try splitting those steady modules from the rest of the structure since they seem to not share a common development/release cycle. I would even consider moving these to another svn repository. Without a real example to analyze, hard to tell. Indeed it introduces some disadvantages every developer must be made aware of and you cannot use quite well working maven tooling that way. Not because this tooling behaves wrong, IMHO. The same applies to automatically discovering the parent pom. That's constantly changing artifacts without anyone noticing it, somehow. At least in all local repositories. It does not matter if there are any code changes. Changing poms is the same as changing code, IMHO. I would just say that it takes less than a week until every developer has its own releases in the local repository and noticing that is really not that easy. For me such setup would not work at all since the CI server not only builds artifacts whenever someone committed something, but forcibly runs builds every few days or so. So for me that would just mean that the CI server would constantly deploy differing release artifacts. Even worse, those release artifacts contain a reference to a snapshot parent pom which introduces additional problems. Non-reproducible. Why? In SCM there should never be a non-snapshot module with snapshot dependencies. Further a non-snapshot module should not be modified except for pom.xml /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and root(1.2-SNAPSHOT) declares a dependency management with snapshot versions and A(1.0) declares a dependency without an explicit version, than A(1.0) may start depending on a snapshot. If you do 'mvn deploy' at root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release repository, everything else to the snapshot repository. OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. They just shouldn't change things significantly without good arguments. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 14, 2009, at 9:18 PM, Christian Schulte wrote: Why? In SCM there should never be a non-snapshot module with snapshot dependencies. Further a non-snapshot module should not be modified except for pom.xml /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and root(1.2-SNAPSHOT) declares a dependency management with snapshot versions and A(1.0) declares a dependency without an explicit version, than A(1.0) may start depending on a snapshot. If you do 'mvn deploy' at root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release repository, everything else to the snapshot repository. Which is exactly why the deploy plugin should never redeploy something that is already in a release repository. It is ALWAYS wrong, even in a scenario where you rely on the release plugin to do its magic. Actually, in the case above since the parent pom is a SNAPSHOT the deploy should just ignore any modules that aren't snapshots. OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. They just shouldn't change things significantly without good arguments. Which are only the ones you agree with? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
2009/5/15 Christian Schulte c...@schulte.it Joerg Hohwiller schrieb: Why? In SCM there should never be a non-snapshot module with snapshot dependencies. Further a non-snapshot module should not be modified except for pom.xml /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and root(1.2-SNAPSHOT) declares a dependency management with snapshot versions and A(1.0) declares a dependency without an explicit version, than A(1.0) may start depending on a snapshot. If you do 'mvn deploy' at root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release repository, everything else to the snapshot repository. If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT) which is subject to change... which means that a released pom does not have a definitive content... bad karma -Stephen
Re: Progress on support for large projects
Ralph Goers schrieb: On May 12, 2009, at 9:30 PM, Christian Schulte wrote: Ralph Goers schrieb: Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go with it. a) You want all the projects to be part of the build to be sure that they all work together. Even though some projects didn't change, running the unit tests will help identify any compatibility problems. If an artifact did not change, those tests will always yield the same results as during the release of that artifact. By did not change I assume that not only the source code did not change, also the pom and everything else also did not change. Maven did not change, not a single Maven plugin changed, no dependency, etc. This assumption is incorrect. All the projects in the library use other parts of the library, just as commons projects use other commons projects. Because a project does not specify the version of the project it depends on but obtains it from the bom pom the dependency will change with the new release. Ok. No code changes but the artifact and you don't want to release without actual code changes. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Tue, May 12, 2009 at 11:01 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Milos, relying on the reactor and giving up on being able to build the one project separately is very bad (read: completely breaks) any IDE integration. I totally disagree. I am successfully using maven-eclipse-plugin (mvn eclipse:eclipse) and this works perfectly with Eclipse except if you do a lot of filtering. The suggested approach would have no influence on my IDE, omitted versions would become inter-project-dependencies in eclipse and everything is fine. mvn eclipse:eclipse does perform a build (partially) and might even produce 1 eclipse project for multiple maven projects (correct me if I'm wrong) In NetBeans (IDE I use and develop maven integration for) no build is performed and we rely entirely on maven metadata when it comes to project representation. Doing a build is out of questions, opening of projects would be too slow. And it's a perfectly sound to assume that one wants to open just a single maven project from apache geronimo codebase without actually building the 200+ multiproject. Even with brutal performance hacks the 200 projects take about 10 minutes to open, while the single project is just a snap. I'm not sure what the auto-reactor feature in eclipse does, but in general and especially for large projects it's hard to figure automatically what the reactor is.. is it just the geronomo plugins pom, or we need all of geronimo, or just geronimo aspectj plugin parent? if you are the geronimo dev you might know, but will everyone figure that out? Milos I tried m2eclipse and iam about 20 times and always gave up, because they were simply NOT able to run my project. E.g. I have source/target set to 1.5 for compiler-plugin but require 1.6 for development. m2eclipse thinks that it needs to replace 1.6 with 1.5 wenn I do m2 enable of my project. However if all the bugs of these plugins would be fixed, and the auto-reactor feature was working, everything could be fine as well together with the suggested feature. One day there will be eclipse 4.x and support multi-projects so the entire project (and its reactor) can be managed as a whole. I heard this already works for idea. Milos Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ47EACgkQmPuec2Dcv//5iACfc1jnc4F33uoOKQ/JFKO8IUuP x5sAn2m0GO5n32Uz+r0C1Fa23x1PjXxx =zmBx -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 7:02 PM, Ralph Goers wrote: On May 12, 2009, at 6:20 PM, David Jencks wrote: On May 12, 2009, at 3:43 PM, Ralph Goers wrote: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a bill of materials (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my library isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. I'm fairly mystified how what you and Jorg appear to want could work with any of the scm systems I know about, that tag an entire file system subtree at once. Maybe I don't understand what you guys are talking about at all. here's what I think you want: file system structure showing projects +root +A +B +C ... +D Probably Jorg has further nesting, but I don't think that actually affects the argument. Projects A, C, E, G,... need to be released right now, whereas projects B, D, F... are just fine and don't need releases. IIUC you guys are supposing a parent pom for all these projects in root and want to be able to run a release on root and have the effect be to release just A, C, E, G and the root pom. No. The root represents the library. The release is of the library, not the individual subprojects. I just don't want new versions created for subprojects that didn't change. So if you run a release on root the entire tree will get tagged including B, D, F etc that you didn't want tagged. Actually, I do want them tagged. The bill of materials represents a release of the whole library. It is just that some of the artifacts in the library didn't change. But they should all be part of the release tag. So I think what you want to do is have a quick way to run releases on A,C,E,G,... and have each of those tagged individually and not tag the whole tree at once. No. See above. My impression is that what you are fighting is the scm system, not maven. No. The SCM isn't a problem. However, mvn deploy will try to deploy artifacts that haven't changed since the last release. That is bad. Nexus should be able to silently ignore those or the deployer should somehow be able to detect that the artifact shouldn't be deployed. I'm even more mystified and understand how you want to use scm even less. One of the basic principles I have for scm is that stuff shouldn't be duplicated, in the sense that if some artifact is released at version 1.2.3.4 say, the scm location for that release can be found in only one, unique, place in the scm tree, such as an svn tag. Now if I understand what you are proposing, its to have +root(1.2-SNAPSHOT) +A(1.1-SNAPSHOT) +B(1.3-SNAPSHOT) Only B has changed since the last release, which was of root (1.1), A(1.1) and B(1.2); these are the version in the release tag. So you tag this after arranging the new release versions. You new tag has root(1.2), A(1.1) and B(1.3), and trunk has root(1.3-SNAPSHOT), A(1.1-SNAPSHOT) and B(1.4-SNAPSHOT) The problem I have with this is that A(1.1) is present in two different tags, violating the uniqueness principle I hold to. Have I yet again misunderstood the actions you want to take during release or do you think the uniqueness principle is not worth following? If I've misunderstood again, could you provide a more concrete example with versions and contents of tags to help me understand? thanks david jencks Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 12:53 AM, David Jencks wrote: I'm even more mystified and understand how you want to use scm even less. One of the basic principles I have for scm is that stuff shouldn't be duplicated, in the sense that if some artifact is released at version 1.2.3.4 say, the scm location for that release can be found in only one, unique, place in the scm tree, such as an svn tag. Now if I understand what you are proposing, its to have +root(1.2-SNAPSHOT) +A(1.1-SNAPSHOT) +B(1.3-SNAPSHOT) Only B has changed since the last release, which was of root (1.1), A(1.1) and B(1.2); these are the version in the release tag. If B is the only thing that has changed then you would have: +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) In this case two artifacts would be deployed during the release: 1. The library bom pom (which, in this case, is the pom in root) for version 1.2. 2. The artifact for B 1.3 A 1.0 is part of the tag, is built and tested during the build, but is not redeployed to the repository. After the release the scm will contain: +root(1.2) +A(1.0) +B(1.3) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 7:02 AM, Ralph Goers wrote: On May 13, 2009, at 12:53 AM, David Jencks wrote: I'm even more mystified and understand how you want to use scm even less. One of the basic principles I have for scm is that stuff shouldn't be duplicated, in the sense that if some artifact is released at version 1.2.3.4 say, the scm location for that release can be found in only one, unique, place in the scm tree, such as an svn tag. Now if I understand what you are proposing, its to have +root(1.2-SNAPSHOT) +A(1.1-SNAPSHOT) +B(1.3-SNAPSHOT) Only B has changed since the last release, which was of root (1.1), A(1.1) and B(1.2); these are the version in the release tag. If B is the only thing that has changed then you would have: +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) In this case two artifacts would be deployed during the release: 1. The library bom pom (which, in this case, is the pom in root) for version 1.2. 2. The artifact for B 1.3 A 1.0 is part of the tag, is built and tested during the build, but is not redeployed to the repository. After the release the scm will contain: +root(1.2) +A(1.0) +B(1.3) Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... - development will continue after the release - therefore the version in trunk must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 - there is no plausible version for trunk/root/A - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, [cut.] Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... - development will continue after the release - therefore the version in trunk must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 - there is no plausible version for trunk/root/A - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? Like Ralph, I have no problem with my scm (which is indeed svn). I also want to maintain versions of modules and have the problems that when I change a version I typically have to change this in all other POMs pointing to the module that changed version. Besiders there can be excuses where a dependency version remains unchanged, so no automatism that release-plugin could guess. And I want to keep modules unchanged in the tree. In my case they would NOT have to be rebuild but that does NOT matter to me. Maintaining these redundant versions is hell if you do it by hand. I have some hacky tools but it could be so easy if you could just omit the version in the dependencies of my local pom.xml's. To answer the SCM-structure question: There maybe some good conventions but SVN gives you a lot of flexibility in whatever you do. I personally always have a flat list of all my modules in tags and then have the according module copied (tagged) there named by its version. I never think that release-plugin has to deal with all possible ways that users can do their release-management. It has to go some way and there will always be people that want it different so I think the release-plugin is NOT the magic answer to all of our problems. thanks david jencks Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLGWUACgkQmPuec2Dcv/9MggCbBGoMTwZOct1/WiOBUjPmUoxa SQYAn2+uQ6MPAWWSSuUPyX9oK0wtr9hV =YdFZ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Milos, mvn eclipse:eclipse does perform a build (partially) and might even produce 1 eclipse project for multiple maven projects (correct me if I'm wrong) No it does not. But I hope it will one finest day. And it will definitely do NOT compile or invoke tests. All it does is invoking phases for code-generation. In NetBeans (IDE I use and develop maven integration for) no build is performed and we rely entirely on maven metadata when it comes to project representation. Doing a build is out of questions, opening of projects would be too slow. And it's a perfectly sound to assume that one wants to open just a single maven project from apache geronimo codebase without actually building the 200+ multiproject. I am absolutely with you that you do NOT want to build entire geronimo if just one module changes. What I was thinking about is that if mvn somegoal is invoked in module some-module maven scans the pom.xml of some-module. Currently it resolves all parents up to toplevel starting from some-module. What it does NOT do is to go down from toplevel and scan (NOT build!) recursively the entire project tree so all modules are available to maven's internals (that what I named the reactor) but that does NOT mean, that the goal is invoked on all of the modules but still only on some-module. But now the invoked plugins could resolve what other-module in the tree is about. I was suggesting to have this feature disabled by default but have a command-line option to enable this. Ask someone why you have to invoke eclipse:eclipse on toplevel everytime. If the dependency of some-module has changed, you can NOT invoke eclipse:eclipse just on some-module since the plugin then wants to resolve the dependencies from the repository and adds JAR-Dependencies to the IDE project. Further ask someone why you can not build some-module if it depends on other-module but thats not already installed. It can be on the local disc and the knowledge how to build some-module is available to maven but it is simply too stupid to do it. You have to go and invoke install on other-module yourself and then on some-module afterwards. Now try to explain this to somebody new to maven. Next there might be some tests that fail in other-module so you cant install it but still want to build some-module. Even with brutal performance hacks the 200 projects take about 10 minutes to open, while the single project is just a snap. Surely. I'm not sure what the auto-reactor feature in eclipse does, Maybe my post was missleading, but I was talking about a vision not about what already works. but in general and especially for large projects it's hard to figure automatically what the reactor is.. is it just the geronomo plugins pom, or we need all of geronimo, or just geronimo aspectj plugin parent? if you are the geronimo dev you might know, but will everyone figure that out? Well let me say so. I am suggesting a new feature to maven that is 100% downward compatible. Nobody has to use it if he does NOT like it. But it would solve the problems of many users and make maven even better. Milos Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLHgoACgkQmPuec2Dcv/+L0gCZAfkMoCLgf8608h4vKxmGka7C F0MAnRoehAtfciJHGFSFdyQLDI/cWCyi =CpO/ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralph, I've been promised by Jason that the work on Maven 3 is going to fix some of these issues. I simply haven't had the time to look at the work on Maven 3 and even if I had, it has been changing at a fairly rapid pace for months. While, in principal, Maven's processing is pretty simple - it just collects artifacts and runs plugins - the reality is that there are lots of side effects and timing issues. OK. The fix needed to address 2 things; determining the parent pom version and resolving variables so that when the pom is deployed to the repository the pom isn't ambiguous. That does not include resolving variables in dependencies because those are actually OK to not be locked down in the repo. Unfortunately, once the pom is processed it is impossible to use the Maven Model object to create a new pom. It contains lots of information that wasn't in the original pom that shouldn't be in the pom deployed to a repository. The fix I did took care of this effectively. Writing it to an alternate directory and then telling maven where it was meant that the artifact deployer didn't need any changes at all. Okay. So thats what I guessed when I said that the MavenProject/Model is just a stupid POJO and various plugins manipulate it with side effects. Sounds a little hacky to me but thats the way it is. So my serialization idea is nuts though. Anyhow I think that if you have some information in memory, you should NOT have to write it to the disc so that someone else can copy (read and write) it again. I thought that you store the transformed XML in that new string attribute (was it alternativeRepresentation) so the Installer/Deployer could write this string if available instead of copying the pom.xml as is. A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. Ralph Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLIHwACgkQmPuec2Dcv//OawCfTCpa29oxzE68SoadDl2pYOC2 uAsAn1/+M2rOHg+UlrklPJRabJD7oK6s =YnIP -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 10:41 AM, David Jencks wrote: Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... Your assumptions are not completely correct. a) In our case a release is aways off a branch. This isn't particularly relevant to the discussion but it does make production maintenance easier so I'll ignore it. b) tagging doesn't create a copy of anything. It just is a label that is a shortcut to a revision on a branch. Multiple tags that point to the same revision are not a problem and don't incur much overhead. So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. - development will continue after the release - therefore the version in trunk must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. See above. While the tag applies to the whole subtree, no copy is made. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 No. There are multiple tags that all point to the same subversion revision. This is not a problem. - there is no plausible version for trunk/root/A ? If A has not been changed its version is still 1.0. If it has then it is 1.1-SNAPSHOT. - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) Why would you allow a branch that matches a tag? If I was going to allow a branch to be created named root-1.2 then I would require that all tags be named root-1.2.n. If I did that then I would have +tags +root-1.0.0 (trunk revision 1) +A(1.0.0) +B(1.0.0) +root-1.1.0 (trunk revision 2) +A(1.0.0) +B(1.1.0) +root-1.2.0 (root-1.2 revision 3) +A(1.0.0) +B(1.2.0) /root-1.0 (branched from trunk at revision 1) +A(1.0.0) +B(1.0.0) /root-1.1 (branched from trunk at revision 2) +A(1.0.0) +B(1.1.0) /root-1.2 (branched from trunk at revision 3) +A(1.0.0) +B(1.2.0) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? I'm not proposing anything. I'm just explaining what this particular project has been doing for the last 5 years and why Maven 2 is a PITA in this regard. Maven 1 was actually easier for this particular project. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 12:33 PM, Joerg Hohwiller wrote: Okay. So thats what I guessed when I said that the MavenProject/ Model is just a stupid POJO and various plugins manipulate it with side effects. Sounds a little hacky to me but thats the way it is. So my serialization idea is nuts though. Anyhow I think that if you have some information in memory, you should NOT have to write it to the disc so that someone else can copy (read and write) it again. I thought that you store the transformed XML in that new string attribute (was it alternativeRepresentation) so the Installer/Deployer could write this string if available instead of copying the pom.xml as is. I think you are referring to one of the other patches that was submitted, not what I committed to the MNG-624 branch. A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. My fix didn't store the XML in a string, it modified the DOM. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 12:55 PM, Ralph Goers wrote: On May 13, 2009, at 10:41 AM, David Jencks wrote: Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... Your assumptions are not completely correct. a) In our case a release is aways off a branch. This isn't particularly relevant to the discussion but it does make production maintenance easier so I'll ignore it. b) tagging doesn't create a copy of anything. Maybe on the svn server that's true, but I'd never know it from the client view I get by svn co, svn up, etc. It just is a label that is a shortcut to a revision on a branch. Multiple tags that point to the same revision are not a problem and don't incur much overhead. I really don't care how much trouble releasing stuff causes infra disc purchase procedures :-) So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. So, we seem to have different views on acceptable ways to use svn. If I was involved in such a project I would kick and scream until - each release came from a single clearly identifiable scm location (violated by multiple tags for A(1.0), and the presence of A(1.0) in trunk) - trunk contained only SNAPSHOT version (except possibly while someone is actually doing a release -- behavior of the release plugin I'm not thrilled with) (violated by A(1.0) in trunk). or I gave up and forked it. I could be completely misguided in this, but it's my current viewpoint. - development will continue after the release - therefore the version in trunk must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. See above. While the tag applies to the whole subtree, no copy is made. From the point of view of what you get on a client machine, I don't understand this. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 No. There are multiple tags that all point to the same subversion revision. This is not a problem. Apparently we disagree on this. - there is no plausible version for trunk/root/A ? If A has not been changed its version is still 1.0. If it has then it is 1.1-SNAPSHOT. Again we disagree on whether this is acceptable. - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) Why would you allow a branch that matches a tag? If I was going to allow a branch to be created named root-1.2 then I would require that all tags be named root-1.2.n. If I did that then I would have +tags +root-1.0.0 (trunk revision 1) +A(1.0.0) +B(1.0.0) +root-1.1.0 (trunk revision 2) +A(1.0.0) +B(1.1.0) +root-1.2.0 (root-1.2 revision 3) +A(1.0.0) +B(1.2.0) /root-1.0 (branched from trunk at revision 1) +A(1.0.0) +B(1.0.0) /root-1.1 (branched from trunk at revision 2) +A(1.0.0) +B(1.1.0) /root-1.2 (branched from trunk at revision 3) +A(1.0.0) +B(1.2.0) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? I'm not proposing anything. I'm just explaining what this particular project has been doing for the last 5 years and why Maven 2 is a PITA in this regard. Maven 1 was actually easier for this particular project. This process may work fine for the project in question and you in other circumstances, but would keep me from contributing no matter what build tool was in use. Here, the release plugin seems to me to strongly promote good scm practices. The only think I'd like to see is, given a setup like trunk (has no pom) +parent-pom +P1 +P2 +P1000 an easy way to release all the, say, odd numbered projects at once rather than running the release plugin on each one independently. Anyway, I really appreciate your taking the time to explain your point of view to me. While I
Re: Progress on support for large projects
Ralph Goers schrieb: So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. What stops a developer from making changes to A(1.0) on trunk, rebuilding locally - that is - overwriting release artifacts with something different in the local repository, and then later on even commit those changes forgetting to increase the version to a snapshot ? Discipline ? -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 13, 2009, at 5:09 PM, Christian Schulte wrote: Ralph Goers schrieb: So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. What stops a developer from making changes to A(1.0) on trunk, rebuilding locally - that is - overwriting release artifacts with something different in the local repository, and then later on even commit those changes forgetting to increase the version to a snapshot ? Discipline ? Actually, this isn't at all the way we do releases. This was my response to David's hypothetical scenario which didn't make any sense to me. All I did was clean it up. What we actually do looks more like: +tags +library-1.0.0 (on branch-library-1.0) pom version is 1.0.0 +A(1.0.0) +B(1.0.0) +C(1.0.0) +library-1.0.1 (on branch-library-1.0) pom version is 1.0.1 +A(1.0.0) +B(1.0.1) +C(1.0.0) +library-1.1.0 (on branch-library-1.1) pom version is 1.1.0 +A(1.0.0) +B(1.1.0) +C(1.1.0) +branches +branch-library-1.0 (pom is still 1.0.1 - no work in progress on branch) +A(1.0.0) +B(1.0.0) +C(1.0.0) +branch-library-1.1 (pom is 1.1.0-SNAPSHOT) (work in progress) +A(1.0.0) +B(1.1.0) +C(1.1.1-SNAPSHOT) /trunk (library-1.2-SNAPSHOT) (Work in progress) +A(1.1.0-SNAPSHOT) (new work) +B(1.1.0) +C(1.2.0-SNAPSHOT) (work from branch-library-1.1 has been merged) The point here is not to debate the right or wrong way to manage projects. It is what it is and it accomplishes our goals. The issue is that the release plugin (at least the last time I reviewed it) mandates that there is only one right way to do a release. As the debate on Legal discuss last week shows this isn't necessarily the case. I would suggest that the release plugin almost needs a lifecycle of its own where the actual work is accomplished through plugins. If things have changed significantly let me know and I'd be happy to look at it again. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Are you using the release plugin? Nope! I tried it and came to the point that is no good for me. I also had a discussion with the developers long time ago and filed some feature request. Anyhow I still think this is the wrong approach for me. Can you give more details about what doesn't work or doesn't match your process? E.g. it tried to convince me to release all modules of my entire project and complained if some module had a non SNAPSHOT version. [cut.] The new reactor modes are in 2.1.0 that can do some similar things. [cut.] Some of this is already done in 2.1.0 Great to hear that. Please give me some hint (weblink, example or whatever) to get started with this. Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ4coACgkQmPuec2Dcv//ZqACgkQiOIFbclxDb1A/cZr1JjyiX P4IAn2OiW+XcJizxnzYmmXRzsusBx/7n =AinT -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Milos, relying on the reactor and giving up on being able to build the one project separately is very bad (read: completely breaks) any IDE integration. I totally disagree. I am successfully using maven-eclipse-plugin (mvn eclipse:eclipse) and this works perfectly with Eclipse except if you do a lot of filtering. The suggested approach would have no influence on my IDE, omitted versions would become inter-project-dependencies in eclipse and everything is fine. I tried m2eclipse and iam about 20 times and always gave up, because they were simply NOT able to run my project. E.g. I have source/target set to 1.5 for compiler-plugin but require 1.6 for development. m2eclipse thinks that it needs to replace 1.6 with 1.5 wenn I do m2 enable of my project. However if all the bugs of these plugins would be fixed, and the auto-reactor feature was working, everything could be fine as well together with the suggested feature. One day there will be eclipse 4.x and support multi-projects so the entire project (and its reactor) can be managed as a whole. I heard this already works for idea. Milos Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ47EACgkQmPuec2Dcv//5iACfc1jnc4F33uoOKQ/JFKO8IUuP x5sAn2m0GO5n32Uz+r0C1Fa23x1PjXxx =zmBx -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralph, Hi there, absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? This problem probably goes away for anyone able to use the release plugin, but only because the release plugin does all the work, not because the need for the work goes away. If, for whatever reason, you can't use the release plugin, then this is a real pain. Yep, I am having this pain and I now dozens of others that have the same problems. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. Actually, the guys I work with started to complain about this again last week and want me to fix it. They suggested that rather than tackling both accepting a missing parent version and fixing the pom so that the pom written to the repository is fully resolved (i.e. the parent version is present in the deployed pom) that just accepting the missing parent would be enough. I'm not sure, but I'd be willing to look at it. I'm also not sure how much things have changed since I created the branch. I'll have to check. I have read your comments. Well thanks so far for all your work and invest. I hope you have NOT lost your faith ;) The only real problem with what was on the MNG-624 branch was that it requires a place to create the resolved pom.xml. To do that it assumed a hardcoded location of target. If a parent pom redefines the build directory (it seems really odd to me that this is even allowed) then this is wrong. But trying to find the definition of the target variable requires looking at every parent, even if it isn't local, which is something I was trying to avoid. I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de-serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. Anyone is free to look at the branch and improve on it. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Yes, the fix in MNG-624 does a really good job of this. So your patch also resolves variables and NOT only in parent but also in dependencies-section? Havent seen that... However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Where we are in this is that I have been totally booked writing code for other projects - mostly commons VFS and commons configuration. I have the same problem. The main reason why I am here is because I am using maven in all my other OSS-projects and I love it but sometimes I also hate it and hope that the tiny parts that are not already perfect will go away some day... As Brian mentioned, he and I discussed this at the last ApacheCon US and found the issue noted above. I simply have not had the time to figure out how to solve that. Even if you can't contribute a patch a really good idea would be welcomed. I will try to give it a little dive - but I have NOT done much other than some MOJO-coding so far and sometimes get lost with mercury, plexus, wagon, etc. and I have just little time. Still looking for someone who likes to pay me for doing OOS development ;) Ralph Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using
Re: Progress on support for large projects
Can you give more details about what doesn't work or doesn't match your process? E.g. it tried to convince me to release all modules of my entire project and complained if some module had a non SNAPSHOT version. Since it's going to convert a module to a release version, you shouldn't have to convert them by hand first and thus they would always be snapshots in scm. It's true that it will want to release the tree from where ever you run it, but that can be mitigated by constructing trees that match how you do releases. [cut.] The new reactor modes are in 2.1.0 that can do some similar things. [cut.] Some of this is already done in 2.1.0 Great to hear that. Please give me some hint (weblink, example or whatever) to get started with this. Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ4coACgkQmPuec2Dcv//ZqACgkQiOIFbclxDb1A/cZr1JjyiX P4IAn2OiW+XcJizxnzYmmXRzsusBx/7n =AinT -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Fox wrote: Can you give more details about what doesn't work or doesn't match your process? E.g. it tried to convince me to release all modules of my entire project and complained if some module had a non SNAPSHOT version. Since it's going to convert a module to a release version, you shouldn't have to convert them by hand first and thus they would always be snapshots in scm. It's true that it will want to release the tree from where ever you run it, but that can be mitigated by constructing trees that match how you do releases. As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. Thanks anyways for your advice Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ7N4ACgkQmPuec2Dcv//5uQCfXQVEGdOCjcCNZp+uMiDUvaFk MV4AnRewsPtcFh9npnlsvuByNSmxmypN =tQlc -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road.
Re: Progress on support for large projects
On May 12, 2009, at 5:43 PM, Brian Fox wrote: My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. You do know these folks are trying to help, right? ;) Christian. Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de-serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. I read your patch and started to get some parts of the puzzle. 1. The component that reads and parses the POMs is the MavenProjectBuilder. So it is generally possible to do the transformation there. 2. Installing and deploying is NOT diretly done in the according plugins, but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven designers so we do NOT have to touch all MOJOs that deal with this. Still I do NOT know if these plugins need some dependency-update to see such change or if they just depend on the according API and the implementation (DefaultArtifact*) comes with the artifact-version of maven itself. So maybe my idea is right that for the long run maven developers should think about being able to have a 1:1 (de)serialization possibility from pom.xml to MavenProject and vice versa. This way one could make transformations on the POM and ArtifactInstaller/ArtifactDeployer will serialize the project to XML instead of copying. But are there some MOJO-hacks out there that also manipulate the MavenProject and would cause to modify POMs accidently on install/deploy? Or is it NOT possible for regular MOJO to change the MavenProject. As far as I see it is just a plain POJO but it could be proxied or whatever. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ8dIACgkQmPuec2Dcv/9dcACeL7SEqDxSwuBJMUETpfFEEsRt 3VUAnApJkG7mPAYfF1ADSBslgP1k6lGk =NAWp -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Sorry, maybe my words were a little rude (thanks christian btw). I am also NOT a native speaker... Thanks for your friendly response though :) My idea of release-plugin was that if a module in the tree (reactor) has no snapshot version, it should NOT be released then. This allows me to open individual snapshots of single modules without versioning the entire tree (including modules that have NOT changed at all). But how would I tell release-plugin to open one module for development as snapshot and update all other snapshot modules that depend on it so they point on the proper version. I started thinking about a swing GUI opened by the plugin that shows the module tree and allows to change versions including dependencies on that and shows modules that point to an older version of a reactor module. Whenever I thought about it, I came to the point that the problem is just that you have to change versions redundant in various POMs. So if you could just omit the version in case you want to express that you mean the version from the reactor that is in latest state on your disc and in your IDE, all problems were solved. But as pointed out, when the POM is installed/deployed, you have to insert the version valid at this time. It is already possible if you define the versions all in toplevel pom, set all versions of modules with packaging pom to 1.0 and never change them semantically in dependency and build sections and finally add some XSLT MOJO bound to install phase that transforms the installed pom replacing the version. A hack so far, but my hope is that it will work smooth one day with plain native maven standard. Thanks again Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ9oAACgkQmPuec2Dcv/8c5gCgmYPuA1K7Wg32nvFpFLlemoWr oAIAnRmVKP801i71yysAVDen9b+BlK0P =UIdK -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a bill of materials (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my library isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 3:01 PM, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de- serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. I read your patch and started to get some parts of the puzzle. 1. The component that reads and parses the POMs is the MavenProjectBuilder. So it is generally possible to do the transformation there. 2. Installing and deploying is NOT diretly done in the according plugins, but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven designers so we do NOT have to touch all MOJOs that deal with this. Still I do NOT know if these plugins need some dependency-update to see such change or if they just depend on the according API and the implementation (DefaultArtifact*) comes with the artifact-version of maven itself. So maybe my idea is right that for the long run maven developers should think about being able to have a 1:1 (de)serialization possibility from pom.xml to MavenProject and vice versa. This way one could make transformations on the POM and ArtifactInstaller/ArtifactDeployer will serialize the project to XML instead of copying. But are there some MOJO-hacks out there that also manipulate the MavenProject and would cause to modify POMs accidently on install/deploy? Or is it NOT possible for regular MOJO to change the MavenProject. As far as I see it is just a plain POJO but it could be proxied or whatever. I've been promised by Jason that the work on Maven 3 is going to fix some of these issues. I simply haven't had the time to look at the work on Maven 3 and even if I had, it has been changing at a fairly rapid pace for months. While, in principal, Maven's processing is pretty simple - it just collects artifacts and runs plugins - the reality is that there are lots of side effects and timing issues. The fix needed to address 2 things; determining the parent pom version and resolving variables so that when the pom is deployed to the repository the pom isn't ambiguous. That does not include resolving variables in dependencies because those are actually OK to not be locked down in the repo. Unfortunately, once the pom is processed it is impossible to use the Maven Model object to create a new pom. It contains lots of information that wasn't in the original pom that shouldn't be in the pom deployed to a repository. The fix I did took care of this effectively. Writing it to an alternate directory and then telling maven where it was meant that the artifact deployer didn't need any changes at all. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 3:43 PM, Ralph Goers wrote: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a bill of materials (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my library isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. I'm fairly mystified how what you and Jorg appear to want could work with any of the scm systems I know about, that tag an entire file system subtree at once. Maybe I don't understand what you guys are talking about at all. here's what I think you want: file system structure showing projects +root +A +B +C ... +D Probably Jorg has further nesting, but I don't think that actually affects the argument. Projects A, C, E, G,... need to be released right now, whereas projects B, D, F... are just fine and don't need releases. IIUC you guys are supposing a parent pom for all these projects in root and want to be able to run a release on root and have the effect be to release just A, C, E, G and the root pom. So if you run a release on root the entire tree will get tagged including B, D, F etc that you didn't want tagged. So I think what you want to do is have a quick way to run releases on A,C,E,G,... and have each of those tagged individually and not tag the whole tree at once. My impression is that what you are fighting is the scm system, not maven. As far as project setup, what I've done in this situation is have a parent pom that isn't root but parallel to the projects: all the projects use this parent as their parent and obviously dont specify its location as ... I then construct a pom that builds whatever I'm interested in working on in root, but don't check it into svn. I've never had to release more than 2 projects at once in such a setup, so just releasing modules individually hasn't been a problem for me. I can see that it would be a problem if I had 10 projects to release at once. I'd think this is additional new functionality for e.g. the release plugin rather than something that can be created by modifying existing functionality. I was really confused by this kind of situation until I realized that the problems with releasing complicated partial subtrees were caused by scm, not maven. After I arranged the source so tagging would correspond to the independent versions I wanted the layout became much easier for me to understand. Does this correspond at all to what you guys are talking about? thanks david jencks Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Ralph Goers schrieb: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. Why not just remove the modules which haven't changed from the parent ? The updated parent can still be imported afterwards just as you describe and the release plugin could be updated to do this automatically as well. Instead of failing whenever a non-snapshot version is encountered, it could just remove that non-snapshot module element from the corresponding parent and not touch that artifact's version anywhere during release preparation. That's changing aggregation rules with every release somehow, I admit. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 6:20 PM, David Jencks wrote: On May 12, 2009, at 3:43 PM, Ralph Goers wrote: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a bill of materials (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my library isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. I'm fairly mystified how what you and Jorg appear to want could work with any of the scm systems I know about, that tag an entire file system subtree at once. Maybe I don't understand what you guys are talking about at all. here's what I think you want: file system structure showing projects +root +A +B +C ... +D Probably Jorg has further nesting, but I don't think that actually affects the argument. Projects A, C, E, G,... need to be released right now, whereas projects B, D, F... are just fine and don't need releases. IIUC you guys are supposing a parent pom for all these projects in root and want to be able to run a release on root and have the effect be to release just A, C, E, G and the root pom. No. The root represents the library. The release is of the library, not the individual subprojects. I just don't want new versions created for subprojects that didn't change. So if you run a release on root the entire tree will get tagged including B, D, F etc that you didn't want tagged. Actually, I do want them tagged. The bill of materials represents a release of the whole library. It is just that some of the artifacts in the library didn't change. But they should all be part of the release tag. So I think what you want to do is have a quick way to run releases on A,C,E,G,... and have each of those tagged individually and not tag the whole tree at once. No. See above. My impression is that what you are fighting is the scm system, not maven. No. The SCM isn't a problem. However, mvn deploy will try to deploy artifacts that haven't changed since the last release. That is bad. Nexus should be able to silently ignore those or the deployer should somehow be able to detect that the artifact shouldn't be deployed. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 6:17 PM, Christian Schulte wrote: Ralph Goers schrieb: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. Why not just remove the modules which haven't changed from the parent ? The updated parent can still be imported afterwards just as you describe and the release plugin could be updated to do this automatically as well. Instead of failing whenever a non-snapshot version is encountered, it could just remove that non-snapshot module element from the corresponding parent and not touch that artifact's version anywhere during release preparation. That's changing aggregation rules with every release somehow, I admit. Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go with it. a) You want all the projects to be part of the build to be sure that they all work together. Even though some projects didn't change, running the unit tests will help identify any compatibility problems. b) You don't want each release's bill of materials to only contain what changed, it should reflect the whole library. A release consists of converting all subprojects marked as snapshots to non-snapshots and leaving the other subprojects alone, tagging everything, building everything and then deploying only the artifacts that were modified to Nexus, along with the bom pom. Note - it does not end with changing everything to snapshots. We only do that when we actually change something. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Ralph Goers schrieb: Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go with it. a) You want all the projects to be part of the build to be sure that they all work together. Even though some projects didn't change, running the unit tests will help identify any compatibility problems. If an artifact did not change, those tests will always yield the same results as during the release of that artifact. By did not change I assume that not only the source code did not change, also the pom and everything else also did not change. Maven did not change, not a single Maven plugin changed, no dependency, etc. Constantly rebuilding a tag without ever changing anything. If you want to ensure that some artifacts work together, there is no need to rebuild them. Depending on released artifacts suffices instead of rebuilding those tags over and over again. If an artifact contains unit tests used to test that things work together, that sounds like you are doing integration testing instead of unit testing during the build. Creating an independent artifact containing the integration tests and running those integration tests independently helps a lot in such situations. Testing that building those artifacts all together works is another story. That's testing the build itself. I would say that's what the maven integration tests are for. b) You don't want each release's bill of materials to only contain what changed, it should reflect the whole library. It does - except the modules element. If you do not change the release versions of the artifacts you do not want to release, those just stay the same with every new release of that bom. The modules element changes with every release but that does not make any problems for the released poms since that element is only used to aggregate modules during building. The tag which gets created during the release cannot be used to build all artifacts together. If that's what you want, there really seems no other way to either edit the tagged pom after the release re-adding all modules you did not release or release all those artifacts together. That also means that even if no code changed for some of those artifacts, the pom does which forces you to release with a different version nevertheless. Even changing just the parent version produces a new artifact version - that is - the jar file and the pom are tightly coupled and there is no way to release just the pom without the jar. Automatically resolving the parent seems quite dangerous if different parent versions stop leading to different child versions. A release consists of converting all subprojects marked as snapshots to non-snapshots and leaving the other subprojects alone, tagging everything, building everything and then deploying only the artifacts that were modified to Nexus, along with the bom pom. Note - it does not end with changing everything to snapshots. We only do that when we actually change something. I think I do get your point. What is still unclear is why you want to constantly rebuild those tags. Even if its just for running those tests during the build. Why should those test results ever change if nothing else has changed ? So I assume there must be some kind of changes somewhere so that rebuilding the whole library really makes sense. What then does not make sense is to not use snapshot versions which would make the release plugin work for you out of the box. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 12, 2009, at 9:30 PM, Christian Schulte wrote: Ralph Goers schrieb: Imagine that you could get a pom.xml for all of Apache Commons that contained the dependency management for it. Every time a commons project released a new Commons bill of materials would go with it. a) You want all the projects to be part of the build to be sure that they all work together. Even though some projects didn't change, running the unit tests will help identify any compatibility problems. If an artifact did not change, those tests will always yield the same results as during the release of that artifact. By did not change I assume that not only the source code did not change, also the pom and everything else also did not change. Maven did not change, not a single Maven plugin changed, no dependency, etc. This assumption is incorrect. All the projects in the library use other parts of the library, just as commons projects use other commons projects. Because a project does not specify the version of the project it depends on but obtains it from the bom pom the dependency will change with the new release. Thus all subprojects must be tested. Because of this the rest of your response doesn't really apply. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
It sounds like some people should have a look at the versions-maven-plugin... ok, so it will still force updating your pom, but it will allow releasing individual modules using the release plugin and then updating the reactor to reflect the new release. -Stephen
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, thanks for your answer... absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? Nope! I tried it and came to the point that is no good for me. I also had a discussion with the developers long time ago and filed some feature request. Anyhow I still think this is the wrong approach for me. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. I have read parts of this. I hope there is a chance to see this in the future. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. I see your point. But I am always building from toplevel. Anyhow I am also dreaming of a cmd-option in maven 3 that enables a mode where maven walks up to the loplevel pom (as far as locally available) and creates the entire reactor while still building just the module where it was invoked. This could solve the problem you pointed out as well as many other problems, e.g. to do dependent builds of local modules. Anyhow this would just be a feature that does not hurt and would not cause downward compatibility problems if assured, that install/deploy will fill in the omitted version. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Great. So I hope for MNG-2971. Anybody out there can let me know if this is just waiting for contribution. I might work on this one if it is just about that feature in the install-plugin. If there is some more general architectural change needed in order to make this also work with release-plugin and many others let me know - I might not see all possible problems. I think I also read some ideas about POM-Transformation in maven 3... However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoG0h4ACgkQmPuec2Dcv/8zqgCghlevEs/YlVRLaaTIWQl6yi5W kJYAn00C5R0sjXjIl6Z08EtMCFEFIMHN =yhX0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
Are you using the release plugin? Nope! I tried it and came to the point that is no good for me. I also had a discussion with the developers long time ago and filed some feature request. Anyhow I still think this is the wrong approach for me. Can you give more details about what doesn't work or doesn't match your process? Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. I have read parts of this. I hope there is a chance to see this in the future. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. I see your point. But I am always building from toplevel. Anyhow I am also dreaming of a cmd-option in maven 3 that enables a mode where maven walks up to the loplevel pom (as far as locally available) and creates the entire reactor while still building just the module where it was invoked. This could solve the problem you pointed out as well as many other problems, e.g. to do dependent builds of local modules. Anyhow this would just be a feature that does not hurt and would not cause downward compatibility problems if assured, that install/deploy will fill in the omitted version. The new reactor modes are in 2.1.0 that can do some similar things. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Great. So I hope for MNG-2971. Anybody out there can let me know if this is just waiting for contribution. I might work on this one if it is just about that feature in the install-plugin. If there is some more general architectural change needed in order to make this also work with release-plugin and many others let me know - I might not see all possible problems. I think I also read some ideas about POM-Transformation in maven 3... Some of this is already done in 2.1.0 However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoG0h4ACgkQmPuec2Dcv/8zqgCghlevEs/YlVRLaaTIWQl6yi5W kJYAn00C5R0sjXjIl6Z08EtMCFEFIMHN =yhX0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On May 9, 2009, at 7:42 PM, Brian Fox wrote: On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j- hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? This problem probably goes away for anyone able to use the release plugin, but only because the release plugin does all the work, not because the need for the work goes away. If, for whatever reason, you can't use the release plugin, then this is a real pain. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. Actually, the guys I work with started to complain about this again last week and want me to fix it. They suggested that rather than tackling both accepting a missing parent version and fixing the pom so that the pom written to the repository is fully resolved (i.e. the parent version is present in the deployed pom) that just accepting the missing parent would be enough. I'm not sure, but I'd be willing to look at it. I'm also not sure how much things have changed since I created the branch. I'll have to check. The only real problem with what was on the MNG-624 branch was that it requires a place to create the resolved pom.xml. To do that it assumed a hardcoded location of target. If a parent pom redefines the build directory (it seems really odd to me that this is even allowed) then this is wrong. But trying to find the definition of the target variable requires looking at every parent, even if it isn't local, which is something I was trying to avoid. Anyone is free to look at the branch and improve on it. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Yes, the fix in MNG-624 does a really good job of this. However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Where we are in this is that I have been totally booked writing code for other projects - mostly commons VFS and commons configuration. As Brian mentioned, he and I discussed this at the last ApacheCon US and found the issue noted above. I simply have not had the time to figure out how to solve that. Even if you can't contribute a patch a really good idea would be welcomed. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Sun, May 10, 2009 at 3:09 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. I see your point. But I am always building from toplevel. Anyhow I am also dreaming of a cmd-option in maven 3 that enables a mode where maven walks up to the loplevel pom (as far as locally available) and creates the entire reactor while still building just the module where it was invoked. This could solve the problem you pointed out as well as many other problems, e.g. to do dependent builds of local modules. relying on the reactor and giving up on being able to build the one project separately is very bad (read: completely breaks) any IDE integration. Milos
Re: Progress on support for large projects
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+ 7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3 =Jn88 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
