[pgier]

"pgier" wrote:

"ALRubinger" wrote:
I have committed org.jboss.jbossas:jboss-as-dependency:

http://jira.jboss.com/jira/browse/JBAS-5324

Looking to avoid being too invasive here. The shared POM is now committed and deployed for review, though I'm holding the commit for org.jboss.jbossas:jboss-as-parent until we can verify that all looks allright. Once Paul gives me the nod, I'll commit that change.

The patch up for review is attached to the JIRA, as is the commit of the new project.

Paul, let's look over this together.

S,
ALR

Hey Andrew, I think it's fine to commit this, except for the prerequisites section (maven 2.0.8). I think that should stay in the jbossas parent because it doesn't get inherited. If ejb also requires 2.0.8 you'll have to define it in that parent also.

Also, I must have committed the 2.2-beta-3-SNAPSHOT version of the assembly plugin by mistake. I was working with that locally, but the one in the pom should be 2.2-beta-2.

One more thing I realized, is that the jbossas intermodule dependencies (deps with groupid "org.jboss.jbossas") will probably have to remain in the as parent, and not in the new super parent. Otherwise we could have a chicken/egg problem when trying to release.

[alrubinger]

No we should use constraints (version ranges). But we need to understand how that interacts with the release process and reproducability of tagged versions.

Brian had this to say about current support for ranges:

"#maven" wrote:
ALR: Brian: Don't know if you're interested, we've been running into some conflicts regarding versioning and transitive dependencies in JBossAS build.
Brian: ugh
ALR: Some use cases are documented: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748
Brian: FWIW, i never used ranges in my corp builds
ALR: Brian: Is that a vote for "don't Mavenize"? :)
Brian: no, just don't use ranges

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

No we should use constraints (version ranges). But we need to understand how that interacts with the release process and reproducability of tagged versions.

Brian had this to say about current support for ranges:

"#maven" wrote:
ALR: Brian: Don't know if you're interested, we've been running into some conflicts regarding versioning and transitive dependencies in JBossAS build.
Brian: ugh
ALR: Some use cases are documented: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748
Brian: FWIW, i never used ranges in my corp builds
ALR: Brian: Is that a vote for "don't Mavenize"? :)
Brian: no, just don't use ranges

S,
ALR

Is that confirmation that it doesn't understand 1.0.1 > 1.0.0 like I said above.
Or is that just his preference.

There's no way we can fix dependencies at single version given the number
of projects/releases we have.

It reminds me of when I started working on the JBossAS source code using
eclipse and wondered why it was so slow.
It had never been considered that the tool should scale to such a large project. ;-)

[alrubinger]

Is that confirmation that it doesn't understand 1.0.1 > 1.0.0 like I said above. Or is that just his preference.

No, Maven will understand version order (we covered this elsewhere in the conversation; check the full transcript). This is his preference, likely based on some prior experience (conjecture).

There's no way we can fix dependencies at single version given the number of projects/releases we have.

We can introduce some ranges and see what kind of results we have...technically this is a supported feature.

Any better ideas?

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

We can introduce some ranges and see what kind of results we have...technically this is a supported feature.

It needs testing. Somebody needs to run some test projects through a few releases
(including snapshots) to validate the behaviour is correct;
* specific versions pom tagged in svn
* ranges in the repository
If it is not correct in some cases we learn what to avoid or how to work around the problems.

If I had more time, I'd do it myself, for now I'm just using
mvn dependency:tree
to check poms are behaving as expected when I create releases
and fixing it with exclusions if they are not.

[alrubinger]

"pgier" wrote:
I think I like component-matrix better ;-) Or maybe dependency-matrix. Just "dependency" by itself seems too generic.

I agree. Renamed to 'component-matrix', with artifactId 'jboss-as-component-matrix'.

S,
ALR

[starksm64]

Trying to do a mvn compile from the jbossas trunk I'm failing to find org.jboss.jbossas:jboss-as-component-matrix:pom:5.0.0-SNAPSHOT:

Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository

 org.jboss.jbossas:jboss-as-component-matrix:pom:5.0.0-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 repository.jboss.org (http://repository.jboss.org/maven2),
 snapshots.jboss.org (http://snapshots.jboss.org/maven2)

 at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197)
 at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73)
 at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:526)
 ... 18 more

I don't see this under http://snapshots.jboss.org/maven2/org/jboss/jbossas/.

[alrubinger]

Trying to do a mvn compile from the jbossas trunk I'm failing to find org.jboss.jbossas:jboss-as-component-matrix:pom:5.0.0-SNAPSHOT

Sorry, Scott; hadn't realized that jboss-as-parent had been switched over to use this until after I committed.

Just ran a deploy.

S,
ALR

[pgier]

Trying to do a mvn compile from the jbossas trunk I'm failing to find org.jboss.jbossas:jboss-as-component-matrix:pom:5.0.0-SNAPSHOT:

Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository

 org.jboss.jbossas:jboss-as-component-matrix:pom:5.0.0-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 repository.jboss.org (http://repository.jboss.org/maven2),
 snapshots.jboss.org (http://snapshots.jboss.org/maven2)

 at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197)
 at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73)
 at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:526)
 ... 18 more

I don't see this under http://snapshots.jboss.org/maven2/org/jboss/jbossas/.

I'm updating a few things in the app server maven build now. Partly based on the new component matrix. I should have things working again soon.