How can I resolve artifacts for deployment?

(lists) #1

We’ve got a large number (100+) of Maven builds written in-house that my group is responsible for deploying to JBoss 5 and 6. We tried using Cargo for a while, then gave up and switched to using Wagon to SCP the file, then SSHing in to the box to restart JBoss when necessary. We basically hijacked the “validate” goal to do these things.

The problem is that doing this requires profiles for all of the environments that we push to – meaning that every pom.xml in an ear project has a profile for dev, a profile for qa, a profile for uat, a profile for srt and a profile for prod. We support 7 different Java development departments, so these profiles can become quite large, which of course makes the ear pom HUGE, which tends to anger some developers.

We tried extracting these profiles out to the settings.xml file, but it’s not the Maven Way, so it’s not supported. We tried creating a pom.xml that just had the profile info and declaring it as a dependency, but, again, it’s not the Maven Way, and the profiles don’t get picked up.

There’s no way I can talk 60 developers into converting their hundred-plus projects to gradle, so I’m wondering if there’s a way that I can use Gradle to simply use the existing poms to extract out the groupID/artifactID/version and repo information for the project itself.

I’m fine with getting Gradle to scp the files and ssh in to bounce jboss, but could anyone point me toward a good way to leverage the existing poms (and the validate goal) to grab the artifacts?

Thanks, John

(René Groeschke) #2

Not sure if I understand you correctly, but in general you can resolve a pom of a project by using

configurations { poms }
    poms "org.acme:proj1:1.0@pom"

The you can use the resolved poms to read manually the information you request. Does this answer your question?

cheers, René