[jboss-dev] AS jars from maven repository

[Bill Burke]

seems a bit too verbose and heavy on the processing.  I'm thinking that 
actually resolving and downloading dependencies is a bit overkill.

Carlo de Wolf wrote:
> 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
>>    
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com