The correct way to do this is to use the requirements and add a resolver<br>that knows about maven.<br><br>That way you dont care whether this jar;<br><br>1) Is already deployed<br>2) Is in the profile service repository<br>
3) Is coming from maven<br>4) Is coming from an osgi repository<br>etc.<br><br>Config (i would recommend you require packages because of refactoring issues):<br><br> <classloader name="resteasy-classloader"<br>
xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY"
import-all="true"><div> <requirements><br> <module name="org.jboss.resteasy:resteasy-jaxrs" version="2.0-RC1"><br> </requirements><br>
</div></classloader><br><br>Interface to implement that knows about maven:<br><br><a href="http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/Resolver.java">http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/Resolver.java</a><br>
<br>The resolver will only get used, if it is not already deployed.<br><br><!-- your resolver --><br><bean name="MavenResolver" ...<br><br><!-- Change to config to automatically register all things that implement
that interface: --><br><bean name="ClassLoading" ...><br><br> ...<br><br> <incallback method="addResolver"/><br> <uncallback method="removeResolver"/><br>
</bean><br><br>Further comments in line.<br><br><div class="gmail_quote">On Wed, Jul 14, 2010 at 12:55 AM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I've made a small change to jboss-classloading-vfs in my working copy so<br>
that you can define a <maven-artifact> within a beans <classloader><br>
declaration, i.e.:<br>
<br>
<classloader name="resteasy-classloader"<br>
xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true"><br>
<br>
<maven-artifact>org.jboss.resteasy:resteasy-jaxrs:2.0-RC1</maven-artifact><br>
<br>
<maven-artifact>org.jboss.resteasy:async-http-servlet-3.0:2.0-RC1</maven-artifact><br>
</classloader><br>
<br>
It has no dependency on the profile service (not sure why Scott/Julien<br>
wanted to do it that way anyways), just a simple change to the<br>
VFSClassLoaderPolicyModule and XML metadata classes.<br>
<br></blockquote><div><br>It shouldnt require you specify that your source is maven either.<br>You just want to specify the name and version.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I currently have it hardcoded to look in $HOME/.m2/repository for maven<br>
artifacts, and it assumes the .jar name can be discovered from the<br>
artifact URI.<br>
<br>
Any interest and moving this forward at all? The idea would be to look<br>
for artifacts in this order:<br>
<br>
1. $JBOSS_MAVEN_REPOSITORY<br>
2. $JBOSS_HOME/maven-repository<br>
3. $HOME/.m2/repository<br>
<br>
The repository would have to be on local disk. This would greatly<br>
reduce our distribution size as there would be no copies of jars<br>
anywhere. It would also help development as you would not have to keep<br>
rebuilding the AS distribution, or manually copying jar files to test<br>
individual work you are doing. It would just be a change to the<br>
artifact declaration.<br>
<br></blockquote><div><br>Emmanuel has code that knows how to do the download from the<br>remote repository. But his version embeds the jar in each deployment<br>so you cant share classes if it is in two deployments unlike<br>
the requirement declaration which shares (assuming they are in<br>the same classloading domain).<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The work would be in creating a <classloader> entry in each deployment<br>
and creating the $JBOSS_HOME/maven-repository. A maven plugin could be<br>
written to create a beans file with classloader info in it. The only<br>
problem I see with that is some deployment units have multiple beans.xml<br>
files and I don't know if <classloader> is processed in all beans.xml<br>
first before the bean metadata.<br>
<br></blockquote><div><br>Dont use <classloader> in deployments, use jboss-classloading.xml<br>or do it programmatically to the ClassLoadingMetaData attachment.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I also might need some help if there are any scoping issues as the<br>
classloader code is a spaghetti mess.<br>
<div class="im"><br></div></blockquote><div><br>Probably because things are hidden to make it hard for people (like you) to do things<br>the wrong way or play with things they shouldn't, lol<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">jboss-development mailing list<br>
<a href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-development" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-development</a><br>
</div></div></blockquote></div><br>