[jboss-dev] AS jars from maven repository

[Adrian Brock]

The correct way to do this is to use the requirements and add a resolver
that knows about maven.

That way you dont care whether this jar;

1) Is already deployed
2) Is in the profile service repository
3) Is coming from maven
4) Is coming from an osgi repository
etc.

Config (i would recommend you require packages because of refactoring
issues):

   <classloader name="resteasy-classloader"
xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
 <requirements>
     <module name="org.jboss.resteasy:resteasy-jaxrs" version="2.0-RC1">
 </requirements>
</classloader>

Interface to implement that knows about maven:

http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/Resolver.java

The resolver will only get used, if it is not already deployed.

<!-- your resolver -->
<bean name="MavenResolver" ...

<!-- Change to config to automatically register all things that implement
that interface: -->
<bean name="ClassLoading" ...>

    ...

    <incallback method="addResolver"/>
    <uncallback method="removeResolver"/>
</bean>

Further comments in line.

On Wed, Jul 14, 2010 at 12:55 AM, Bill Burke <bburke at redhat.com> 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.
>
>
It shouldnt require you specify that your source is maven either.
You just want to specify the name and version.


> 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.
>
>
Emmanuel has code that knows how to do the download from the
remote repository. But his version embeds the jar in each deployment
so you cant share classes if it is in two deployments unlike
the requirement declaration which shares (assuming they are in
the same classloading domain).


> 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.
>
>
Dont use <classloader> in deployments, use jboss-classloading.xml
or do it programmatically to the ClassLoadingMetaData attachment.


> I also might need some help if there are any scoping issues as the
> classloader code is a spaghetti mess.
>
>
Probably because things are hidden to make it hard for people (like you) to
do things
the wrong way or play with things they shouldn't, lol


>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100714/6d4029ed/attachment.html