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 <[EMAIL PROTECTED]>:
http://geronimo.apache.org/xbean
On Fri, May 2, 2008 at 1:04 PM, Hilco Wijbenga
<[EMAIL PROTECTED]>
wrote:
On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jesse mcconnell
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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
