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
