2:28 p.m.
Hi guys,
Since I started to work with OSGI a lot recently I start to feel more and
more that Forge should run on OSGI. We have discussed this before but I now
have a more clear view of how to do that.
How I would like to structure it:
-The shell becomes the most important bundle. In the bundle activator we
bootstrap Forge
-Every plugin (including all internal ones) become OSGI services in separate
bundles (this will hardly require any code changes)
-We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from
there
When the shell needs to execute a plugin, or need to create a list of
plugins it uses the BundleContext to retrieve all services that publish the
Plugin interface (which is currently already a marker interface). We iterate
over the list of services and check the @Alias annotation to know which
plugins are there.
After the plugin has been found we can iterate over all methods to find all
commands.
The service lookup mechanism can probably even be done in a nicer way by
using https://github.com/mathieuancelin/weld-osgi which looks excellent.
For plugins, everything will stay the same, we can still inject the Shell
etc, the only thing is that we actually inject services under the hood. It
will require a significant rewrite at the core, but I think it's do-able and
will avoid a lot of difficult problems later on. The largest problem at the
moment that I still worry about is that plugins are not really isolated from
the core at the moment, which makes it impossible for plugins to use
additional libraries for example. The maven build and project structure
won't have to change.
If we do this, it will give us a nice way to solve the plugin repository
problem too. We can use the existing bundle repository spec. for this which
includes transitive dependencies etc.
Just to demonstrate my idea I uploaded a very, very, simple prototype. This
uses bndtools which should be replaced by weld-osgi, but the code is pretty
similar: https://github.com/paulbakker/forge-osgi
Paul
5:25 p.m.
Hey Paul,
This is definitely the direction we should take, but I don't think we should
be using OSGI. I'd still like to use JBoss Modules since it is far simpler
and lighter, and also allows us to define our own module structure for
plugins, meaning we can re-use the existing maven repository for plugin
distribution, and also future proof us for the Java module system whenever
that comes around. It'll mean a little overhead work to get the plugin
loading done right, but I think it will be worth it to let people use Maven
natively and not worry about any kind of special packaging whatsoever.
I've started toying with JBoss Modules here:
https://github.com/forge/core/tree/master/plugin-loader
https://issues.jboss.org/browse/SEAMFORGE-136
Thoughts?
~Lincoln
On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
Hi guys,
Since I started to work with OSGI a lot recently I start to feel more and
more that Forge should run on OSGI. We have discussed this before but I now
have a more clear view of how to do that.
How I would like to structure it:
-The shell becomes the most important bundle. In the bundle activator we
bootstrap Forge
-Every plugin (including all internal ones) become OSGI services in
separate bundles (this will hardly require any code changes)
-We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from
there
When the shell needs to execute a plugin, or need to create a list of
plugins it uses the BundleContext to retrieve all services that publish the
Plugin interface (which is currently already a marker interface). We iterate
over the list of services and check the @Alias annotation to know which
plugins are there.
After the plugin has been found we can iterate over all methods to find all
commands.
The service lookup mechanism can probably even be done in a nicer way by
using https://github.com/mathieuancelin/weld-osgi which looks excellent.
For plugins, everything will stay the same, we can still inject the Shell
etc, the only thing is that we actually inject services under the hood. It
will require a significant rewrite at the core, but I think it's do-able and
will avoid a lot of difficult problems later on. The largest problem at the
moment that I still worry about is that plugins are not really isolated from
the core at the moment, which makes it impossible for plugins to use
additional libraries for example. The maven build and project structure
won't have to change.
If we do this, it will give us a nice way to solve the plugin repository
problem too. We can use the existing bundle repository spec. for this which
includes transitive dependencies etc.
Just to demonstrate my idea I uploaded a very, very, simple prototype. This
uses bndtools which should be replaced by weld-osgi, but the code is pretty
similar: https://github.com/paulbakker/forge-osgi
Paul
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5:40 p.m.
I still don't know much about JBoss Modules, but it would make sense because
they're both JBoss projects. On the other hand, OSGI is well proven now,
while JBoss Modules is relatively new. I'm sure it works great, but I'm more
worried about knowledge / best practices at this point.
Does JBoss Modules have a service model? I think that's an important
requirement. If it doesn't have a service model we would have to create one
ourselves and that would be like re-inventing OSGI.
We, and plugin writers, can still use Maven as they do now. The only extra
thing needed is the maven-bundle-plugin which will take care of generating
manifests:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html.
Packaging will stay exactly the same (just plain JAR files).
Using weld-osgi most of the code will stay the same as is, only the
bootstrap process and plugin loading mechanism will change considerably.
Maybe we should create a prototype both for osgi and Jboss Modules, and see
which works best.
I'll take a good look at your code this weekend :-)
Paul
On Fri, Jun 17, 2011 at 5:25 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Hey Paul,
This is definitely the direction we should take, but I don't think we
should be using OSGI. I'd still like to use JBoss Modules since it is far
simpler and lighter, and also allows us to define our own module structure
for plugins, meaning we can re-use the existing maven repository for plugin
distribution, and also future proof us for the Java module system whenever
that comes around. It'll mean a little overhead work to get the plugin
loading done right, but I think it will be worth it to let people use Maven
natively and not worry about any kind of special packaging whatsoever.
I've started toying with JBoss Modules here:
https://github.com/forge/core/tree/master/plugin-loader
https://issues.jboss.org/browse/SEAMFORGE-136
Thoughts?
~Lincoln
On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
> Hi guys,
>
> Since I started to work with OSGI a lot recently I start to feel more and
> more that Forge should run on OSGI. We have discussed this before but I now
> have a more clear view of how to do that.
>
> How I would like to structure it:
> -The shell becomes the most important bundle. In the bundle activator we
> bootstrap Forge
> -Every plugin (including all internal ones) become OSGI services in
> separate bundles (this will hardly require any code changes)
> -We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from
> there
>
> When the shell needs to execute a plugin, or need to create a list of
> plugins it uses the BundleContext to retrieve all services that publish the
> Plugin interface (which is currently already a marker interface). We iterate
> over the list of services and check the @Alias annotation to know which
> plugins are there.
> After the plugin has been found we can iterate over all methods to find
> all commands.
>
> The service lookup mechanism can probably even be done in a nicer way by
> using https://github.com/mathieuancelin/weld-osgi which looks excellent.
>
> For plugins, everything will stay the same, we can still inject the Shell
> etc, the only thing is that we actually inject services under the hood. It
> will require a significant rewrite at the core, but I think it's do-able and
> will avoid a lot of difficult problems later on. The largest problem at the
> moment that I still worry about is that plugins are not really isolated from
> the core at the moment, which makes it impossible for plugins to use
> additional libraries for example. The maven build and project structure
> won't have to change.
>
> If we do this, it will give us a nice way to solve the plugin repository
> problem too. We can use the existing bundle repository spec. for this which
> includes transitive dependencies etc.
>
> Just to demonstrate my idea I uploaded a very, very, simple prototype.
> This uses bndtools which should be replaced by weld-osgi, but the code is
> pretty similar: https://github.com/paulbakker/forge-osgi
>
> Paul
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:59 p.m.
I think doing a side-by side prototype would be an excellent test. Let's try
to do that and come together and see what we can make. I'll be focusing on
this significantly after I get back from JAXConf next week.
The reason I want to go toward JBoss Modules is because I think that we can
get things working with absolutely 0 code changes required for plugin
developers, and yes, also because it's a jboss project.
David, does JBM have the concept of a service model? I don't believe it
does, just checking. Paul, why do you think we'd need this? (Not familiar
with OSGi, so I just want to understand.)
~Lincoln
On Fri, Jun 17, 2011 at 11:40 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
I still don't know much about JBoss Modules, but it would make
sense
because they're both JBoss projects. On the other hand, OSGI is well proven
now, while JBoss Modules is relatively new. I'm sure it works great, but I'm
more worried about knowledge / best practices at this point.
Does JBoss Modules have a service model? I think that's an important
requirement. If it doesn't have a service model we would have to create one
ourselves and that would be like re-inventing OSGI.
We, and plugin writers, can still use Maven as they do now. The only extra
thing needed is the maven-bundle-plugin which will take care of generating
manifests:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html.
Packaging will stay exactly the same (just plain JAR files).
Using weld-osgi most of the code will stay the same as is, only the
bootstrap process and plugin loading mechanism will change considerably.
Maybe we should create a prototype both for osgi and Jboss Modules, and see
which works best.
I'll take a good look at your code this weekend :-)
Paul
On Fri, Jun 17, 2011 at 5:25 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> Hey Paul,
>
> This is definitely the direction we should take, but I don't think we
> should be using OSGI. I'd still like to use JBoss Modules since it is far
> simpler and lighter, and also allows us to define our own module structure
> for plugins, meaning we can re-use the existing maven repository for plugin
> distribution, and also future proof us for the Java module system whenever
> that comes around. It'll mean a little overhead work to get the plugin
> loading done right, but I think it will be worth it to let people use Maven
> natively and not worry about any kind of special packaging whatsoever.
>
> I've started toying with JBoss Modules here:
> https://github.com/forge/core/tree/master/plugin-loader
> https://issues.jboss.org/browse/SEAMFORGE-136
>
> Thoughts?
> ~Lincoln
>
> On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
>
>> Hi guys,
>>
>> Since I started to work with OSGI a lot recently I start to feel more and
>> more that Forge should run on OSGI. We have discussed this before but I now
>> have a more clear view of how to do that.
>>
>> How I would like to structure it:
>> -The shell becomes the most important bundle. In the bundle activator we
>> bootstrap Forge
>> -Every plugin (including all internal ones) become OSGI services in
>> separate bundles (this will hardly require any code changes)
>> -We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from
>> there
>>
>> When the shell needs to execute a plugin, or need to create a list of
>> plugins it uses the BundleContext to retrieve all services that publish the
>> Plugin interface (which is currently already a marker interface). We iterate
>> over the list of services and check the @Alias annotation to know which
>> plugins are there.
>> After the plugin has been found we can iterate over all methods to find
>> all commands.
>>
>> The service lookup mechanism can probably even be done in a nicer way by
>> using https://github.com/mathieuancelin/weld-osgi which looks
>> excellent.
>>
>> For plugins, everything will stay the same, we can still inject the Shell
>> etc, the only thing is that we actually inject services under the hood. It
>> will require a significant rewrite at the core, but I think it's do-able and
>> will avoid a lot of difficult problems later on. The largest problem at the
>> moment that I still worry about is that plugins are not really isolated from
>> the core at the moment, which makes it impossible for plugins to use
>> additional libraries for example. The maven build and project structure
>> won't have to change.
>>
>> If we do this, it will give us a nice way to solve the plugin repository
>> problem too. We can use the existing bundle repository spec. for this which
>> includes transitive dependencies etc.
>>
>> Just to demonstrate my idea I uploaded a very, very, simple prototype.
>> This uses bndtools which should be replaced by weld-osgi, but the code is
>> pretty similar: https://github.com/paulbakker/forge-osgi
>>
>> Paul
>>
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
6:39 p.m.
On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com>wrote:
The reason I want to go toward JBoss Modules is because I think that
we can
get things working with absolutely 0 code changes required for plugin
developers, and yes, also because it's a jboss project.
I have complete confidence that JBoss Modules [1] is the right way to go. It
may be young, but it has been very carefully designed by someone who has
crystal clear understanding of the problem. I'm not just saying that because
David's my respected colleague, it's backed up with proof in the form of AS
7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
I've heard the JavaDoc are very good as well. [4]
If you haven't yet, I strongly recommend all of you to watch the
presentation on JBoss Modules from JUDCon [5], which was given by David by
his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
importantly it explains how it relates to OSGi and Maven.
JBoss Modules truly is a good fit. Plus, Forge could really help get the
word out about the benefit of modularity in general.
-Dan
[1] https://github.com/jbossas/jboss-modules
[2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
[3]
http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsR...
[4]
https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jb...
[5] http://vimeo.com/24776447
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
2:53 p.m.
The osgi service model makes it possible to publish services to the runtime.
A service is just a Java interface, because services are running in the same
VM/runtime. Services are dynamic, meaning they can come and go any time.
From code you can ask the runtime for all services implementing a
specific
interface (other "query" metadata is possible too). With
weld-osgi it's
possble to do this completely using cdi annotations. Forge is already higly
modular at build time because Plugins are decoupled from other plugins. If
Plugins become services they are decoupled at runtime too. Forge and osgi
services seems to be a perfect fit to each other.
I've watched the JBoss world presentation (thanks for the links Dan!) and
JBM looks great too. JBM doesn't have a services layer though (which is an
explicit choice). We can live without though, since we already do now. The
largest problem that must be solved in Forge is the classloading itself, and
JBM does that perfectly. I would personally prefer OSGI because it offers a
bit more (services) than JBM which I believe is very useful for Forge, but
JBM being a JBoss project is a good argument to prefer this solution.
Either solution would keep the plugin development process exactly the same
as is. Plugin writers and users will not have to notice whatever we use.
I'll try to work on a prototype using OSGI, even if we go for JBM it will be
a fun experiment anyway ;-)
Paul
On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> The reason I want to go toward JBoss Modules is because I think that we
> can get things working with absolutely 0 code changes required for plugin
> developers, and yes, also because it's a jboss project.
>
>
I have complete confidence that JBoss Modules [1] is the right way to go.
It may be young, but it has been very carefully designed by someone who has
crystal clear understanding of the problem. I'm not just saying that because
David's my respected colleague, it's backed up with proof in the form of AS
7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
I've heard the JavaDoc are very good as well. [4]
If you haven't yet, I strongly recommend all of you to watch the
presentation on JBoss Modules from JUDCon [5], which was given by David by
his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
importantly it explains how it relates to OSGi and Maven.
JBoss Modules truly is a good fit. Plus, Forge could really help get the
word out about the benefit of modularity in general.
-Dan
[1] https://github.com/jbossas/jboss-modules
[2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
[3]
http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsR...
[4]
https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jb...
[5] http://vimeo.com/24776447
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:25 p.m.
Right, we currently get around the Weld bootstrap/runtime service
addition/removal issue by simply restarting the entire weld container. While
this is slightly costly, tbh, it really isn't that much of a hit because the
only time people are going to be adding/removing services is when they are
installing/updating/deleting plugins - that shouldn't happen too often, so I
think yes, we can probably live without such a feature :)
I'm still interested to see what each implementation looks like before we
make a decision. Again, I'm basically useless this week since I'm at JAX,
but I'll do my best to dig in and really prototype with JBM / maven when I
get back.
This is exciting :) This is one of those features that makes or breaks a
tool!
~Lincoln
On Sat, Jun 18, 2011 at 8:53 AM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
The osgi service model makes it possible to publish services to the
runtime. A service is just a Java interface, because services are running in
the same VM/runtime. Services are dynamic, meaning they can come and go any
time. From code you can ask the runtime for all services implementing a
specific interface (other "query" metadata is possible too). With weld-osgi
it's possble to do this completely using cdi annotations. Forge is already
higly modular at build time because Plugins are decoupled from other
plugins. If Plugins become services they are decoupled at runtime too. Forge
and osgi services seems to be a perfect fit to each other.
I've watched the JBoss world presentation (thanks for the links Dan!) and
JBM looks great too. JBM doesn't have a services layer though (which is an
explicit choice). We can live without though, since we already do now. The
largest problem that must be solved in Forge is the classloading itself, and
JBM does that perfectly. I would personally prefer OSGI because it offers a
bit more (services) than JBM which I believe is very useful for Forge, but
JBM being a JBoss project is a good argument to prefer this solution.
Either solution would keep the plugin development process exactly the same
as is. Plugin writers and users will not have to notice whatever we use.
I'll try to work on a prototype using OSGI, even if we go for JBM it will be
a fun experiment anyway ;-)
Paul
On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
> lincolnbaxter(a)gmail.com> wrote:
>
>> The reason I want to go toward JBoss Modules is because I think that we
>> can get things working with absolutely 0 code changes required for plugin
>> developers, and yes, also because it's a jboss project.
>>
>>
> I have complete confidence that JBoss Modules [1] is the right way to go.
> It may be young, but it has been very carefully designed by someone who has
> crystal clear understanding of the problem. I'm not just saying that because
> David's my respected colleague, it's backed up with proof in the form of AS
> 7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
> I've heard the JavaDoc are very good as well. [4]
>
> If you haven't yet, I strongly recommend all of you to watch the
> presentation on JBoss Modules from JUDCon [5], which was given by David by
> his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
> importantly it explains how it relates to OSGi and Maven.
>
> JBoss Modules truly is a good fit. Plus, Forge could really help get the
> word out about the benefit of modularity in general.
>
> -Dan
>
> [1] https://github.com/jbossas/jboss-modules
> [2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
> [3]
> http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsR...
> [4]
>
https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jb...
> [5] http://vimeo.com/24776447
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
9:02 p.m.
Paul,
Your points about OSGi are well made and definitely worth exploring.
I did leave out an important piece of information that may help bridge the
design gap.
One of the main motivators for creating JBoss Modules was to isolate the
concern of modular classloading from services, which are unnecessarily
coupled in OSGi. Of course, there is still an need for the services. That's
why the JBoss Modular Services Container [1] was created, to solve the other
half of the equation independently. JBM doesn't have a services layer
because MSC provides that :)
Together, JBoss Modules and the JBoss Modular Services Container match the
functionality that OSGi provides (you can look at it like a Venn Diagram,
with the overlap being the OSGi equivalent). JBoss even provides an OSGi
container, which as you can probably guess, is layered on top of this
foundation.
I would personally prefer OSGI because it offers a bit more (services) than
JBM which I believe is very useful for Forge, but JBM being a JBoss
project
is a good argument to prefer this solution.
In essence, I don't think we should limit ourselves to JBM either. On the
other hand, I don't know that we have to go all the way to OSGi. And I would
say that this choice has little to do with the fact that JBM and MSC are
JBoss projects. After all, if we used OSGi, we can use JBoss OSGi, or any
other compliant container. The ownership doesn't really concern me.
The reason I'm suggesting that we use JBM and MSC is because they are the
simplest possible tool that can solve the problem (the best tool for the
job). If they aren't, for some reason, then we can shift upwards to OSGi.
Make sense?
-Dan
[1] https://github.com/jbossas/jboss-msc
[2] https://github.com/jbosgi
On Sat, Jun 18, 2011 at 08:53, Paul Bakker <paul.bakker.nl(a)gmail.com> wrote:
The osgi service model makes it possible to publish services to the
runtime. A service is just a Java interface, because services are running in
the same VM/runtime. Services are dynamic, meaning they can come and go any
time. From code you can ask the runtime for all services implementing a
specific interface (other "query" metadata is possible too). With weld-osgi
it's possble to do this completely using cdi annotations. Forge is already
higly modular at build time because Plugins are decoupled from other
plugins. If Plugins become services they are decoupled at runtime too. Forge
and osgi services seems to be a perfect fit to each other.
I've watched the JBoss world presentation (thanks for the links Dan!) and
JBM looks great too. JBM doesn't have a services layer though (which is an
explicit choice). We can live without though, since we already do now. The
largest problem that must be solved in Forge is the classloading itself, and
JBM does that perfectly. I would personally prefer OSGI because it offers a
bit more (services) than JBM which I believe is very useful for Forge, but
JBM being a JBoss project is a good argument to prefer this solution.
Either solution would keep the plugin development process exactly the same
as is. Plugin writers and users will not have to notice whatever we use.
I'll try to work on a prototype using OSGI, even if we go for JBM it will be
a fun experiment anyway ;-)
Paul
On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
> lincolnbaxter(a)gmail.com> wrote:
>
>> The reason I want to go toward JBoss Modules is because I think that we
>> can get things working with absolutely 0 code changes required for plugin
>> developers, and yes, also because it's a jboss project.
>>
>>
> I have complete confidence that JBoss Modules [1] is the right way to go.
> It may be young, but it has been very carefully designed by someone who has
> crystal clear understanding of the problem. I'm not just saying that because
> David's my respected colleague, it's backed up with proof in the form of AS
> 7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
> I've heard the JavaDoc are very good as well. [4]
>
> If you haven't yet, I strongly recommend all of you to watch the
> presentation on JBoss Modules from JUDCon [5], which was given by David by
> his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
> importantly it explains how it relates to OSGi and Maven.
>
> JBoss Modules truly is a good fit. Plus, Forge could really help get the
> word out about the benefit of modularity in general.
>
> -Dan
>
> [1] https://github.com/jbossas/jboss-modules
> [2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
> [3]
> http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsR...
> [4]
>
https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jb...
> [5] http://vimeo.com/24776447
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
9:29 p.m.
That's interesting, I hadn't heard about the service container yet. Yes, if
we combine both we have basically the same thing as why I think OSGI would
be good, possibly even better and created within JBoss (so we have access
to the right people). I do think we really need a service layer, just
modules will only solve part of the problem so we should definitly look at
this.
So yes, it makes a lot of sense. I will spent some time on a prototype
anyway just because I want to try and then we have something to compare with
:-)
Paul
On Sat, Jun 18, 2011 at 9:02 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Paul,
Your points about OSGi are well made and definitely worth exploring.
I did leave out an important piece of information that may help bridge the
design gap.
One of the main motivators for creating JBoss Modules was to isolate the
concern of modular classloading from services, which are unnecessarily
coupled in OSGi. Of course, there is still an need for the services. That's
why the JBoss Modular Services Container [1] was created, to solve the other
half of the equation independently. JBM doesn't have a services layer
because MSC provides that :)
Together, JBoss Modules and the JBoss Modular Services Container match the
functionality that OSGi provides (you can look at it like a Venn Diagram,
with the overlap being the OSGi equivalent). JBoss even provides an OSGi
container, which as you can probably guess, is layered on top of this
foundation.
I would personally prefer OSGI because it offers a bit more (services) than
> JBM which I believe is very useful for Forge, but JBM being a JBoss project
> is a good argument to prefer this solution.
In essence, I don't think we should limit ourselves to JBM either. On the
other hand, I don't know that we have to go all the way to OSGi. And I would
say that this choice has little to do with the fact that JBM and MSC are
JBoss projects. After all, if we used OSGi, we can use JBoss OSGi, or any
other compliant container. The ownership doesn't really concern me.
The reason I'm suggesting that we use JBM and MSC is because they are the
simplest possible tool that can solve the problem (the best tool for the
job). If they aren't, for some reason, then we can shift upwards to OSGi.
Make sense?
-Dan
[1] https://github.com/jbossas/jboss-msc
[2] https://github.com/jbosgi
On Sat, Jun 18, 2011 at 08:53, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
> The osgi service model makes it possible to publish services to the
> runtime. A service is just a Java interface, because services are running in
> the same VM/runtime. Services are dynamic, meaning they can come and go any
> time. From code you can ask the runtime for all services implementing a
> specific interface (other "query" metadata is possible too). With
weld-osgi
> it's possble to do this completely using cdi annotations. Forge is already
> higly modular at build time because Plugins are decoupled from other
> plugins. If Plugins become services they are decoupled at runtime too. Forge
> and osgi services seems to be a perfect fit to each other.
>
> I've watched the JBoss world presentation (thanks for the links Dan!) and
> JBM looks great too. JBM doesn't have a services layer though (which is an
> explicit choice). We can live without though, since we already do now. The
> largest problem that must be solved in Forge is the classloading itself, and
> JBM does that perfectly. I would personally prefer OSGI because it offers a
> bit more (services) than JBM which I believe is very useful for Forge, but
> JBM being a JBoss project is a good argument to prefer this solution.
>
> Either solution would keep the plugin development process exactly the same
> as is. Plugin writers and users will not have to notice whatever we use.
> I'll try to work on a prototype using OSGI, even if we go for JBM it will be
> a fun experiment anyway ;-)
>
> Paul
>
> On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
>
>> On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
>> lincolnbaxter(a)gmail.com> wrote:
>>
>>> The reason I want to go toward JBoss Modules is because I think that we
>>> can get things working with absolutely 0 code changes required for plugin
>>> developers, and yes, also because it's a jboss project.
>>>
>>>
>> I have complete confidence that JBoss Modules [1] is the right way to go.
>> It may be young, but it has been very carefully designed by someone who has
>> crystal clear understanding of the problem. I'm not just saying that because
>> David's my respected colleague, it's backed up with proof in the form of
AS
>> 7, his blogs about modularity [2] [3] and the JBoss Modules presentation.
>> I've heard the JavaDoc are very good as well. [4]
>>
>> If you haven't yet, I strongly recommend all of you to watch the
>> presentation on JBoss Modules from JUDCon [5], which was given by David by
>> his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
>> importantly it explains how it relates to OSGi and Maven.
>>
>> JBoss Modules truly is a good fit. Plus, Forge could really help get the
>> word out about the benefit of modularity in general.
>>
>> -Dan
>>
>> [1] https://github.com/jbossas/jboss-modules
>> [2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
>> [3]
>>
http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsR...
>> [4]
>>
https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jb...
>> [5] http://vimeo.com/24776447
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4695
days inactive
4696
days old
8 comments
3 participants
participants (3)
-
Dan Allen -
Lincoln Baxter, III -
Paul Bakker