bundles as modules?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bundles as modules?

Bill Burke
Is there any way we could get the OSGi bundles configured and deployed
as modules?  I know David talked something about this earlier.  We all
talked earlier about the maven artifact stuff I'm doing with JBoss
Modules, and the OSGI bundles are the only thing that I have excluded
from my JBoss AS build script that sets this up.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: bundles as modules?

Thomas Diesler
What do you mean? Bundle become modules when they get deployed at runtime. The reason that the 'bundles' directory exists is that the artefacts in there have their respective dependencies defined in standard OSGi metadata, which makes them bundles (i.e. a bundle cannot have a modules.xml file).

Perhaps you could explain (again) the motivating goal for your question.

cheers
--thomas

On Apr 12, 2013, at 4:46 PM, Bill Burke <[hidden email]> wrote:

> Is there any way we could get the OSGi bundles configured and deployed
> as modules?  I know David talked something about this earlier.  We all
> talked earlier about the maven artifact stuff I'm doing with JBoss
> Modules, and the OSGI bundles are the only thing that I have excluded
> from my JBoss AS build script that sets this up.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: bundles as modules?

Bill Burke
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.

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.

On 4/15/2013 4:37 AM, Thomas Diesler wrote:

> What do you mean? Bundle become modules when they get deployed at runtime. The reason that the 'bundles' directory exists is that the artefacts in there have their respective dependencies defined in standard OSGi metadata, which makes them bundles (i.e. a bundle cannot have a modules.xml file).
>
> Perhaps you could explain (again) the motivating goal for your question.
>
> cheers
> --thomas
>
> On Apr 12, 2013, at 4:46 PM, Bill Burke <[hidden email]> wrote:
>
>> Is there any way we could get the OSGi bundles configured and deployed
>> as modules?  I know David talked something about this earlier.  We all
>> talked earlier about the maven artifact stuff I'm doing with JBoss
>> Modules, and the OSGI bundles are the only thing that I have excluded
>> from my JBoss AS build script that sets this up.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: bundles as modules?

Thomas Diesler

On Apr 16, 2013, at 2:56 PM, Bill Burke <[hidden email]> 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 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.


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

cheers
--thomas  


On 4/15/2013 4:37 AM, Thomas Diesler wrote:
What do you mean? Bundle become modules when they get deployed at runtime. The reason that the 'bundles' directory exists is that the artefacts in there have their respective dependencies defined in standard OSGi metadata, which makes them bundles (i.e. a bundle cannot have a modules.xml file).

Perhaps you could explain (again) the motivating goal for your question.

cheers
--thomas

On Apr 12, 2013, at 4:46 PM, Bill Burke <[hidden email]> wrote:

Is there any way we could get the OSGi bundles configured and deployed
as modules?  I know David talked something about this earlier.  We all
talked earlier about the maven artifact stuff I'm doing with JBoss
Modules, and the OSGI bundles are the only thing that I have excluded
from my JBoss AS build script that sets this up.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




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

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: bundles as modules?

Bill Burke


On 4/16/2013 9:07 AM, Thomas Diesler wrote:

>
> On Apr 16, 2013, at 2:56 PM, Bill Burke <[hidden email]
> <mailto:[hidden email]>> 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.

>>
>> 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...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: bundles as modules?

Thomas Diesler

On Apr 16, 2013, at 3:18 PM, Bill Burke <[hidden email]> wrote:



On 4/16/2013 9:07 AM, Thomas Diesler wrote:

On Apr 16, 2013, at 2:56 PM, Bill Burke <[hidden email]
<[hidden email]>> 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. 

Yes, there should be no dependency on the OSGi Framework. The org.osgi.resource 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)

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. Another standard that defines dependencies between resources is feasible and in its most simplistic form would use named dependencies. JBoss could decide to ignore the standard and treat everything in a proprietary way (i.e. with metadata defined in modules.xml). The result would be that JBoss says: I know the dependencies of Foo better than the author of Foo and replace loosely coupled dependency definitions by hard wired named dependencies. This would still work as long as Foo is part of the build process and subject to extensive QA validation. It would break, when Foo is allowed to come in late (i.e. at runtime). JBoss would require the author of Foo to provide an alternative set of named dependencies in a propriatary way that is only valid for a specific state of the runtime environment (i.e. the author/deployer must know the set of named resources that are available at deploy time). As a result Foo is not a module any more that can be reasoned about independently. 

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

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>
>>
>> On 4/16/2013 9:07 AM, Thomas Diesler wrote:
>>>
>>> On Apr 16, 2013, at 2:56 PM, Bill Burke <[hidden email]
>>> <mailto:[hidden email]>
>>> <mailto:[hidden email]>> 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev