You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Carlos Sanchez <ca...@apache.org> on 2006/09/20 17:53:48 UTC
Repository Policy
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by Markus KARG <ka...@quipsy.de>.
Carlos Sanchez schrieb:
> 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/
>
Now this is clear word! Thank you Carlos!
So we he to change the pom.xml from J�rg SCHAIBLE to mirror the correct
dependencies and send it to you, and we will do that under version 0.20.5-1.
Thanks a lot for this decision!
Markus
Re: Repository Policy
Posted by diroussel <na...@diroussel.xsmail.com>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by Markus KARG <ka...@quipsy.de>.
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 <ka...@quipsy.de> 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 <ka...@quipsy.de> 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
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
>
>
Re: Repository Policy
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ka...@quipsy.de> 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 <ka...@quipsy.de> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by Markus KARG <ka...@quipsy.de>.
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 <ka...@quipsy.de> 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
>>
>>
>>
>
>
Re: Repository Policy
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ka...@quipsy.de> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by Markus KARG <ka...@quipsy.de>.
> 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
Re: Repository Policy
Posted by Carlos Sanchez <ca...@apache.org>.
On 9/20/06, diroussel <na...@diroussel.xsmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by Markus KARG <ka...@quipsy.de>.
Wendy Smoak schrieb:
> On 9/20/06, diroussel <na...@diroussel.xsmail.com> 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
Re: Repository Policy
Posted by Wendy Smoak <ws...@gmail.com>.
On 9/20/06, diroussel <na...@diroussel.xsmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Repository Policy
Posted by diroussel <na...@diroussel.xsmail.com>.
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org