Re: Maven core : Plexus vs Spring / OSGi ?
On Fri, May 9, 2008 at 12:01 AM, Jan Nielsen [EMAIL PROTECTED] wrote: FWIW, IMO introducing Spring and OSGI to replace a number of the choices in Maven is a good start; these are excellent frameworks with excellent documentation, excellent communities, and a lot of experienced developers - something that simply cannot be said of Plexus, XBR, Classworlds - and that represents tremendous value. Not recognizing, or acknowledging, that seems likely to be at the root of Maven's slow progress. Java5+, including annotations and generics, is a no-brainer, and it has been for a long time. On Fri, May 2, 2008 at 6:53 AM, nicolas de loof All good points Jan. Plexus is a pretty slick container so I can't imagine it would be that hard for it to adapt to OSGi. Following a standard is the best way to go almost always even if the non-standard solution is more superior. Alex -- ] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
FWIW, IMO introducing Spring and OSGI to replace a number of the choices in Maven is a good start; these are excellent frameworks with excellent documentation, excellent communities, and a lot of experienced developers - something that simply cannot be said of Plexus, XBR, Classworlds - and that represents tremendous value. Not recognizing, or acknowledging, that seems likely to be at the root of Maven's slow progress. Java5+, including annotations and generics, is a no-brainer, and it has been for a long time. With respect, -Jan On Fri, May 2, 2008 at 6:53 AM, nicolas de loof [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
Hmm. I sense a javax.ioc and javax.ioc.annotations package. :) Christian. On 2-May-08, at 16:56 , John Casey wrote: As far as annotations go, I completely agree with Jason, that Annotations should be standardized, and framework-agnostic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
This is already starting to happen on a couple fronts. On 3-May-08, at 8:32 AM, Christian Edward Gruber wrote: Hmm. I sense a javax.ioc and javax.ioc.annotations package. :) Christian. On 2-May-08, at 16:56 , John Casey wrote: As far as annotations go, I completely agree with Jason, that Annotations should be standardized, and framework-agnostic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
Do you have some secret JCP working draft you could publish ;-) ? 2008/5/3 Jason van Zyl [EMAIL PROTECTED]: This is already starting to happen on a couple fronts. On 3-May-08, at 8:32 AM, Christian Edward Gruber wrote: Hmm. I sense a javax.ioc and javax.ioc.annotations package. :) Christian. On 2-May-08, at 16:56 , John Casey wrote: As far as annotations go, I completely agree with Jason, that Annotations should be standardized, and framework-agnostic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
Nope, I'm doing everything with Dain and XBR which is entirely agnostic. At the core of XBR is a simple model called a recipe which describes how objects are supposed to be wired up. How you create recipes doesn't matter. So with Plexus Dain took the existing component descriptors and created the recipes which then tell XBR how to inject various components into other components, and how to configure components. The closest thing to it is Guice, but is not so hard-wired to Java5 annotations. I'm happy to allow a little more flexibility where Guice wants absolute certainty up-front and that's fine but it's certainly not the model I want for Plexus. The proof is in the pudding and XBR works great inside Plexus. On 3-May-08, at 11:49 AM, nicolas de loof wrote: Do you have some secret JCP working draft you could publish ;-) ? 2008/5/3 Jason van Zyl [EMAIL PROTECTED]: This is already starting to happen on a couple fronts. On 3-May-08, at 8:32 AM, Christian Edward Gruber wrote: Hmm. I sense a javax.ioc and javax.ioc.annotations package. :) Christian. On 2-May-08, at 16:56 , John Casey wrote: As far as annotations go, I completely agree with Jason, that Annotations should be standardized, and framework-agnostic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven core : Plexus vs Spring / OSGi ?
[ ] 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.
Re: Maven core : Plexus vs Spring / OSGi ?
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 [EMAIL PROTECTED] 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.
Re: Maven core : Plexus vs Spring / OSGi ?
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
On Fri, May 2, 2008 at 3:47 PM, Luke Patterson [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
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]
Re: Maven core : Plexus vs Spring / OSGi ?
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]
Re: Maven core : Plexus vs Spring / OSGi ?
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]
Re: Maven core : Plexus vs Spring / OSGi ?
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 [EMAIL PROTECTED] Jochen Wiedmann wrote: On Fri, May 2, 2008 at 3:47 PM, Luke Patterson [EMAIL PROTECTED] 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
Re: Maven core : Plexus vs Spring / OSGi ?
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] Jochen Wiedmann wrote: On Fri, May 2, 2008 at 3:47 PM, Luke Patterson [EMAIL PROTECTED] 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
Re: Maven core : Plexus vs Spring / OSGi ?
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
Re: Maven core : Plexus vs Spring / OSGi ?
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
Re: Maven core : Plexus vs Spring / OSGi ?
I think that would help. Today the classpath issues seem greater with reporter (AbstractReporter) plugins than plain Mojo plugins. Regards, Garvin LeClaire [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
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
Re: Maven core : Plexus vs Spring / OSGi ?
Thats true, The reason new developers/advanced users have to learn Plexus is to create/configure plugins and dependecies. Having a more documented and flexible plugin Api would make things simplier. A firend of mine has created a custom maven plugin for a trivial task. He took much of the dev time to understand the annotation based IoC, the plugin API to acces the project folders, etc.. and had no idea how this could be unit tested, as this requires yet another dedicated tool. Nicolas. 2008/5/2 John Casey [EMAIL PROTECTED]: 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
