Cargo
  1. Cargo
  2. CARGO-953

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: