Re: [jboss-dev] AS jars from maven repository
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.