m2 build broken?

[Upayavira <uv...@odoko.co.uk>]

I've just done a fresh build of trunk using m2, which failed somehow
because of problems with xml-apis, saying something like:

  "This artifact has been relocated to xml-apis:xml-apis:1.0.b2."

And I also found references to it trying to get it from a URL at:

http://cvs.apache.org/maven-snapshot-repository that didn't exist.

Any ideas? Does it work for other people?

Regards, Upayavira

Re: m2 build broken?

[Jorg Heymans <jh...@domek.be>]

Daniel Fagerstrom wrote:
> 
> I'll talk to Upayavira, and see if we can take care about it.
> 
> I saw that you had changed the Cocoon group id to org.apache.cocoon from 
> apache-cocoon in the main pom and the core pom but nowhere else. What is 
> your plane for this? Should we just start to change group id to 
> org.apache.cocoon in all poms?
> 

The "unofficial" groupId policy from the maven ppl states that one 
should try to use a package based groupId ie org.apache.cocoon rather 
than just apache-cocoon. I'll see about getting our poms changed unless 
you beat me to it.


Jorg

Re: m2 build broken?

[Daniel Fagerstrom <da...@nada.kth.se>]

Jorg Heymans skrev:
> Daniel Fagerstrom wrote:
...
> The root of the problem lies somewhere in the current m2 poms from 
> excalibur. These have been automatically converted from the m1 
> project.xml files, so they are not using things like 
> <scope>provided</scope> where they should. This problem became very 
> apparent a while ago, when I noticed that for producing a minimal and 
> working war file, the number of libs to exclude was almost bigger than 
> the number of direct dependencies !
> So i started converting excalibur to use "real" m2 poms, this process is 
> about 95% complete overall, and 100% as to what our dependencies are 
> concerned. The converted artifacts use a different groupId structure, 
> and can be found at [1].
> 
> Left to be done :
> - officially "release" these poms to ibiblio, requires some infra stuff 
> and coordination with the maven and excalibur people.
> - switch our core pom to use these poms instead (anyone up for this?) so 
> for ourselves can do :
> - a round of testing and bugfixing ~ ensure correctly scoped 
> dependencies in excalibur ~ fix and rerelease poms if necessary

I'll talk to Upayavira, and see if we can take care about it.

I saw that you had changed the Cocoon group id to org.apache.cocoon from 
apache-cocoon in the main pom and the core pom but nowhere else. What is 
your plane for this? Should we just start to change group id to 
org.apache.cocoon in all poms?

/Daniel

Re: m2 build broken?

[Jorg Heymans <jh...@domek.be>]

Daniel Fagerstrom wrote:
> I think that the problems is that there was a 2.0.2 release of the 
> xml-apis by mistake, don't know the story behind it, but see 
> http://www.apache.org/dist/java-repository/xml-apis/jars/. It should 
> have been 1.0.b2.
>
> Several poms at the official maven repository have dependencies of 
> 2.0.2. This has been solved by leting the 2.0.2 pom redirect to 1.0.b2, 
> in the repository. Now some part of Cocoon core depends on DOM3 (IIRC), 
> that is part of xml-apis 1.3.02 (but not 1.0.b2).
> 
> Now there are both indirect dependencies to 2.0.2 and a direct 
> dependency on 1.3.02 in the Cocoon core pom. In this situation it seem 
> like the m2 engine chose to compile with the jar with the pom with the 
> highest version number, i.e. 2.0.2. As we saw above this is actually 
> older (1.0.b2 through redirection) than the version we need (1.3.02).
>

Correct.

> Possible solutions would be either ask the official maven repository to 
> redirect 2.0.2 to 1.3.02 instead or by tracking down all the indirect 
> dependencies in the cocoon core pom and adding exclusion clauses in our 
> poms. Considering the number of projects that depend on xml-apis and the 
> number of poms that we have it will not be fun. Other projects are 
> probably going to get the same problems, so we should fix the problem at 
> its root IMO.
> 

The root of the problem lies somewhere in the current m2 poms from 
excalibur. These have been automatically converted from the m1 
project.xml files, so they are not using things like 
<scope>provided</scope> where they should. This problem became very 
apparent a while ago, when I noticed that for producing a minimal and 
working war file, the number of libs to exclude was almost bigger than 
the number of direct dependencies !
So i started converting excalibur to use "real" m2 poms, this process is 
about 95% complete overall, and 100% as to what our dependencies are 
concerned. The converted artifacts use a different groupId structure, 
and can be found at [1].

Left to be done :
- officially "release" these poms to ibiblio, requires some infra stuff 
and coordination with the maven and excalibur people.
- switch our core pom to use these poms instead (anyone up for this?) so 
for ourselves can do :
- a round of testing and bugfixing ~ ensure correctly scoped 
dependencies in excalibur ~ fix and rerelease poms if necessary


> A strange thing that I don't understand, is that it compiled for me on 
> my new computer where everything was installed, checked out etc this 
> thursday.

dunno, poms do get worked on in the backgroud so things can break (or 
get fixed) seemingly random.


Jorg


[1] http://cvs.apache.org/maven-snapshot-repository/org/apache/

Re: m2 build broken?

[Daniel Fagerstrom <da...@nada.kth.se>]

I think that the problems is that there was a 2.0.2 release of the 
xml-apis by mistake, don't know the story behind it, but see 
http://www.apache.org/dist/java-repository/xml-apis/jars/. It should 
have been 1.0.b2.

Several poms at the official maven repository have dependencies of 
2.0.2. This has been solved by leting the 2.0.2 pom redirect to 1.0.b2, 
in the repository. Now some part of Cocoon core depends on DOM3 (IIRC), 
that is part of xml-apis 1.3.02 (but not 1.0.b2).

Now there are both indirect dependencies to 2.0.2 and a direct 
dependency on 1.3.02 in the Cocoon core pom. In this situation it seem 
like the m2 engine chose to compile with the jar with the pom with the 
highest version number, i.e. 2.0.2. As we saw above this is actually 
older (1.0.b2 through redirection) than the version we need (1.3.02).

Possible solutions would be either ask the official maven repository to 
redirect 2.0.2 to 1.3.02 instead or by tracking down all the indirect 
dependencies in the cocoon core pom and adding exclusion clauses in our 
poms. Considering the number of projects that depend on xml-apis and the 
number of poms that we have it will not be fun. Other projects are 
probably going to get the same problems, so we should fix the problem at 
its root IMO.

A strange thing that I don't understand, is that it compiled for me on 
my new computer where everything was installed, checked out etc this 
thursday.

/Daniel

Upayavira skrev:
> I've just done a fresh build of trunk using m2, which failed somehow
> because of problems with xml-apis, saying something like:
> 
>   "This artifact has been relocated to xml-apis:xml-apis:1.0.b2."
> 
> And I also found references to it trying to get it from a URL at:
> 
> http://cvs.apache.org/maven-snapshot-repository that didn't exist.
> 
> Any ideas? Does it work for other people?
> 
> Regards, Upayavira