Re: Repository Policy
ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus -- 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]
Re: Repository Policy
Actually I don't know it myself, since I am a beginner. But there must be a Maven way to solve the problem (otherwise this would make install:install-file totally useless, since least pre-packaged binary are named in the correct way using -x.y.z versions). I'll start another thread to ask for help on this. Thanks Markus Carlos Sanchez schrieb: ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Repository Policy
As I said somewhere you'll have to probably rename the jars AFTER downloading if you want them to match the manifest On 9/21/06, Markus KARG [EMAIL PROTECTED] wrote: Actually I don't know it myself, since I am a beginner. But there must be a Maven way to solve the problem (otherwise this would make install:install-file totally useless, since least pre-packaged binary are named in the correct way using -x.y.z versions). I'll start another thread to ask for help on this. Thanks Markus Carlos Sanchez schrieb: ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus -- 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]
Re: Repository Policy
Jörg was so kind to tell me that this is not possible in Maven, I didn't know before (actually this is written nowhere and there was no real concensus on the version policy of Maven -- some where talking about planned features, some where talking about the schema only beeing a good advice and so on). Know I know. Discussions can be so easy once everyone understands that not everyone is a Maven professional. :-) Thanks Markus Carlos Sanchez schrieb: As I said somewhere you'll have to probably rename the jars AFTER downloading if you want them to match the manifest On 9/21/06, Markus KARG [EMAIL PROTECTED] wrote: Actually I don't know it myself, since I am a beginner. But there must be a Maven way to solve the problem (otherwise this would make install:install-file totally useless, since least pre-packaged binary are named in the correct way using -x.y.z versions). I'll start another thread to ask for help on this. Thanks Markus Carlos Sanchez schrieb: ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Repository Policy
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]
Re: Repository Policy
On 9/20/06, diroussel [EMAIL PROTECTED] wrote: 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. ... Does that make sense? Do people think a similar mechanism in maven would be useful? I'm not sure how much of it can be addressed by Maven vs. needing to be done in the JVM itself, but you may want to keep an eye on JSR-277, Java Module System: http://www.jcp.org/en/jsr/detail?id=277 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Policy
On 9/20/06, diroussel [EMAIL PROTECTED] wrote: 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. When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version 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] -- 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]
Re: Repository Policy
Carlos Sanchez-4 wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version The CLR versioning meta-data is for runtime, not compile time like maven. Also it's designed for closed source software, not open source. So perhaps the idea is not a good fit for maven's compile time dependency management. Sorry to trouble you. Carlos Sanchez-4 wrote: because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version Yes, you nly get what you ask for, and version mapping should only used if you know that it's a good mapping, or if you are testing that same mapping. Only then can you know it's a good substitution. David -- View this message in context: http://www.nabble.com/Repository-Policy-tf2306302.html#a6415851 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Policy
Wendy Smoak schrieb: On 9/20/06, diroussel [EMAIL PROTECTED] wrote: 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. ... Does that make sense? Do people think a similar mechanism in maven would be useful? I'm not sure how much of it can be addressed by Maven vs. needing to be done in the JVM itself, but you may want to keep an eye on JSR-277, Java Module System: http://www.jcp.org/en/jsr/detail?id=277 I think JSR 277 discusses exactly what we need to solve our quarrel. Meanwhile, we should agree on accepting the current specifications (J2EE spec, MANIFEST.MF spec) as they are. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Repository Policy
When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
