[jboss-as7-dev] bundles as modules?

[Bill Burke]

On 4/16/2013 10:10 AM, Thomas Diesler wrote:
>
> On Apr 16, 2013, at 3:18 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>>
>>
>> On 4/16/2013 9:07 AM, Thomas Diesler wrote:
>>>
>>> On Apr 16, 2013, at 2:56 PM, Bill Burke <bburke at redhat.com
>>> <mailto:bburke at redhat.com>
>>> <mailto:bburke at redhat.com>> wrote:
>>>
>>>> I'm trying to make a AS distribution that has no jars.  Instead,
>>>> metadata points to a maven repository location for those jars.  I've
>>>> patched Jboss Modules to make this work, but have no solution for OSGi.
>>>
>>> This may relate to the Provisioner service
>>> <http://community.jboss.org/wiki/ProvisionerServiceAndFeatureDeployment>
>>> topic.
>>> We already have a component that understands Maven coordinates and can
>>> provide named resources. If you are thinking of a special ModuleLoader
>>> that can fetch modules on demand then this loader should preferably
>>> simply call the Repository IMHO. In the near future it could call the
>>> Provisioner service with the top level Requirements.
>>>
>>
>> Here's my pull request.
>>
>> https://github.com/jbossas/jboss-modules/pull/28
>>
>> With this patch, only jar you need to boot jboss is jboss-modules.jar.
>> It will optionally download (or look in local maven repository) for
>> any other required jars.  I've written a bunch of long emails why this
>> feature is interesting, I could forward them if you're interested.
>>
>> I don't see why we'd want an AS dependency on some OSGi service.  The
>> idea of only needing one *local* jar to boot AS is much more
>> appealing, IMO.
>
> I'd say that "one local jar" should first fetch a component that can
> provision the system in a consistent way. It would then work with a
> small set of top level requirements (i.e. one per subsystem). The
> transitive closure of jars that actually need to be provisioned to
> satisfy the feature requests should to be computed by a authority that
> guarantees a consistent solution (i.e. a Resolver) - the maven
> dependency tree is not suitable for this IMHO.
>

I don't know if we disagree here :)  I'm talking about changing absolute 
or relative file references to maven repository coordinates.  Thats it. 
  The solution I currently have with JBoss Modules is very simple.

> Yes, there should be no dependency on the OSGi Framework. The
> org.osgi.resource
> <http://www.osgi.org/javadoc/r5/core/org/osgi/resource/package-summary.html> API
> qualifies to model resources with associated capabilities/requirements
> just like any other API. It has intentionally been designed such that it
> is independent of OSGi. A resource can of course define named
> requirements on other resources as we do with modules.xml today. A named
> dependency however is a form of tight coupling, which violates the
> fundamental principal of modularity that you should be able to reason
> about A without having to know that B has a dependency on A - A and B
> should only define their own respective caps/reqs. It is the job of a
> resolver to figure out that B actually depends on A and not on some
> other resource that also provides a capability that B requires (e.g. a
> java package)
>

I don't want to replace i.e. module.xml with a maven dependency graph. 
I just want module.xml to reference maven coordinates for its jars and 
files.  Basically to reduce the AS distro from 100M+ to < 1M.


> There should be no performance hit for that process. The Resolver could
> have a persistent view of wiring metadata that can be computed at build
> time. Performance wise this would be equivalent to reading module.xml
> files only that there is a guarantee that the wiring is consistent and
> that dependencies can be defined in a modular fashion.
>
>>
>>>>
>>>> David Lloyd said he didn't understand why your bundles weren't
>>>> deployed as modules.  I don't know what that means either, but that's
>>>> what he said.
>>>
>>> Don't what this means either ;-) but I regularly talk with him so I can
>>> probably find out
>>
>> Maybe that the OSGi layer delegates to JBoss Modules to resolve
>> classloader dependencies?  That would make sense…
>
> Dependencies defined by OSGi metadata are complex and go beyond the hard
> wired named dependencies that we have today - so in fact it would not
> make sense at all if you want to support the de-facto standard for
> modularity.

Are you mixing classloader dependencies with service dependencies?  Why 
do classloader dependencies need to be any more complicated than the 
metadata required for something like a linker?  Classloader and service 
dependencies should be a separate thing IMO, one layered on top of the 
other like what exists between JBoss Modules and AS deployments.  Mixing 
this type of metadata is a bad aproach, IMO, but I don't know enough 
about OSGi to know if it does that or not...Please argue with David or 
somebody else though.  I really don't care so long as OSGi is optional 
and AS puts some thought into usability and not make us developers be 
human linkers.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com