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.

It's very similar to your stuff, Bill. First I define a repo-classloader: http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/repoclassl... 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/repoclassl... 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-pr... 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

It's very similar to your stuff, Bill. First I define a repo-classloader: http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/repoclassl... 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/repoclassl... 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-pr... 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

<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>

It would work in both, but for what Bill wants, I think you are correct.

Although as I understand it, he is actually creating a bean inside a deployment?

Bill's approach wont know anything about the scoping rules of the deployment as he correctly points out.

On Wed, Jul 14, 2010 at 9:43 AM, Ales Justin <ales.justin(a)gmail.com&gt; wrote: > <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> The top element here should actually be <classloading>, not <classloader>. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

<deployment <classloader>...</classloader> </deployment> I couldn't figure out how to deal with jboss-classloading files.