[jboss-dev] AS jars from maven repository

Andrew Lee Rubinger andrew.rubinger at redhat.com
Tue Jul 13 23:26:53 EDT 2010


We've been discussing similar problems from within the ShrinkWrap context.

The idea is that we want to say something like:

JavaArchive archive = MavenArchive.create("groupId:artifactId:classifier");

Sure, you can look by default in some hardcoded repos (JBoss Nexus, then 
~/.m2/repository/, etc), but this negates the configuration to have:

1) Alternate external repos
2) Alternate local repos in a non-default location (which is usually 
specified in some settings.xml, also may be located in a non-default 
location)

At first glance I figure the grammar above is fine for defaults, but we 
*must* hook in a configuration option somehow to define overrides, 
preferably from some settings.xml format located *somewhere*.  We 
haven't yet settled on an intelligent/intuitive way of providing this 
hook without muddying the API however.

Awesome feature for <classloader> in VFS, BTW.  Carlo did a similar one 
as well in the Reloaded prototype, using a backing Ivy library to do the 
resolution off a known/configured Maven2 repo structure.

S,
ALR

On 07/13/2010 07:55 PM, Bill Burke wrote:
> I've made a small change to jboss-classloading-vfs in my working copy so
> that you can define a<maven-artifact>  within a beans<classloader>
> declaration, i.e.:
>
>      <classloader name="resteasy-classloader"
> xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
>
> <maven-artifact>org.jboss.resteasy:resteasy-jaxrs:2.0-RC1</maven-artifact>
>
> <maven-artifact>org.jboss.resteasy:async-http-servlet-3.0:2.0-RC1</maven-artifact>
>      </classloader>
>
> It has no dependency on the profile service (not sure why Scott/Julien
> wanted to do it that way anyways), just a simple change to the
> VFSClassLoaderPolicyModule and XML metadata classes.
>
> I currently have it hardcoded to look in $HOME/.m2/repository for maven
> artifacts, and it assumes the .jar name can be discovered from the
> artifact URI.
>
> Any interest and moving this forward at all?  The idea would be to look
> for artifacts in this order:
>
> 1. $JBOSS_MAVEN_REPOSITORY
> 2. $JBOSS_HOME/maven-repository
> 3. $HOME/.m2/repository
>
> The repository would have to be on local disk.  This would greatly
> reduce our distribution size as there would be no copies of jars
> anywhere.  It would also help development as you would not have to keep
> rebuilding the AS distribution, or manually copying jar files to test
> individual work you are doing.  It would just be a change to the
> artifact declaration.
>
> The work would be in creating a<classloader>  entry in each deployment
> and creating the $JBOSS_HOME/maven-repository.  A maven plugin could be
> written to create a beans file with classloader info in it.  The only
> problem I see with that is some deployment units have multiple beans.xml
>    files and I don't know if<classloader>  is processed in all beans.xml
> first before the bean metadata.
>
> I also might need some help if there are any scoping issues as the
> classloader code is a spaghetti mess.
>
>


More information about the jboss-development mailing list