Maven core : Plexus vs Spring / OSGi ?

[nicolas de loof-3]

 [
----------------------------------------------------------------------------------------------------------------------------
]
 Note to plexus lovers :
 CONTROVERSAL PROPOSAL, please don't blame me and just give good arguments !
[
----------------------------------------------------------------------------------------------------------------------------
]

Maven is built on Plexus. This lightweight container is used (afaik) for :
 - simple (javadoc) annotation-based programming model
 - lifecycle management
 - dependency injection
 - classloader isolation for plugins (using classworld)

Let's now consider the today responses to the same requirements :
- Since Java5, annotations are common, and JSR-250 introduces standard
annotations that can address some basic lifecycle and IoC requirements.
- The IoC container ecosystem is dominated by Springframework. Maybe not the
best technical one for any reason, but the best documented and most know by
developers.
- Classloader isolation is very well adressed by OSGi, with the advantage of
beeing a recognized standard, with many documentation AND business interest.

Maybe Plexus was a very advanced container when it was created, but it did
not become the today 1rst choice technology.

Considering an opensource tool like maven is built by volunteers developers,
it would be a good thing to attract talentuous ones to use up-to-date and
well known technologies. As an example, Archiva (trunk) is migrating to
Spring as it's IoC container.

Could we consider for future maven version (let's say 2.2, or "3.0" - as 2.1
is allready in advanced development phase) to replace plexus with a
combination of Java5 + Spring + OSGi ?

Nicolas.

[lukewpatterson]

I agree that people would be more willing (and able) to contribute if the
core technologies were "Java5 + Spring + OSGi".


In the limited amount of time available to learn new things, is it
worthwhile for one to learn Plexus?


On 5/2/08, nicolas de loof <nicolas@...> wrote:

>
> [
>
> ----------------------------------------------------------------------------------------------------------------------------
> ]
> Note to plexus lovers :
> CONTROVERSAL PROPOSAL, please don't blame me and just give good arguments
> !
> [
>
> ----------------------------------------------------------------------------------------------------------------------------
> ]
>
> Maven is built on Plexus. This lightweight container is used (afaik) for :
> - simple (javadoc) annotation-based programming model
> - lifecycle management
> - dependency injection
> - classloader isolation for plugins (using classworld)
>
> Let's now consider the today responses to the same requirements :
> - Since Java5, annotations are common, and JSR-250 introduces standard
> annotations that can address some basic lifecycle and IoC requirements.
> - The IoC container ecosystem is dominated by Springframework. Maybe not
> the
> best technical one for any reason, but the best documented and most know
> by
> developers.
> - Classloader isolation is very well adressed by OSGi, with the advantage
> of
> beeing a recognized standard, with many documentation AND business
> interest.
>
> Maybe Plexus was a very advanced container when it was created, but it did
> not become the today 1rst choice technology.
>
> Considering an opensource tool like maven is built by volunteers
> developers,
> it would be a good thing to attract talentuous ones to use up-to-date and
> well known technologies. As an example, Archiva (trunk) is migrating to
> Spring as it's IoC container.
>
> Could we consider for future maven version (let's say 2.2, or "3.0" - as
> 2.1
> is allready in advanced development phase) to replace plexus with a
> combination of Java5 + Spring + OSGi ?
>
> Nicolas.
>

[Carlos Sanchez-4]

I'd really love to see that, but that's not news at all ;)

On Fri, May 2, 2008 at 5:53 AM, nicolas de loof <nicolas@...> wrote:

>  [
>  ----------------------------------------------------------------------------------------------------------------------------
>  ]
>   Note to plexus lovers :
>   CONTROVERSAL PROPOSAL, please don't blame me and just give good arguments !
>  [
>  ----------------------------------------------------------------------------------------------------------------------------
>  ]
>
>  Maven is built on Plexus. This lightweight container is used (afaik) for :
>   - simple (javadoc) annotation-based programming model
>   - lifecycle management
>   - dependency injection
>   - classloader isolation for plugins (using classworld)
>
>  Let's now consider the today responses to the same requirements :
>  - Since Java5, annotations are common, and JSR-250 introduces standard
>  annotations that can address some basic lifecycle and IoC requirements.
>  - The IoC container ecosystem is dominated by Springframework. Maybe not the
>  best technical one for any reason, but the best documented and most know by
>  developers.
>  - Classloader isolation is very well adressed by OSGi, with the advantage of
>  beeing a recognized standard, with many documentation AND business interest.
>
>  Maybe Plexus was a very advanced container when it was created, but it did
>  not become the today 1rst choice technology.
>
>  Considering an opensource tool like maven is built by volunteers developers,
>  it would be a good thing to attract talentuous ones to use up-to-date and
>  well known technologies. As an example, Archiva (trunk) is migrating to
>  Spring as it's IoC container.
>
>  Could we consider for future maven version (let's say 2.2, or "3.0" - as 2.1
>  is allready in advanced development phase) to replace plexus with a
>  combination of Java5 + Spring + OSGi ?
>
>  Nicolas.
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 2-May-08, at 5:53 AM, nicolas de loof wrote:

> [
> ----------------------------------------------------------------------------------------------------------------------------
> ]
> Note to plexus lovers :
> CONTROVERSAL PROPOSAL, please don't blame me and just give good  
> arguments !
> [
> ----------------------------------------------------------------------------------------------------------------------------
> ]
>
> Maven is built on Plexus. This lightweight container is used (afaik)  
> for :
> - simple (javadoc) annotation-based programming model

There are java5 annotations which Jason Dillon wrote, and they are  
available for Mojos as well in the model that Yoav has placed JIRA.

>
> - lifecycle management
> - dependency injection
> - classloader isolation for plugins (using classworld)
>
> Let's now consider the today responses to the same requirements :
> - Since Java5, annotations are common, and JSR-250 introduces standard
> annotations that can address some basic lifecycle and IoC  
> requirements.
> - The IoC container ecosystem is dominated by Springframework. Maybe  
> not the
> best technical one for any reason, but the best documented and most  
> know by
> developers.

I think it's really more then the JSR about a component model which is  
now a little race between Spring, Guice, and OSGi. What's more  
important, as Paul Hammant will also argue, is the interoperability of  
the components. Important things like making the embedder usable in a  
OSGi environment. These are the things that really matter.

>
> - Classloader isolation is very well adressed by OSGi, with the  
> advantage of
> beeing a recognized standard, with many documentation AND business  
> interest.
>

I'm definitely interested in the OSGi model for classloaders and I've  
had more then one conversation with Jeff McAffer.

> Maybe Plexus was a very advanced container when it was created, but  
> it did
> not become the today 1rst choice technology.
>

OpenEJB is using XBR, Geronimo is using XBR, and I'm happy using XBR  
which is a project here at Apache where the degree of collaboration  
can be much higher. What XBR is capable of is simply amazing, that it  
was possible to swap in another DI engine without a _single_ change to  
Maven is amazing. I am also more interested in collaborating with the  
Pico community and bring together their world with ours.

> Considering an opensource tool like maven is built by volunteers  
> developers,
> it would be a good thing to attract talentuous ones to use up-to-
> date and
> well known technologies. As an example, Archiva (trunk) is migrating  
> to
> Spring as it's IoC container.
>

XBR is certainly up-to-date and probably one of the most advanced DI  
libraries there is, Dain is at hand to help and he just finished doing  
a lot of work to bring the DI capabilities up to the most advanced  
there are.

I would counter Archiva with Nexus which is using Plexus and I believe  
this makes it more flexible and will integrate with Maven far better.  
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.

> Could we consider for future maven version (let's say 2.2, or "3.0"  
> - as 2.1
> is allready in advanced development phase) to replace plexus with a
> combination of Java5 + Spring + OSGi ?
>

Java5 absolutely, that exists now and with the integration of XBR  
there are no limitations. As far as Spring, that's honestly never  
going to happen while I'm here because I will always argue that  
something like XBR/Guice which is a DI library is more appropriate and  
there is nothing Spring can do that XBR cannot do today in terms of  
dependency injection. OSGi classloaders are definitely an option and  
Eugene and Igor of m2eclipse already have some very cool tools that  
are akin to Spring DM.

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.

> Nicolas. What

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

-- Christopher Alexander, A Pattern Language




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jochen Wiedmann]

On Fri, May 2, 2008 at 3:47 PM, Luke Patterson <lukewpatterson@...> wrote:

> I agree that people would be more willing (and able) to contribute if the
>  core technologies were "Java5 + Spring + OSGi".
>
>
>  In the limited amount of time available to learn new things, is it
>  worthwhile for one to learn Plexus?

I must admit that I find this puzzling.

What people drives to participate in an open source project like
Maven, will, IMO, hardly be the inner architecture, but the value it
gives you for your daily work. Not that I find the Maven core
particularly clear, but that is hardly the result of using Plexus and
more owned to the cores complexity.

Apart from that, the most work is not so much in the core but in the
components. I surely hope that noone intends to rewrite or, even
worse, enforce a rewrite of shared components, plugins, and so on.

To sum it up: I don't see the value in that project. If there are
people who want to do it, fine with me, but I don't see what we could
win.


Jochen


--
Look, that's why there's rules, understand? So that you think before
you break 'em.

 -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hilco Wijbenga-2]

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@...

[jmcconnell]

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@...

[nicolas de loof-3]

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@...
>
>

[Garvin LeClaire-2]

I would agree .  Why spend time converting the core just to be on a
"more popular" framework.  What would we do if Guice became more
popular, change again?

I think the bigger issue here is documentation on Maven's design and
design implementation.   I find I have to search in a lot of places and
dig deep into the code to find out information when writing plugins.  
This would be the same issue today if we had Spring.  Now I do have to
admit I am just as guilty of this when I write my plugin which is much
smaller the core Maven.  I think we all need to take the time to produce
and consolidate this information for users and for developers in order
to foster the Maven development community.

I do think that  OSGi would provide a way to alleviate our dependency
issues (classpath hell).   I know I am going through that now and it is
not easy to deal with.

Regards,



Garvin LeClaire
garvin.leclaire@...




Jochen Wiedmann wrote:

> On Fri, May 2, 2008 at 3:47 PM, Luke Patterson <lukewpatterson@...> wrote:
>
>  
>> I agree that people would be more willing (and able) to contribute if the
>>  core technologies were "Java5 + Spring + OSGi".
>>
>>
>>  In the limited amount of time available to learn new things, is it
>>  worthwhile for one to learn Plexus?
>>    
>
> I must admit that I find this puzzling.
>
> What people drives to participate in an open source project like
> Maven, will, IMO, hardly be the inner architecture, but the value it
> gives you for your daily work. Not that I find the Maven core
> particularly clear, but that is hardly the result of using Plexus and
> more owned to the cores complexity.
>
> Apart from that, the most work is not so much in the core but in the
> components. I surely hope that noone intends to rewrite or, even
> worse, enforce a rewrite of shared components, plugins, and so on.
>
> To sum it up: I don't see the value in that project. If there are
> people who want to do it, fine with me, but I don't see what we could
> win.
>
>
>  

Jochen
>
>  

[nicolas de loof-3]

My initial idea was not about Plexus vs Spring but to use OSGi as it
supports the plugin + isolation that is required for maven, and suggested
Spring because it allready supports OSGi.

If we can use plexus with OSGi, lets do it. I just would prefer plexus to be
less intrusive and to support annotations, as a replacement for javadocs and
a dedicated maven plugin to extract components requirements.

2008/5/2 Garvin LeClaire <garvin.leclaire@...>:

>
>
> I would agree .  Why spend time converting the core just to be on a "more
> popular" framework.  What would we do if Guice became more popular, change
> again?
> I think the bigger issue here is documentation on Maven's design and
> design implementation.   I find I have to search in a lot of places and dig
> deep into the code to find out information when writing plugins.  This would
> be the same issue today if we had Spring.  Now I do have to admit I am just
> as guilty of this when I write my plugin which is much smaller the core
> Maven.  I think we all need to take the time to produce and consolidate this
> information for users and for developers in order to foster the Maven
> development community.
>
> I do think that  OSGi would provide a way to alleviate our dependency
> issues (classpath hell).   I know I am going through that now and it is not
> easy to deal with.
>
> Regards,
>
>
>
> Garvin LeClaire
> garvin.leclaire@...
>
>
>
>
>
> Jochen Wiedmann wrote:
>
> > On Fri, May 2, 2008 at 3:47 PM, Luke Patterson <lukewpatterson@...>
> > wrote:
> >
> >
> >
> > > I agree that people would be more willing (and able) to contribute if
> > > the
> > >  core technologies were "Java5 + Spring + OSGi".
> > >
> > >
> > >  In the limited amount of time available to learn new things, is it
> > >  worthwhile for one to learn Plexus?
> > >
> > >
> >
> > I must admit that I find this puzzling.
> >
> > What people drives to participate in an open source project like
> > Maven, will, IMO, hardly be the inner architecture, but the value it
> > gives you for your daily work. Not that I find the Maven core
> > particularly clear, but that is hardly the result of using Plexus and
> > more owned to the cores complexity.
> >
> > Apart from that, the most work is not so much in the core but in the
> > components. I surely hope that noone intends to rewrite or, even
> > worse, enforce a rewrite of shared components, plugins, and so on.
> >
> > To sum it up: I don't see the value in that project. If there are
> > people who want to do it, fine with me, but I don't see what we could
> > win.
> >
> >
> >
> >
> Jochen
>
> >
> >
> >
>

[John Casey-5]

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

[John Casey-5]

I think this issue would go away if we could write a plugin-
facilities api that gave easy access to the things plugins need to do  
in most cases. In other words, publish a formal, public api for Maven  
for the plugin developer. While it'd be nice to have full design docs  
for all of Maven, in 90% of cases this wouldn't help the plugin  
developer...it would only serve to create a new haystack to poke  
through (this one in HTML rather than Java). If we can be a little  
more selective this, and provide a plugin-oriented api for common  
tasks like resolving artifacts, building projects, etc. then document  
that, we'd probably alleviate the problems for 90% of users.

-john

On May 2, 2008, at 4:50 PM, Garvin LeClaire wrote:

>  I find I have to search in a lot of places and dig deep into the  
> code to find out information when writing plugins.

---
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

[Garvin LeClaire-2]

I think that would help.

Today the classpath issues seem greater with reporter (AbstractReporter)
plugins than plain Mojo plugins.


Regards,



Garvin LeClaire
garvin.leclaire@...




John Casey wrote:

> I think this issue would go away if we could write a plugin-facilities
> api that gave easy access to the things plugins need to do in most
> cases. In other words, publish a formal, public api for Maven for the
> plugin developer. While it'd be nice to have full design docs for all
> of Maven, in 90% of cases this wouldn't help the plugin developer...it
> would only serve to create a new haystack to poke through (this one in
> HTML rather than Java). If we can be a little more selective this, and
> provide a plugin-oriented api for common tasks like resolving
> artifacts, building projects, etc. then document that, we'd probably
> alleviate the problems for 90% of users.
>
> -john
>
> On May 2, 2008, at 4:50 PM, Garvin LeClaire wrote:
>
>>  I find I have to search in a lot of places and dig deep into the
>> code to find out information when writing plugins.
>
> ---
> 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
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

My 2 cents. I happen to like Spring. I know Avalon really well which
Plexus has its roots in. That being said, I really don't care which one
is used as long as DI is really used, and that is where the problem is.
Things that should have been wired via configuration aren't (i.e.
DefaultArtifactVersion).

If you have limited time spend it on things that really matter.

OSGi, on the other hand, might have some nice benefits that everyone
would appreciate.

Ralph

John Casey wrote:

> 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: d