Re: [jboss-dev] AS jars from maven repository

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