Re: Progress on support for large projects
On Tue, May 12, 2009 at 11:01 PM, Joerg Hohwiller wrote: > -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
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
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
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
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
maven-clover2-plugin:2.5.0 released . Optimize your Integration Tests.
Hi, Just a quick note to say thanks for the advice and tips this list has provided so far in helping me extend the maven-clover2-plugin to now support Test Optimization of Integration/Functional Tests. If your current project has problems with your unit or functional tests taking too long to run, please try the new 'selective testing' feature of Clover. When configured, only the tests that cover code that was modified since the last test-run, will be run. This allows more CI builds to be run, and also provides faster feedback about test failures. More information is available here: http://www.atlassian.com/software/clover/features/optimization.jsp . Specifically, for getting started on using Test Optimization for your functional tests, please have a look at : http://confluence.atlassian.com/display/CLOVER/Using+Distributed+Per-test+Coverage+with+Maven+2 . Clover is free for open source projects and may be trialled for 30 days for free. Thanks again, Nick Pellow Atlassian Clover. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Ant Tasks version 2.0.10
Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=Html&version=14199 There are still several issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11533&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-018/ Staging site: http://maven.apache.org/ant-tasks-2.0.10/ SCM Tag: http://svn.apache.org/repos/asf/maven/ant-tasks/tags/maven-ant-tasks-2.0.10/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
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
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 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
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 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
-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
-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
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
> > > > 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
-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
> > > > > > 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 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 as well >>> as in 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 and 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 . >>> 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 fo
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 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
