On 01/05/2010 09:54 AM, Bill Burke wrote:
Brian Stansberry wrote:
> On 01/05/2010 09:24 AM, Bill Burke wrote:
>>>> Instead of a jboss-classloading.xml, why not reading the manifest? Or
>>>> is somebody working on that?
>>> This is something we're definitely planning.
>>> I once discussed it with Scott what we should support.
>>> Afair, we agreed on supporting both.
>>> But as you can see from SS+OSGi_repo story, this is not as trivial as it
>>> Once we have this fully in place, DML's modularization, etc,
>>> we should make sure we can re-use stuff from SS's repo.
>> There's already a osgi maven bundle plugin. Why not use it?
>> Why not use that to generate exported packages? Just tried it out.
>> Pretty cool.
> Looks like that can handle exporting all packages via a simple wildcard.
You don't even need to do that. Just put in the plugin with a regular
The question is though, does the VFS get bypassed if this is put in?
Because scanning for packages isn't slow once the VFS context is
initialized. The time is all within initializing the VFS context for
I'm curious how much difference VFS3 will make in this. I've asked John
Bailey to ping you about getting ahold of your test.
Or, is VFS still used for every deployed jar because of
Most of our jars are not packaged in deployments, they're added to the
classpath via conf/jboss-service.xml. I'm looking now at what the
structural deployers do with a simple single-file deployment like that.
Lead, AS Clustering
JBoss by Red Hat