Cargo

Need to remove reference to the JBoss Maven repo in the jboss remote deployer projects

Details

  • Type: Task Task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.0.6, 1.1.0
  • Fix Version/s: None
  • Component/s: Build, JBoss
  • Labels:
    None
  • Environment:
    n/a
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

The projects with the JBoss Remote Deployer support classes (cargo-core-tools-jboss-deployer-5 and cargo-core-tools-jboss-deployer-5.1-and-onwards) have a declaration to the JBoss Maven repo. This is not allowed by the rules of Maven central, as Maven central needs to be self-contained. We need to solve this somehow!

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. CARGO-1013 JBoss AS 6X remote deploy failed: Cargo pom needs to be fixed

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CARGO-972 Use JSR88 for remote deployment on JBoss

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Savas Ali Tokmen added a comment -

I agree. Do you have any ideas for solving it?

PS: sending a lawyer to the Red Hat headquarters is not an acceptable idea.

Show
Savas Ali Tokmen added a comment - I agree. Do you have any ideas for solving it? PS: sending a lawyer to the Red Hat headquarters is not an acceptable idea.
Hide
Permalink
Savas Ali Tokmen added a comment -

Committed revision 2827, which checks in the JARs into the SVN. This is a bad idea, and we get warnings:

[WARNING] Some problems were encountered while building the effective model for org.codehaus.cargo:cargo-core-tools-jboss-deployer-5:jar:1.1.0-SNAPSHOT
[WARNING] 'dependencies.dependency.systemPath' for org.jboss.integration:jboss-profileservice-spi:jar should not point at files within the project directory, ${basedir}/lib/jboss-profileservice-spi-5.0.3.GA.jar will be unresolvable by dependent projects @ line 43, column 19
[WARNING] 'dependencies.dependency.systemPath' for org.jboss.man:jboss-managed:jar should not point at files within the project directory, ${basedir}/lib/jboss-managed-2.0.0.CR5.jar will be unresolvable by dependent projects @ line 52, column 19

and

[WARNING] Some problems were encountered while building the effective model for org.codehaus.cargo:cargo-core-tools-jboss-deployer-5.1-and-onwards:jar:1.1.0-SNAPSHOT
[WARNING] 'dependencies.dependency.systemPath' for org.jboss.integration:jboss-profileservice-spi:jar should not point at files within the project directory, ${basedir}/lib/jboss-profileservice-spi-5.1.0.SP1.jar will be unresolvable by dependent projects @ line 43, column 19
[WARNING] 'dependencies.dependency.systemPath' for org.jboss.man:jboss-managed:jar should not point at files within the project directory, ${basedir}/lib/jboss-managed-2.1.0.SP1.jar will be unresolvable by dependent projects @ line 52, column 19
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

I don't know if it is worse now... :o

I have also asked a question on http://community.jboss.org/wiki/MavenGettingStarted-Users#comment-5939 to know what is the real reason behind JBoss not putting its JARs on central. If it is not a legal reason, I could even create a "phantom" project Codehaus JBoss for just deploying dependencies. Or create some other dummy project on Google Code.

Show
Savas Ali Tokmen added a comment - Committed revision 2827, which checks in the JARs into the SVN. This is a bad idea, and we get warnings: [WARNING] Some problems were encountered while building the effective model for org.codehaus.cargo:cargo-core-tools-jboss-deployer-5:jar:1.1.0-SNAPSHOT [WARNING] 'dependencies.dependency.systemPath' for org.jboss.integration:jboss-profileservice-spi:jar should not point at files within the project directory, ${basedir}/lib/jboss-profileservice-spi-5.0.3.GA.jar will be unresolvable by dependent projects @ line 43, column 19 [WARNING] 'dependencies.dependency.systemPath' for org.jboss.man:jboss-managed:jar should not point at files within the project directory, ${basedir}/lib/jboss-managed-2.0.0.CR5.jar will be unresolvable by dependent projects @ line 52, column 19 and [WARNING] Some problems were encountered while building the effective model for org.codehaus.cargo:cargo-core-tools-jboss-deployer-5.1-and-onwards:jar:1.1.0-SNAPSHOT [WARNING] 'dependencies.dependency.systemPath' for org.jboss.integration:jboss-profileservice-spi:jar should not point at files within the project directory, ${basedir}/lib/jboss-profileservice-spi-5.1.0.SP1.jar will be unresolvable by dependent projects @ line 43, column 19 [WARNING] 'dependencies.dependency.systemPath' for org.jboss.man:jboss-managed:jar should not point at files within the project directory, ${basedir}/lib/jboss-managed-2.1.0.SP1.jar will be unresolvable by dependent projects @ line 52, column 19 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. I don't know if it is worse now... :o I have also asked a question on http://community.jboss.org/wiki/MavenGettingStarted-Users#comment-5939 to know what is the real reason behind JBoss not putting its JARs on central. If it is not a legal reason, I could even create a "phantom" project Codehaus JBoss for just deploying dependencies. Or create some other dummy project on Google Code.
Hide
Permalink
Anders Hammar added a comment -

Yes it is. System scope is a total no, no! A simple test project would have shown that Maven can't resolve the dependencies. It might work when building, but for those using the artifact it will not work.

Show
Anders Hammar added a comment - Yes it is. System scope is a total no, no! A simple test project would have shown that Maven can't resolve the dependencies. It might work when building, but for those using the artifact it will not work.
Hide
Permalink
Savas Ali Tokmen added a comment -

Maven does resolve the dependencies: the documentation on http://cargo.codehaus.org/JBoss+Remote+Deployer shows that the following dependencies need to be added:

    <dependency>
      <groupId>org.jboss.integration</groupId>
      <artifactId>jboss-profileservice-spi</artifactId>
      <version>5.1.0.GA</version>
    </dependency>

    <dependency>
      <groupId>org.jboss.jbossas</groupId>
      <artifactId>jboss-as-client</artifactId>
      <version>5.1.0.GA</version>
      <type>pom</type>
    </dependency>

As I told before, these two dependencies need to be at the EXACT SAME version as the target JBoss server anyway!

Do you have any other ideas?

Show
Savas Ali Tokmen added a comment - Maven does resolve the dependencies: the documentation on http://cargo.codehaus.org/JBoss+Remote+Deployer shows that the following dependencies need to be added: <dependency> <groupId>org.jboss.integration</groupId> <artifactId>jboss-profileservice-spi</artifactId> <version>5.1.0.GA</version> </dependency> <dependency> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-client</artifactId> <version>5.1.0.GA</version> <type>pom</type> </dependency> As I told before, these two dependencies need to be at the EXACT SAME version as the target JBoss server anyway! Do you have any other ideas?
Hide
Permalink
Anders Hammar added a comment -

But Maven will not be able to resolve the dependencies with system scope as the path does not exist in the user's environment. Have a try and you'll see.

And no, I don't have a solution. Unfortunately this is one of the issues in Maven world. Can we add the jboss code to our codebase (license wise)? That would be a solution. We then need to shade the packages so there will not be any clashes.

Show
Anders Hammar added a comment - But Maven will not be able to resolve the dependencies with system scope as the path does not exist in the user's environment. Have a try and you'll see. And no, I don't have a solution. Unfortunately this is one of the issues in Maven world. Can we add the jboss code to our codebase (license wise)? That would be a solution. We then need to shade the packages so there will not be any clashes.
Hide
Permalink
Savas Ali Tokmen added a comment -

OK, fair enough. I will then set this as affecting version 1.1.0 as well.

As for legally putting the JBoss artifacts on some repository (Codehaus or others), that's the lawyer option I had mentioned before But, why not.

Show
Savas Ali Tokmen added a comment - OK, fair enough. I will then set this as affecting version 1.1.0 as well. As for legally putting the JBoss artifacts on some repository (Codehaus or others), that's the lawyer option I had mentioned before But, why not.
Hide
Permalink
Savas Ali Tokmen added a comment -

JBoss plans to fix this as part of https://issues.jboss.org/browse/JBBUILD-597 (Synchronize JBoss artifacts from the JBoss repository to the Maven central repository)

That task is in progress, and I'm now setting the target versions of this ticket to 1.1.1 and 1.2.0 so we don't forget to check at each release.

Show
Savas Ali Tokmen added a comment - JBoss plans to fix this as part of https://issues.jboss.org/browse/JBBUILD-597 (Synchronize JBoss artifacts from the JBoss repository to the Maven central repository) That task is in progress, and I'm now setting the target versions of this ticket to 1.1.1 and 1.2.0 so we don't forget to check at each release.
Hide
Permalink
Savas Ali Tokmen added a comment -

If CARGO-972 is solved, this one would also get solved automatically since we wouldn't depend on JBoss anymore.

Show
Savas Ali Tokmen added a comment - If CARGO-972 is solved, this one would also get solved automatically since we wouldn't depend on JBoss anymore.
Hide
Permalink
Savas Ali Tokmen added a comment -

https://issues.jboss.org/browse/JBBUILD-597 is now closed. The rsync is now active for certain groupIds. Some additional information is on the jboss build blog: http://community.jboss.org/en/build/blog/2011/05/24/rsync-jbossorg-to-maven-central

Here is a list of the groupIds currently being synced on a nightly basis:

javassist
jgroups
org.jgroups
org.jboss.netty
org.hibernate
org.hornetq
org.resteasy

... which does not include the artifact CARGO needs ... yet

Show
Savas Ali Tokmen added a comment - https://issues.jboss.org/browse/JBBUILD-597 is now closed. The rsync is now active for certain groupIds. Some additional information is on the jboss build blog: http://community.jboss.org/en/build/blog/2011/05/24/rsync-jbossorg-to-maven-central Here is a list of the groupIds currently being synced on a nightly basis: javassist jgroups org.jgroups org.jboss.netty org.hibernate org.hornetq org.resteasy ... which does not include the artifact CARGO needs ... yet
Hide
Permalink
Savas Ali Tokmen added a comment -

Progress to be tracked on http://community.jboss.org/wiki/MavenRepositoryCentralSynchronization

They have more and more groupIds, but not org.jboss.integration ... yet!

Show
Savas Ali Tokmen added a comment - Progress to be tracked on http://community.jboss.org/wiki/MavenRepositoryCentralSynchronization They have more and more groupIds, but not org.jboss.integration ... yet!
Hide
Permalink
Savas Ali Tokmen added a comment -

The "currently under review for sync" now includes org.jboss.integration ... let's stay tuned!

Show
Savas Ali Tokmen added a comment - The "currently under review for sync" now includes org.jboss.integration ... let's stay tuned!
Hide
Permalink
Savas Ali Tokmen added a comment -

Committed revision 3137 and updated http://cargo.codehaus.org/JBoss+Remote+Deployer since the JBoss 7 dependencies are now in the Maven central.

Now waiting for the older ones

Show
Savas Ali Tokmen added a comment - Committed revision 3137 and updated http://cargo.codehaus.org/JBoss+Remote+Deployer since the JBoss 7 dependencies are now in the Maven central. Now waiting for the older ones
Hide
Permalink
Savas Ali Tokmen added a comment -

JBoss did its best, so now all org.jboss artifacts are on Maven central.

Unfortunately, these have some transitive dependencies, for example apache-xerces:xml-apis, which are only available on the JBoss third party repository (and cannot be put anywhere else since they exist with a different official name in central; for example Xerces is under org.apache).

We therefore need to have:

<!--
  Some transitive dependencies of JBoss artifacts, for example apache-xerces:xml-apis, are
  only available on the JBoss third party repository.
  -->
<pluginRepositories>
  <pluginRepository>
    <id>repository.jboss.org_thirdparty-releases</id>
    <name>JBoss.org third party releases repository</name>
    <url></url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </pluginRepository>
  <pluginRepository>
    <id>repository.jboss.org_thirdparty-uploads</id>
    <name>JBoss.org third party uploads repository</name>
    <url></url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </pluginRepository>
</pluginRepositories>
 
<repositories>
  <repository>
    <id>repository.jboss.org_thirdparty-releases</id>
    <name>JBoss.org third party releases repository</name>
    <url></url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
  <repository>
    <id>repository.jboss.org_thirdparty-uploads</id>
    <name>JBoss.org third party uploads repository</name>
    <url></url>
    <releases>
      <enabled>true</enabled>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
</repositories>
Show
Savas Ali Tokmen added a comment - JBoss did its best, so now all org.jboss artifacts are on Maven central. Unfortunately, these have some transitive dependencies, for example apache-xerces:xml-apis, which are only available on the JBoss third party repository (and cannot be put anywhere else since they exist with a different official name in central; for example Xerces is under org.apache). We therefore need to have: <!-- Some transitive dependencies of JBoss artifacts, for example apache-xerces:xml-apis, are only available on the JBoss third party repository. --> <pluginRepositories> <pluginRepository> <id>repository.jboss.org_thirdparty-releases</id> <name>JBoss.org third party releases repository</name> <url></url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>repository.jboss.org_thirdparty-uploads</id> <name>JBoss.org third party uploads repository</name> <url></url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> </pluginRepositories> <repositories> <repository> <id>repository.jboss.org_thirdparty-releases</id> <name>JBoss.org third party releases repository</name> <url></url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> <repository> <id>repository.jboss.org_thirdparty-uploads</id> <name>JBoss.org third party uploads repository</name> <url></url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>

People

  • Assignee:
    Unassigned
    Reporter:
    Anders Hammar
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: