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
