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

        Gliffy Diagrams

          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:

                  Development