[jboss-dev] AS jars from maven repository

[Carlo de Wolf]

It's very similar to your stuff, Bill.

First I define a repo-classloader: 
http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/repoclassloader/src/test/resources/conf/bootstrap/repo.xml

The not so nice magic bit is that RepoResolver is injected into 
RepoClassLoaderPolicyModule. That bit should really be reflected in the 
repo.xml.

And then I put inline ivy descriptor elements: 
http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/repoclassloader/src/test/resources/conf/bootstrap/aop.xml

It works with $HOME/.m2/repository or any other Maven / Ivy repository.

I even have a booting AS 5.0.1 with it: 
http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/as5_0_1-profile/

Carlo

On 07/14/2010 05:26 AM, Andrew Lee Rubinger wrote:
> 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.
>>
>>
>>      
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>