Details

    • Similar Issues:
      Show 10 results 

      Description

      There are a number of projects which have dependencies on non-jboss
      maven repos (jboss-osgi is one of them)

      http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779

      I believe, this issue is general enough to have proper repo aggregation
      setup somehow

      Here is a link to some aggregators

      http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix

      Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo?
      Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.

      http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

        Issue Links

          Activity

          Hide
          Thomas Diesler
          added a comment -

          Please also note, that even if you preserve the original POM on 'deploy-file' it is likely that the deployed file itself has dependencies on artefacts in other repositories.

          Show
          Thomas Diesler
          added a comment - Please also note, that even if you preserve the original POM on 'deploy-file' it is likely that the deployed file itself has dependencies on artefacts in other repositories.
          Hide
          Thomas Diesler
          added a comment -

          Max sais:

          Paul G. and I are exploring to setup a Nexus repository
          manager....needed to get order in the jboss maven chaos we got right now
          Plus looking into
          getting a similar setup for the productized binaries.

          Problem right now is time and machine availability constraints - if you
          want to help out with this ping me

          Show
          Thomas Diesler
          added a comment - Max sais: Paul G. and I are exploring to setup a Nexus repository manager....needed to get order in the jboss maven chaos we got right now Plus looking into getting a similar setup for the productized binaries. Problem right now is time and machine availability constraints - if you want to help out with this ping me
          Hide
          Thomas Diesler
          added a comment -

          Generally, I'd like to mention again that 'deploy-file' is not good solution because of

          • with the generated POM you loose all info about transitive dependencies, etc.
          • when you preserve/deploy the original POM you also deploy the dependencies on other repos
          • the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from
          Show
          Thomas Diesler
          added a comment - Generally, I'd like to mention again that 'deploy-file' is not good solution because of with the generated POM you loose all info about transitive dependencies, etc. when you preserve/deploy the original POM you also deploy the dependencies on other repos the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from
          Hide
          Paul Gier
          added a comment -

          This is currently dependent on jboss.org. The issue for the past year has been that jboss.org doesn't have any space available for this. I've talked to IT and Mark Newton about this and was told to wait until they have more servers available.

          I'm currently looking into an alternative hosting solution, and will provide more info when it's available.

          Show
          Paul Gier
          added a comment - This is currently dependent on jboss.org. The issue for the past year has been that jboss.org doesn't have any space available for this. I've talked to IT and Mark Newton about this and was told to wait until they have more servers available. I'm currently looking into an alternative hosting solution, and will provide more info when it's available.
          Hide
          Max Rydahl Andersen
          added a comment -

          "* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from "

          unfortunately that does not fit well with the current business model of a split....something gotta give...any suggestions ?

          Show
          Max Rydahl Andersen
          added a comment - "* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from " unfortunately that does not fit well with the current business model of a split....something gotta give...any suggestions ?
          Hide
          Paul Gier
          added a comment -

          There was some discussion on the maven developers list about repository synching, and how we can manage synchronization with our dependencies on rebuilt stuff (for example all the jars with "-brew" at the end). We can't send them to the central repository because they are not our upstream projects, but we need them for building projects like the app server. So it doesn't really do us any good to synchronize the jboss app server jars to central if we can't also send the dependencies. So the recommendation is to change the groupId of our rebuilt artifacts and prefix it with something like "org.jboss". If we use a groupId like this then we could avoid conflicts caused by rebuilt artifacts. But this would cause other problems [1].

          [1]http://www.nabble.com/Depending-on-Artifacts-not-in-central-td24394458.html

          Show
          Paul Gier
          added a comment - There was some discussion on the maven developers list about repository synching, and how we can manage synchronization with our dependencies on rebuilt stuff (for example all the jars with "-brew" at the end). We can't send them to the central repository because they are not our upstream projects, but we need them for building projects like the app server. So it doesn't really do us any good to synchronize the jboss app server jars to central if we can't also send the dependencies. So the recommendation is to change the groupId of our rebuilt artifacts and prefix it with something like "org.jboss". If we use a groupId like this then we could avoid conflicts caused by rebuilt artifacts. But this would cause other problems [1] . [1] http://www.nabble.com/Depending-on-Artifacts-not-in-central-td24394458.html
          Hide
          Max Rydahl Andersen
          added a comment -

          yes - exactly, its not really solvable if product binaries are considered different.
          Then the dependency set will have to be different for both project and product builds which will lead to horrible maintanence headache ;(

          Show
          Max Rydahl Andersen
          added a comment - yes - exactly, its not really solvable if product binaries are considered different. Then the dependency set will have to be different for both project and product builds which will lead to horrible maintanence headache ;(
          Hide
          Paul Gier
          added a comment -

          The new repository now automatically proxies thirdparty repositories.

          Show
          Paul Gier
          added a comment - The new repository now automatically proxies thirdparty repositories.

            People

            • Assignee:
              Paul Gier
              Reporter:
              Thomas Diesler
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: