-----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: [email protected] For additional commands, e-mail: [email protected]
