This, and the previous fop thread, has made me think about what happens with versioning and simple fixes.
For example A-1.5 depends on B-1.0 B-1.0 depends on C-2.0 Now there is an API compatible fix in C, and the version is changed to C-2.0.1. Now for A to get the bennifit of this change both A and B need to be changed. It's a bit of a pain, but we get immutable versions and thus can reproduce builds easily. Now, I'm not a .NET expect, so correct me if I'm wrong. But according to the CLR book [1] one of the ways the CLR is better than the java JVM is the handling of versions and version meta-data. One thing you can do with this version meta-data is to map versions. So you can say that "any module that depends on C-2.0 should use C-2.0.1 instead". So if this meta data is in place when you build A then C-2.0.1 will be used, and B doesn't have to be version bumped. So if one can add this version meta-data to A's pom, or in the settings.xml one can map versions in a controlled way, keeping reproducability, but avoiding the pain of version bumping all poms in a dependancy chain. Does that make sense? Do people think a similar mechanism in maven would be useful? David [1] "Essential .NET", Don Box et al, http://www.amazon.co.uk/Essential-Net-1-Don-Box/dp/0201734117 Carlos Sanchez-4 wrote: > > To make clear to all maven users, this is the current repository policy: > > We don't allow pom changes that can alter reproducibility, which means > DEPENDENCIES IN POMS WILL NOT BE CHANGED. > > The repo is only a way to distribute other people work. We don't > repackage their work, only exceptions are for distribution of sources > or javadocs when the original project don't provide them. > > You CAN NOT PROVIDE YOUR OWN BUILT VERSION OF ANOTHER PROJECT. > As an example if fop adds anything to he manifest that you don't like > or think is wrong it's not our problem, ask them if they want to > change. > > You can always as for an upload of anything you want to a group under > your project/domain name, as long as the license allows it. > Eg. I want to provide my own version of fop, created by my project > hosted in foobar.org. I can request an upload under org.foobar group. > I can upload to org.foobar anything I want as long as it follows the > maven conventions. > > In case a pom is clearly bad, broken or unmanageable, a new pom can be > uploaded for users convenience, under same version appending -1. The > pom description must clearly state it's just for maven users > convenience and the originating project must be asked to provide the > pom improvements in next version (in case they provided the bad one) > Eg. http://repo1.maven.org/maven2/groovy/groovy/1.0-jsr-05-1/ > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Repository-Policy-tf2306302.html#a6413289 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
