I need to find out the maintainer of the fop:fop project on repo1.maven.org.
There is a severe bug in the published JAR that prevents referencing
this project from own projects.
Please either fix the bug or tell me the name of the maintainer so I can
ask him to fix it!
As there is no JIRA group for that project, I also cannot file a JIRA issue.
It's all about the fop plugin (groupId: fop, artifactId: fop). The
current version is 0.20.5. That version's pom.xml found on
repo1.maven.org contains a dependency on "xml-apis-1.0.b2.jar"
(xml-apis, version 1.0.b2), which should result in "Class-Path:
xml-apis-1.0.b2.jar" to be written in the main artifact "fop-0.20.5.jar".
Actually the "fop-0.20.5.jar" found on repo1.maven.org doesn't contain
"Class-Path: xml-apis-1.0.b2.jar" but "Class-Path: xml-apis.jar" which
results in a class path resolving problem at run time in any project
using FP 0.20.5!
The same problem not only happens with "xml-apis" but with nearly ALL
dependencies of fop-0.20.5 (e. g. also with "batik")!
This has to be fixed ASAP to make those projects work!
The fix is quite easy, just modify the Class-Path: entry or do "mvn
clean deploy" to push another copy to repo1.maven.org.
The problem is really urgent since we need this and we do not have write
access to that folder on of repo1.maven.org.
Thanks
Markus

Carlos,

actually the repo MUST be changes since the jar IS WRNG.

So if there is no maintainer and no JIRA: WHM T TELL ABUT THE BUG NW ?

Markus

Carlos Sanchez schrieb:

I don't think the repo needs to be changed to meet your requirements.
And it's a collective effort, there's no mantainer.

9/19/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
>
>I need to find out the maintainer of the fop:fop project on
>repo1.maven.org.
>There is a severe bug in the published JAR that prevents referencing
>this project from own projects.
>>
>Please either fix the bug or tell me the name of the maintainer so I can
>ask him to fix it!
>>
>As there is no JIRA group for that project, I also cannot file a JIRA
>issue.
>>
>It's all about the fop plugin (groupId: fop, artifactId: fop). The
>current version is 0.20.5. That version's pom.xml found on
>repo1.maven.org contains a dependency on "xml-apis-1.0.b2.jar"
>(xml-apis, version 1.0.b2), which should result in "Class-Path:
>xml-apis-1.0.b2.jar" to be written in the main artifact
>"fop-0.20.5.jar".
>Actually the "fop-0.20.5.jar" found on repo1.maven.org doesn't contain
>"Class-Path: xml-apis-1.0.b2.jar" but "Class-Path: xml-apis.jar" which
>results in a class path resolving problem at run time in any project
>using FP 0.20.5!
>>
>The same problem not only happens with "xml-apis" but with nearly ALL
>dependencies of fop-0.20.5 (e. g. also with "batik")!
>>
>This has to be fixed ASAP to make those projects work!
>The fix is quite easy, just modify the Class-Path: entry or do "mvn
>clean deploy" to push another copy to repo1.maven.org.
>>
>The problem is really urgent since we need this and we do not have write
>access to that folder on of repo1.maven.org.
>>
>Thanks
>Markus
>>
>>
>>
>
>

Well, probably the development community of the Apache Fop project can
help you. Check the project site [1].

Cheers,

Bruno

[1]

9/19/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
Carlos,

actually the repo MUST be changes since the jar IS WRNG.

So if there is no maintainer and no JIRA: WHM T TELL ABUT THE BUG NW ?

Markus

Carlos Sanchez schrieb:

I don't think the repo needs to be changed to meet your requirements.
And it's a collective effort, there's no mantainer.

9/19/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
>
>I need to find out the maintainer of the fop:fop project on
>repo1.maven.org.
>There is a severe bug in the published JAR that prevents referencing
>this project from own projects.
>>
>Please either fix the bug or tell me the name of the maintainer so I can
>ask him to fix it!
>>
>As there is no JIRA group for that project, I also cannot file a JIRA
>issue.
>>
>It's all about the fop plugin (groupId: fop, artifactId: fop). The
>current version is 0.20.5. That version's pom.xml found on
>repo1.maven.org contains a dependency on "xml-apis-1.0.b2.jar"
>(xml-apis, version 1.0.b2), which should result in "Class-Path:
>xml-apis-1.0.b2.jar" to be written in the main artifact
>"fop-0.20.5.jar".
>Actually the "fop-0.20.5.jar" found on repo1.maven.org doesn't contain
>"Class-Path: xml-apis-1.0.b2.jar" but "Class-Path: xml-apis.jar" which
>results in a class path resolving problem at run time in any project
>using FP 0.20.5!
>>
>The same problem not only happens with "xml-apis" but with nearly ALL
>dependencies of fop-0.20.5 (e. g. also with "batik")!
>>
>This has to be fixed ASAP to make those projects work!
>The fix is quite easy, just modify the Class-Path: entry or do "mvn
>clean deploy" to push another copy to repo1.maven.org.
>>
>The problem is really urgent since we need this and we do not have write
>access to that folder on of repo1.maven.org.
>>
>Thanks
>Markus
>>
>>
>>
>
>
>
>
>
>

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

(1) I cannot take care of in my application since I don't know where to
get the dependencies from. The idea behind Maven and Class-Path is that
the user doesn't need to care about.

(2) Why not just correcting the Class-Path in the JAR or the pom.xml? As
you put the the project in the project, you are responsible for doing it
correctly. What sense does it make to have jar and pom.xml found in the
repo that in fact are not in sync and cannot be used at all?

Markus

Carlos Sanchez schrieb:

We don't build the jars, we just put them in the repo. If they build
agains a jar that being the same has a different name we can't do
anything about it. You are the one that in your application have to
take care of it.

Busch, Hendrik (LNG-MUE) schrieb:

Hi,

This has to be fixed ASAP to make those projects work!
The fix is quite easy, just modify the Class-Path: entry or do "mvn
clean deploy" to push another copy to repo1.maven.org.

The problem is really urgent since we need this and we do not have
write
access to that folder on of repo1.maven.org.

If this is a really urgent matter I suggest that you fix that problem
on your own side. Just apply the fix you suggested to the jar file
from repo1 and install it to your local repository server (or your
local .m2 directory if you happen to have no own server) using a a
special version number and reference this newly installed artifact
version in your projects.

Yes this is urgent and we fixed it on our side meanwhile, but our
customers rely on beeing able to build our products using Maven and so
there is no help currently but to tell them "The stuff on the Maven
repository is broken". :-(

You want me to submit a new pom.xml for fop-0.20.5 to that JIRA group?
And how do you verify that I didn't do another bug?
I mean, ain't there some kind of quality assurance of repo contents?

dan tran schrieb:

And submit it back to

-D

9/19/06, Busch, Hendrik (LNG-MUE) <hendrik.busch (AT) lexisnexis (DOT) dewrote:
>
>>
>Hi,
>>
>This has to be fixed ASAP to make those projects work!
>The fix is quite easy, just modify the Class-Path: entry or do "mvn
>clean deploy" to push another copy to repo1.maven.org.
>
>The problem is really urgent since we need this and we do not have
>write
>access to that folder on of repo1.maven.org.
>>
>If this is a really urgent matter I suggest that you fix that problem on
>your own side. Just apply the fix you suggested to the jar file from
>repo1 and install it to your local repository server (or your local .m2
>directory if you happen to have no own server) using a a special version
>number and reference this newly installed artifact version in your
>projects.
>>
>--
>Mit freundlichen G / Kind regards
>>
>Hendrik Busch - Stellv. Leiter der Softwareentwicklung
>>
>LexisNexis Deutschland GmbH
>http://www.lexisnexis.de
>Feldstiege 100
>D-48161 M
>phone +49 (0) 2533-9300-455
>fax +49 (0) 02533-9300-50
>hendrik.busch (AT) lexisnexis (DOT) de
>>
>
>To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>>
>>
>

Bruno Aranda schrieb:

Well, probably the development community of the Apache Fop project can
help you. Check the project site [1].

I have asked them.
They don't know.
They even didn't know that FP is available on that repository.
So someone just put it up there without their knowledge!

If you rely on your customer to build your product, it is best to have your
own repo to
solve this kind of crisis. Have maven to search artifact first before going
to central

In the mean time, It seems you can fix the problem by fixing the pom right?

why not submit it back?
-D

9/19/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
>
>
>
Bruno Aranda schrieb:

Well, probably the development community of the Apache Fop project can
help you. Check the project site [1].
>
>
>
I have asked them.
They don't know.
They even didn't know that FP is available on that repository.
So someone just put it up there without their knowledge!
>
>
>
>

Dan,

what you write sounds good, we will set up our own repository and put
our own fop-0.20.5 on it. the other hand, its not nice to have a
"private" fop while there is global repository already hosting one. The
fix cannot be done NLY by fixing the pom, because fop is dependent on
other apache projects that have the same fault (register in
repo1.maven.org with JARs that are not in sync with their PMs), so
supplying our locally implemented fix will not a globally working
solution. Remember, we are Maven starters and so we do not have to
knowledge to solve this problem on our own all alone. But if the authors
of that other projects will help us, we can coordinate work to make it
work finally. Unfortunately it seems, they do NT want to help us (at
least for now) :-(

Markus

dan tran schrieb:

If you rely on your customer to build your product, it is best to
have your own repo to
solve this kind of crisis. Have maven to search artifact first before
going to central

In the mean time, It seems you can fix the problem by fixing the pom
right?
why not submit it back?
-D

9/19/06, *Markus KARG* <karg (AT) quipsy (DOT) de <mailto:karg (AT) quipsy (DOT) de>wrote:
>
>
>
Bruno Aranda schrieb:

Well, probably the development community of the Apache Fop
project can
help you. Check the project site [1].
>
>
>
I have asked them.
They don't know.
They even didn't know that FP is available on that repository.
So someone just put it up there without their knowledge!
>
>
>
>

Carlos Sanchez schrieb:

The repo is mantained in a no guarantees, free time basis, so your
request to get this solved asap because my client needs it doesn't fit
here. There are companies out there that provide commercial support
around maven and will be able to help you in a more commercial
fashion. I'm not gonna say names but i'm sure somebody in the list can
point you in the right direction ;)

That said, the repo contains artifacts built by the project, we don't
rebuild anything, we just take whatever they distribute. If you really
really need to make use of the classpath entry in the manifest (I
haven't seen many situations in which that is required) it's becuause
you are using the jars outside of the repo, so I suggest you as simple
solution that when you copy/move the jars you rename them to make use
of the name more convenient for you.

As people said poms already in the repo can't be changed, anyway that
won't help you with the classpath manifest problem, but you can
contribute pom improvements that can be taken into account in next
versions.

more, I didn't ask anyone to fix it, I asked for the name of the
author of that pom file to help him fixing it.
Maybe you didn't get me wrong here. I will also spent my free time to do
that, as you do. But I want to spent my spare time to create quality.
repo1.maven.org is a special place because every mvn installation knows
it and such we all have to care not to put things up there that do not work.
Is it so hard to take a bit care before pushing a JAR into it? If it is,
here is my offer: Do not upload it before I have spend my free time to
check its quality.
No problem, I will do.

Markus

Markus KARG wrote:
What sense does it make to have jar and pom.xml found in the
repo that in fact are not in sync and cannot be used at all?

Hi Markus,

it's a common situation that you have to maintain a local repository,
maybe company wide and using a proxy to mirror repo1's contents.
So better you get used to it.
Just think about all those proprietary libs which can't be provided by
repo1 for licensing reasons. Examples are all Sun jars or the
jdbc driver. You have to install all of them on your own in your own
repo. So why not do the same with fop:fop?

Just my 2 cents ;-)

Stefan

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

>it's a common situation that you have to maintain a local repository,
>maybe company wide and using a proxy to mirror repo1's contents.
>So better you get used to it.
>Just think about all those proprietary libs which can't be provided by
>repo1 for licensing reasons. Examples are all Sun jars or the
>jdbc driver. You have to install all of them on your own in your own
>repo. So why not do the same with fop:fop?

Stefan,

this thread is not about local repositories or Sun JARs, it is solely
about a bug I WANT T FIX IN REPMAVENRG IN NLY THE FP PRJECT.
Not more. Not less. So do you know the author of the fop:fop pom.xml
file so that I can tell him of the bug, or don't you? Sorry, but
meanwhile this thread is used by anyone to discuss anything

Markus

As previously mentioned, it is quite honestly not possible to "fix"
that specific version of the pom. For a very brief period of time,
Maven was allowing changes to poms but then realized this was a bad
idea. So instead the proper way to fix issues like this is to actually
release a new version of the Maven artifact including an updated pom.

As for the question "who is the maintainer of this pom" -- unless the
FP team has specifically taken over the Maven artifact for their
project, **anyone** can be the maintainer. This means you, or me, or
any one else interested enough in Maven and FP to actually do the
work and submit the Maven Upload JIRA.

In this case, I would suggest the following, as you appear to be very
well versed in this particular artifact and it sounds like the FP
team does not currently maintain the pom file

Download the FP source code (or binary if you won't compile it) for
version 0.20.5
Download the pom.xml for version 0.20.5
Alter the pom.xml as needed and bump version to 0.20.5.1
Compile the source code if needed and package the JAR
Create the Maven artifact bundle using the new 0.20.5.1 pom
(Install this artifact in your local repo and make sure it works like
you expect by using it in your project, check the Class-Path etc)
Create a new Maven JIRA for this new version and attach your new
bundle to the issue
Wait for feedback from Carlos et al and hope you didn't screw anything
up; if so, adjust your bundle as requested and re-upload
accepted, the new artifact will appear in Central

This is your best approach (imo) to get this updated FP artifact
installed in the Maven Repo. Unless of course someone else has a
better suggestion

You asked about "quality control" previously The assumption is that
the people contributing builds to Maven are competent enough to create
proper builds with reasonable pom.xml files etc. Ideally every Java
project will eventually take over as maintainers of the Maven artifact
but this is not required, nor is it entirely reasonable to expect it
to ever occur.

While there is some checking and testing before artifacts are
installed into Central, in general, its not reasonable to expect the
handful of Maven Repo maintainers to know everything about every
project, so instead they simply trust the community and provide a way
to "easily" update the artifacts, so when problems appear, the
community can "easily" take care of it. Maven automatically looks for
updates to artifacts, so new versions are pulled down and used as they
are made available.

Wayne

9/20/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:

this thread is not about local repositories or Sun JARs, it is solely
about a bug I WANT T FIX IN REPMAVENRG IN NLY THE FP PRJECT.
Not more. Not less. So do you know the author of the fop:fop pom.xml
file so that I can tell him of the bug, or don't you? Sorry, but
meanwhile this thread is used by anyone to discuss anything

Markus

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Wayne Fay schrieb:

As previously mentioned, it is quite honestly not possible to "fix"
that specific version of the pom. For a very brief period of time,
Maven was allowing changes to poms but then realized this was a bad
idea. So instead the proper way to fix issues like this is to actually
release a new version of the Maven artifact including an updated pom.

That's why I am asking for the name of the maintainer, so that I can ask
him to do that

As for the question "who is the maintainer of this pom" -- unless the
FP team has specifically taken over the Maven artifact for their
project, **anyone** can be the maintainer. This means you, or me, or
any one else interested enough in Maven and FP to actually do the
work and submit the Maven Upload JIRA.

So anyone can just put up some buggy JARs into that repository.
Do you think this to be beneficial for the overall quality of the
content?

In this case, I would suggest the following, as you appear to be very
well versed in this particular artifact and it sounds like the FP
team does not currently maintain the pom file

Not only not currently. THEY HAVE NEITHER WRITTEN IT. THE FP TEAM DES
NT AT ALL KNW F ITS PURE EXISTENCE.
Clear now? ;-)

Download the FP source code (or binary if you won't compile it) for
version 0.20.5
Download the pom.xml for version 0.20.5
Alter the pom.xml as needed and bump version to 0.20.5.1
Compile the source code if needed and package the JAR
Create the Maven artifact bundle using the new 0.20.5.1 pom
(Install this artifact in your local repo and make sure it works like
you expect by using it in your project, check the Class-Path etc)
Create a new Maven JIRA for this new version and attach your new
bundle to the issue
Wait for feedback from Carlos et al and hope you didn't screw anything
up; if so, adjust your bundle as requested and re-upload
accepted, the new artifact will appear in Central

So actually Carlos is the maintainer?
That's all I liked to know actually.
So I'll look into doing that.

This is your best approach (imo) to get this updated FP artifact
installed in the Maven Repo. Unless of course someone else has a
better suggestion

You asked about "quality control" previously The assumption is that
the people contributing builds to Maven are competent enough to create
proper builds with reasonable pom.xml files etc. Ideally every Java
project will eventually take over as maintainers of the Maven artifact
but this is not required, nor is it entirely reasonable to expect it
to ever occur.

You need to know that our company is deeply involved into the business
of quality assurance.
So what you write is wrong. Nobody can rely on others to be good enough.
You need to control quality EVER.
As a proof, see the FP project. Nobody knows where the author of that
buggy pom.xml was, and it needed a two days discussion on how to fix it.
That's not quality assurance, that's pure random.
This is acceptable for any repository, but not for that one that is
listed automatically with every installation of Maven 2.0.4.

While there is some checking and testing before artifacts are
installed into Central, in general, its not reasonable to expect the
handful of Maven Repo maintainers to know everything about every
project, so instead they simply trust the community and provide a way
to "easily" update the artifacts, so when problems appear, the
community can "easily" take care of it. Maven automatically looks for
updates to artifacts, so new versions are pulled down and used as they
are made available.

Well, in case of FP this trust doesn't seem to work

Markus

Markus writes:
That's why I am asking for the name of the maintainer, so that I can ask
him to do that

As Carlos said in another email:
The repo is mantained in a no guarantees, free time basis, so your
request to get this solved asap because my client needs it doesn't fit
here.

i.e. No on maintains the FP available in the repo.
It is there as a convenience only.

I might also suggest you adjust your attitude.

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

i.e. No on maintains the FP available in the repo.
It is there as a convenience only.

I might also suggest you adjust your attitude.

Sorry for beeing rude and thank you for telling me.
It wasn't my intention.

But see, I just want to know who is the guy that has write access to the
FP's pom.xml.
After two days I get told "Carlos", while Carlos actually wasn't able to
tell me that directly in his first email.
Isn't it ironic to discuss two days (over 20 emails) instead of just
writing "Hi, I'm Carlos, it's me whom you have to send the fixed pom.xml"?
Don't you think you would be a bit rude then, too?

Markus

9/20/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:

i.e. No on maintains the FP available in the repo.
It is there as a convenience only.

I might also suggest you adjust your attitude.

Sorry for beeing rude and thank you for telling me.
It wasn't my intention.

But see, I just want to know who is the guy that has write access to the
FP's pom.xml.
After two days I get told "Carlos", while Carlos actually wasn't able to
tell me that directly in his first email.
Isn't it ironic to discuss two days (over 20 emails) instead of just
writing "Hi, I'm Carlos, it's me whom you have to send the fixed pom.xml"?
Don't you think you would be a bit rude then, too?

Carlos did tell you who maintains it and the answer is no one.

Carlos is just one of the people who will upload your pom and artifact
if you follow the instructions on the web site.

So you are able to make the necessary changes and get it fixed.

The problem that Jorg points out is still outstanding is what naming
conventions should be used to indicate that this fixes a problem with
an already released version of the artifact.

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Barrie Treloar wrote:

The problem that Jorg points out is still outstanding is what naming
conventions should be used to indicate that this fixes a problem with
an already released version of the artifact.

There is no problem.

If the artifact is actually modified, then it's a different release. In
other words, one needs a new version number. Note, that the version
number might be something like "0.20.5-fix1" or whatever.

Jochen

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Barrie Treloar schrieb:

Carlos did tell you who maintains it and the answer is no one.

Carlos is just one of the people who will upload your pom and artifact
if you follow the instructions on the web site.

So you are able to make the necessary changes and get it fixed.

The problem that Jorg points out is still outstanding is what naming
conventions should be used to indicate that this fixes a problem with
an already released version of the artifact.

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

If Carlos is able to upload it while I seem not to be, he actually is in
the role of the maintainer.
Where am I going wrong with that assumption?

Markus

Markus KARG wrote:

If Carlos is able to upload it while I seem not to be, he actually is in
the role of the maintainer.
Where am I going wrong with that assumption?

Your assumption is, that he is able to change files in the repository.
The answer is he isn't. , he may be able to do that technically, but
the policy is clearly that already released files are left unchanged -
forever.

Jochen

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

So the policy is "A bug cannot be fixed"?!

Jochen Wiedmann schrieb:

Markus KARG wrote:
>
>If Carlos is able to upload it while I seem not to be, he actually is
>in the role of the maintainer.
>Where am I going wrong with that assumption?
>
>
Your assumption is, that he is able to change files in the repository.
The answer is he isn't. , he may be able to do that technically, but
the policy is clearly that already released files are left unchanged -
forever.
--
Jochen
--

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

A released jar cannot be modified. A bug can be fixed, but in the next
version/bugfix of the artifact (and maybe you could provide such a
fixed artifact). All this is a community effort where everyone can
participate. It is not right to change anything in a released
artifact, because you are never sure that the bug you are fixing will
cause other bugs

Bruno

9/20/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
So the policy is "A bug cannot be fixed"?!

Jochen Wiedmann schrieb:

Markus KARG wrote:
>
>If Carlos is able to upload it while I seem not to be, he actually is
>in the role of the maintainer.
>Where am I going wrong with that assumption?
>
>
Your assumption is, that he is able to change files in the repository.
The answer is he isn't. , he may be able to do that technically, but
the policy is clearly that already released files are left unchanged -
forever.
--
Jochen
--

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>
>
>
>
>

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Yes, this is the point of the discussion. Please search this mail list
(Nabble etc) and Maven Dev to see the entire history of this issue.

Increment version by one, upload it, and allow Maven to find the
updated version the next time your build runs, it will automatically
find and use it.

Wayne

9/20/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
So the policy is "A bug cannot be fixed"?!

Jochen Wiedmann schrieb:

Markus KARG wrote:
>
>If Carlos is able to upload it while I seem not to be, he actually is
>in the role of the maintainer.
>Where am I going wrong with that assumption?
>
>
Your assumption is, that he is able to change files in the repository.
The answer is he isn't. , he may be able to do that technically, but
the policy is clearly that already released files are left unchanged -
forever.
--
Jochen
--

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>
>
>
>
>

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

So since bugs once released cannot get fixed without changing the
version (what is problematic with FP as we have discussed today), this
is one more reason for not let anybody upload things without doing
quality control. :-)

Wayne Fay schrieb:

Yes, this is the point of the discussion. Please search this mail list
(Nabble etc) and Maven Dev to see the entire history of this issue.

Increment version by one, upload it, and allow Maven to find the
updated version the next time your build runs, it will automatically
find and use it.

Wayne

9/20/06, Markus KARG <karg (AT) quipsy (DOT) dewrote:
>
>So the policy is "A bug cannot be fixed"?!
>>
>Jochen Wiedmann schrieb:
>>
>Markus KARG wrote:
>>
>>If Carlos is able to upload it while I seem not to be, he actually is
>>in the role of the maintainer.
>>Where am I going wrong with that assumption?
>>
>>
>Your assumption is, that he is able to change files in the repository.
>The answer is he isn't. , he may be able to do that technically, but
>the policy is clearly that already released files are left unchanged -
>forever.
>>
>>
>Jochen
>>
>>
>
>To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>>
>>
>>
>>
>>