|
»
»
»
« Return to Thread: Maven core : Plexus vs Spring / OSGi ?
Re: Maven core : Plexus vs Spring / OSGi ?
by John Casey-5
::
Rate this Message:
I have to say that I'm not at all interested in moving to Spring. At
all. I've used both Spring and Plexus, and while I don't think Plexus
is the end-all, be-all, it's better IMO than Spring. As far as
annotations go, I completely agree with Jason, that Annotations
should be standardized, and framework-agnostic. As for OSGi, I think
we're definitely moving in the direction of that type of system in
the 2.1 extensions and plugin handling code, but I'd be a little
hesitant to make the decision to give up all control over our
classloading model without doing some serious tests on a branch to
make sure OSGi can support our needs. IMO, ClassWorlds is fast
approaching the capability of OSGi in terms of raw classloading
flexibility.
I have to say that I take some issue with the idea that we should
completely refactor Maven to "standards" - which, by the way, are
only popular items when we're talking about Spring, not specified
standards that have more than one implementation - just so our users
will get warm fuzzies about using the tool. From the user's
perspective, if we have the bugs worked out of this system properly
(we don't) then it absolutely shouldn't matter. If we get our
annotations standardized to something that truly is being used by a
large number of projects (where Spring is just one project...I'm not
talking about all the projects *using* Spring), then plugin
development shouldn't be that difficult to wrap one's head around.
For many applications, it's actually not that hard now, as you don't
need to interact with Plexus that much as-is. For instance, you don't
even know that it's Plexus doing the DI for your plugin when you use
@component annotations in your plugin...if that annotation were
standardized, it would matter even less.
I can appreciate that you don't want to learn another suite of
technologies in order to be able to work on Maven, but I can repeat
your argument back to you: I'm not interested in learning a suite of
new apis in order to keep developing on Maven...at least, not unless
there is a compelling reason.
My two cents.
-john
On May 2, 2008, at 3:25 PM, nicolas de loof wrote:
> From the fiew documentation available, XBean seems to be a
> container for
> jsr250-based components, with plugability for various IoC containers.
>
> The "discover, download and install" plugin model seems to be very
> similar
> to OSGi, and the link to Eclipse Equinox makes me suppose it's OSGi
> based
> under the hood.
>
> This looks very similar to Spring-DM + Equinox, with support for
> multiple
> IoC containers.
>
> If maven only needs jsr-250 + custom annotations, it could be IoC
> container
> agnostic, beeing Spring or anything else with same features.
>
>> I also have never bought the argument that what's popular is
>> what's best.
> Maven wouldn't exist if that were the
>> case. There's always room for competitors.
>
> beeing the most popular is not a technical argument, but this is to be
> considered :
> 1. the leader may not be technicaly stupid, beeing the leader
> 2. when used as a service, the documentation / good knoledge from
> developer community is IMHO a big element to consider.
>
> Sorry to say, but I allready had to learn Spring in deep,
> some limited Plexus, and now OSGi, I won't look more at XBean until
> it gets
> mainly used or comes with highly innovative features.
>
> I agrea there is always room for competitors and that's a good
> thing to see
> people come with new ideas and projects, but just some "nice"
> features is
> not enough for me to choose a software, as what maven expect from it's
> container is limited to simple IoC (no AOP, declarative TX, bytecode
> instrumentation...) and advanced classloader/plugability. Only the
> second
> criteria can help the choice, and OSGi seems to be the most promising
> technology.
>
> About "Maven wouldn't exist if that were the case", please remember
> Maven1
> was desinged as a "let's share common ANT scripts" and envolved on
> this
> basis, and Maven2 was a "lets take what was good in M1 and make it
> stronger". You never build from scratch, but allways start from
> what is
> considered good.
>
> Today, what is considered good is
> - about IoC : to be non-intrusive (plexus IS intrusive, as LogEnabled
> demonstrates in most of classes) and to be compliant with the fiew
> existing
> standards (JSR250 or other).
> - about plugin-based-architecture : hot deployment, replacement and
> concurrent versionning, with OSGI as the only recognized candidate
> (as JSR
> for "java modules" is still WIP)
>
> Nicolas.
>
>
> 2008/5/2 Jesse McConnell <jesse.mcconnell@...>:
>
>> http://geronimo.apache.org/xbean
>>
>> On Fri, May 2, 2008 at 1:04 PM, Hilco Wijbenga
>> <hilco.wijbenga@...>
>> wrote:
>>> On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl <jason@...>
>>> wrote:
>>> <snip/>
>>>
>>>> And ultimately the container DI is not the important part but the
>>>> implementations of our components. Using standard annotations for
>> that is a
>>>> good thing and that's not hard. XBR does full JEE injection and can
>> manage
>>>> any sort of annotation based DI because it's entirely agnostic. At
>> any rate
>>>> full support for that is now possible with XBR.
>>>
>>> XBR? I did some googling but all I could find (aside from lots
>>> of TVs)
>>> was a reference to an apparently brand new Maven 2.1 project. No
>>> website or anything. Where can I find more information?
>>>
>>> Cheers,
>>> Hilco
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
all. I've used both Spring and Plexus, and while I don't think Plexus
is the end-all, be-all, it's better IMO than Spring. As far as
annotations go, I completely agree with Jason, that Annotations
should be standardized, and framework-agnostic. As for OSGi, I think
we're definitely moving in the direction of that type of system in
the 2.1 extensions and plugin handling code, but I'd be a little
hesitant to make the decision to give up all control over our
classloading model without doing some serious tests on a branch to
make sure OSGi can support our needs. IMO, ClassWorlds is fast
approaching the capability of OSGi in terms of raw classloading
flexibility.
I have to say that I take some issue with the idea that we should
completely refactor Maven to "standards" - which, by the way, are
only popular items when we're talking about Spring, not specified
standards that have more than one implementation - just so our users
will get warm fuzzies about using the tool. From the user's
perspective, if we have the bugs worked out of this system properly
(we don't) then it absolutely shouldn't matter. If we get our
annotations standardized to something that truly is being used by a
large number of projects (where Spring is just one project...I'm not
talking about all the projects *using* Spring), then plugin
development shouldn't be that difficult to wrap one's head around.
For many applications, it's actually not that hard now, as you don't
need to interact with Plexus that much as-is. For instance, you don't
even know that it's Plexus doing the DI for your plugin when you use
@component annotations in your plugin...if that annotation were
standardized, it would matter even less.
I can appreciate that you don't want to learn another suite of
technologies in order to be able to work on Maven, but I can repeat
your argument back to you: I'm not interested in learning a suite of
new apis in order to keep developing on Maven...at least, not unless
there is a compelling reason.
My two cents.
-john
On May 2, 2008, at 3:25 PM, nicolas de loof wrote:
> From the fiew documentation available, XBean seems to be a
> container for
> jsr250-based components, with plugability for various IoC containers.
>
> The "discover, download and install" plugin model seems to be very
> similar
> to OSGi, and the link to Eclipse Equinox makes me suppose it's OSGi
> based
> under the hood.
>
> This looks very similar to Spring-DM + Equinox, with support for
> multiple
> IoC containers.
>
> If maven only needs jsr-250 + custom annotations, it could be IoC
> container
> agnostic, beeing Spring or anything else with same features.
>
>> I also have never bought the argument that what's popular is
>> what's best.
> Maven wouldn't exist if that were the
>> case. There's always room for competitors.
>
> beeing the most popular is not a technical argument, but this is to be
> considered :
> 1. the leader may not be technicaly stupid, beeing the leader
> 2. when used as a service, the documentation / good knoledge from
> developer community is IMHO a big element to consider.
>
> Sorry to say, but I allready had to learn Spring in deep,
> some limited Plexus, and now OSGi, I won't look more at XBean until
> it gets
> mainly used or comes with highly innovative features.
>
> I agrea there is always room for competitors and that's a good
> thing to see
> people come with new ideas and projects, but just some "nice"
> features is
> not enough for me to choose a software, as what maven expect from it's
> container is limited to simple IoC (no AOP, declarative TX, bytecode
> instrumentation...) and advanced classloader/plugability. Only the
> second
> criteria can help the choice, and OSGi seems to be the most promising
> technology.
>
> About "Maven wouldn't exist if that were the case", please remember
> Maven1
> was desinged as a "let's share common ANT scripts" and envolved on
> this
> basis, and Maven2 was a "lets take what was good in M1 and make it
> stronger". You never build from scratch, but allways start from
> what is
> considered good.
>
> Today, what is considered good is
> - about IoC : to be non-intrusive (plexus IS intrusive, as LogEnabled
> demonstrates in most of classes) and to be compliant with the fiew
> existing
> standards (JSR250 or other).
> - about plugin-based-architecture : hot deployment, replacement and
> concurrent versionning, with OSGI as the only recognized candidate
> (as JSR
> for "java modules" is still WIP)
>
> Nicolas.
>
>
> 2008/5/2 Jesse McConnell <jesse.mcconnell@...>:
>
>> http://geronimo.apache.org/xbean
>>
>> On Fri, May 2, 2008 at 1:04 PM, Hilco Wijbenga
>> <hilco.wijbenga@...>
>> wrote:
>>> On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl <jason@...>
>>> wrote:
>>> <snip/>
>>>
>>>> And ultimately the container DI is not the important part but the
>>>> implementations of our components. Using standard annotations for
>> that is a
>>>> good thing and that's not hard. XBR does full JEE injection and can
>> manage
>>>> any sort of annotation based DI because it's entirely agnostic. At
>> any rate
>>>> full support for that is now possible with XBR.
>>>
>>> XBR? I did some googling but all I could find (aside from lots
>>> of TVs)
>>> was a reference to an apparently brand new Maven 2.1 project. No
>>> website or anything. Where can I find more information?
>>>
>>> Cheers,
>>> Hilco
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
« Return to Thread: Maven core : Plexus vs Spring / OSGi ?
| Free Forum Powered by Nabble | Forum Help |