You don't get it and I am tired of it now.
Markus KARG wrote on Thursday, September 21, 2006 7:33 AM:
But it would be beneficial for you since I would change it in a way
that FOP is valid for everyone, so you can remove your workarounds.
Since in your case the Class-Path isn't taken into
Carlos Sanchez wrote on Wednesday, September 20, 2006 5:20 PM:
fop 0.20.5 pom was provided by Joerg Schaible
http://jira.codehaus.org/browse/MEV-386
That was at the point we allowed changing poms in the repo, now it is
not possible to change that pom.
Ah, that was me. Did not know anymore :)
Markus KARG wrote on Thursday, September 21, 2006 7:35 AM:
Carlos Sanchez schrieb:
fop 0.20.5 pom was provided by Joerg Schaible
http://jira.codehaus.org/browse/MEV-386
That was at the point we allowed changing poms in the repo, now it is
not possible to change that pom.
Jörg, why do
I don't know if you ALSO read the part where I said we DO NOT
repackage binaries, so your proposed solution is not acceptable..
On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote:
Carlos Sanchez schrieb:
fop 0.20.5 pom was provided by Joerg Schaible
http://jira.codehaus.org/browse/MEV-386
That
Carlos,
I don't know if you ALSO read the part where I said that I will provide
another pom.xml instead of another binary (it was your solution
proposal, actually)?
Markus
Carlos Sanchez schrieb:
I don't know if you ALSO read the part where I said we DO NOT
repackage binaries, so your
Jörg Schaible schrieb:
Markus KARG wrote on Thursday, September 21, 2006 9:27 AM:
Carlos,
I don't know if you ALSO read the part where I said that I will
provide another pom.xml instead of another binary (it was your
solution proposal, actually)?
When do *you* get it, that you
Jörg,
No need to, it will be rejected. See, how could Maven ever locate and download
a unique artifact without a version? That's one of the critical poiints
providing a POM for a library that is not build with Maven. First you have to
look at the provided docs to learn about the deps and
Markus KARG wrote on Wednesday, September 20, 2006 7:39 AM:
Jörg Schaible schrieb:
[snip]
This does not help, since it is no POM issue! Maven may
select the version declared in the POM but it does not have
to. So it is quite brain dead for any library to define a fix
classpath in the
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
There is no error in the POM, it in the jar's manifest and the jar is the one
published by the FOP team.
In that case (Markus), take my instructions sent 2mins ago, modify
slightly to adjust the manifest file in the JAR as well as the other
instructions, and proceed to update pom to
Wayne Fay wrote on Wednesday, September 20, 2006 9:05 AM:
There is no error in the POM, it in the jar's manifest and
the jar is the one published by the FOP team.
In that case (Markus), take my instructions sent 2mins ago, modify
slightly to adjust the manifest file in the JAR as well as
That's wrong. Maven automatically creates the correct Class-Path
attributes in the manifest, and it's up to the fop team to
decide what
third party library versions to use.
No! If any library would declare a Class-Path in its deps, you could nearly use
none in combination. Just because
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
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
i.e. No on maintains the FOP 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
FOP's
On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote:
i.e. No on maintains the FOP 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
A good idea, but definitely something we would need the Maven Dev team
to make a decision on... Perhaps one of them is even monitoring this
(lengthy) discussion at this point, and will start a discussion on
Maven Dev ml if necessary?
I'm not personally convinced that simply appending another
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
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
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. Ok, he may be able to do that
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
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
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
Hi Markus,
Markus KARG wrote on Wednesday, September 20, 2006 9:35 AM:
Wayne Fay schrieb:
[snip]
This is your best approach (imo) to get this updated FOP artifact
installed in the Maven Repo. Unless of course someone else has a
better suggestion...
You asked about quality control
So since bugs once released cannot get fixed without changing the
version (what is problematic with FOP 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.
Actually I never voted for using ibiblio but just added a dependency to
fop:fop to my project, while in fact Maven 2.0.4 automatically has
choosen to pull it from ibiblio. That's why I said: Since ibiblio is
choosen automatically by Maven until manually de-configured, that
repository must
The community itself is the community control. See your case. It is
the user that reports if something fails, and maybe suggests/provides
a patch or has the patience to let other do it. Here, there is no such
a master-slave relationship where someone tells the changes and others
do. If you need
Markus KARG wrote:
So the policy is A bug cannot be fixed?!
The policy is A bug can be fixed in the next version. What else did
you expect?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Markus KARG wrote on Wednesday, September 20, 2006 9:28 AM:
That's wrong. Maven automatically creates the correct Class-Path
attributes in the manifest, and it's up to the fop team to decide
what third party library versions to use.
No! If any library would declare a Class-Path in its
Markus KARG wrote on Wednesday, September 20, 2006 10:15 AM:
Actually I never voted for using ibiblio but just added a
dependency to
fop:fop to my project, while in fact Maven 2.0.4 automatically has
choosen to pull it from ibiblio. That's why I said: Since ibiblio is
choosen automatically
I expected that if the bug is not in the release but the release itself,
then the release can be undone.
All car manufacturers do that. If there is a severe bug that is likely
to kill lots of people, then they take back thousands of cars to fix the
problem on the vendor's cost.
I don't see that
Well, since I am in the business of QA for ten years now, believe me,
there can be a better one:
The bug was detected after months by incident.
A good QA would have detected it before publishing the release.
Also there still is no fix, since I am a beginner with Maven and a
beginner with FOP.
Then all the Sun JRE's are buggy. Sorry, I am using exactly this artifact for a
long time now without ever noticing that weird classpath entry. The only time
it is respected is when you start the jar as app:
java -jar my.jar
In this case your classpath theory applies. The situation is
No, the point is, that you're not satisfied with the procedure, how QA works
with Maven's public repo. While I can understand your point (being hit also by
bogous POMs), you're not going to change it. If you want have better control,
setup an own repository from scratch. Look, not even the
Markus KARG wrote on Wednesday, September 20, 2006 10:49 AM:
Then all the Sun JRE's are buggy. Sorry, I am using exactly
this artifact for a long time now without ever noticing that
weird classpath entry. The only time it is respected is when
you start the jar as app:
java -jar my.jar
Markus KARG wrote on Wednesday, September 20, 2006 10:50 AM:
Why don't you think that we can change it?
You all told me this is a community process.
So community should be able to discuss, and, if needed, change it.
As Jochen pointed out, it can be fixed with a new version. From a QA's PoV
As said, the situation is different on AppServers. Neither jBoss nor WebLogic
complain. IONA's possibly would, but it's abandonned. WebLogic *does* respect
the classpath entry of the EJB artifact itself though.
That's not part of this discussion I think.
We have discussed EJB problems
As Jochen pointed out, it can be fixed with a new version. From a QA's PoV you
cannot change a reelased version ever. See, we have relesed own artfiacts using
FOP as dep. If POM or the artifact itsefl would change now, or build is no
longer consistent. Even worse, the build could then be
Markus KARG wrote:
But it would be beneficial for you since I would change it in a way that
FOP is valid for everyone, so you can remove your workarounds.
Since in your case the Class-Path isn't taken into account anyways as
you wrote, what have you lost?
It is strange that you as the
Markus KARG wrote on Wednesday, September 20, 2006 11:05 AM:
As Jochen pointed out, it can be fixed with a new version.
From a QA's PoV you cannot change a reelased version ever.
See, we have relesed own artfiacts using FOP as dep. If POM
or the artifact itsefl would change now, or build is
fop 0.20.5 pom was provided by Joerg Schaible
http://jira.codehaus.org/browse/MEV-386
That was at the point we allowed changing poms in the repo, now it is
not possible to change that pom.
Please create new threads for any other related questions, this one is
becoming unmanageable.
I'm now
But it would be beneficial for you since I would change it in
a way that
FOP is valid for everyone, so you can remove your workarounds.
Since in your case the Class-Path isn't taken into account anyways as
you wrote, what have you lost?
Reproducability! If we deploy our final release to
I don't think the repo needs to be changed to meet your requirements.
And it's a collective effort, there's no mantainer.
On 9/19/06, Markus KARG [EMAIL PROTECTED] wrote:
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
Carlos,
actually the repo MUST be changes since the jar IS WRONG.
So if there is no maintainer and no JIRA: WHOM TO TELL ABOUT THE BUG NOW ?
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
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.
On 9/19/06, Markus KARG [EMAIL PROTECTED] wrote:
Carlos,
actually the repo
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
Well, probably the development community of the Apache Fop project can
help you. Check the project site [1].
Cheers,
Bruno
[1] http://xmlgraphics.apache.org/fop/
On 9/19/06, Markus KARG [EMAIL PROTECTED] wrote:
Carlos,
actually the repo MUST be changes since the jar IS WRONG.
So if there
And submit it back to http://jira.codehaus.org/browse/MEV
-D
On 9/19/06, Busch, Hendrik (LNG-MUE) [EMAIL PROTECTED] wrote:
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
(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,
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
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 FOP is available on that repository.
So someone just put it up there without their knowledge!
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 http://jira.codehaus.org/browse/MEV
-D
On 9/19/06, Busch,
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
On 9/19/06,
Markus KARG wrote, On 2006-09-19 3:37 PM:
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 FOP is available on that repository.
So someone
Dan,
what you write sounds good, we will set up our own repository and put
our own fop-0.20.5 on it. On the other hand, its not nice to have a
private fop while there is global repository already hosting one. The
fix cannot be done ONLY by fixing the pom, because fop is dependent on
other
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
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
Geoffrey De Smet wrote on Tuesday, September 19, 2006 3:56 PM:
Markus KARG wrote, On 2006-09-19 3:37 PM:
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
Markus KARG wrote on Tuesday, September 19, 2006 3:34 PM:
(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
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
Jörg Schaible 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 FOP is available on that repository.
So someone just put it up there without their
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
62 matches
Mail list logo
