Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: Repository Support 2010
-
Component/s: Maven Builds
-
Labels:None
-
Similar Issues:
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
- is blocked by
-
ORG-237
Provide hardware for a maven proxy server which can be used by the project builds.
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
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 
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 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
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
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.
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. "* 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 ?
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 ? 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
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 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 ;(
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 ;( 
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.