On Mon, 2004-05-03 at 22:55, [EMAIL PROTECTED] wrote: > Jason van Zyl <[EMAIL PROTECTED]> wrote on 04/05/2004 12:17:13 PM: > > [snip good stuff] > > > No, if you actually looked at code you'll see it's not. There are tests > > for the 4 varieties and even the fourth variety only requires a 3k dep > > which does not really have anything to do with Maven2. They are > > interfaces which are the minimum needed for a POJO to interact with a > > client system. The integrated form is essentially: > > > > execute( request, response ) > > I must be seeing things then.
More likely you don't fully comprehend what's there or what it does exactly, but that's why we're having this discussion. > I had looked at the code already. > CleanPlugin extends AbstractPlugin, and doesn't wrap a POJO from what I > can tell. It does all the deleting itself. Read what was written, it is the POJO. The Plugin, AbstractPlugin, PluginExecutionRequest and PluginExecutionResponse are the 3k of dependencies mentioned in the previous email. The PluginExecutionRequest still have a reference to the core but not required except in one place. This is why the number of plugins has remained constant while these last bits are worked out. > So 4 out of 7 look ok. If Maven2 is supposed to fix the issues that > cropped up in Maven1, we really need to do it right from the outset. I'm not sure what issues you're referring to. > Maybe they could be run without plexus or maven, but they're not really > reusable without the plugin setup code in a couple of cases. We should > draw the line. They are all usable without Maven at all. You can create a Map of parameters for any of them and use them stand-alone. All the plugin configuration mechanism does is extract the values from the POM and make the Map from those values. Whether the Map is generated from within maven or from some other mechanism it doesn't matter. Also note some of the plugins do use Plexus components, like the compiler plugin, and it is still usable as a POJO. We are using that strategy for Wagon and SCM to make a POJO facade essentially over a set of components. So what the user ends up using is something like: WagonManager wagonManager = new WagonManager(); And all the plexus goop is hidden. This doesn't really matter inside maven2 as it is a plexus application but reuse namely in the form of real embeddability is something I've considered for a long time. The Mevenide folks are helping with embeddabiltity of maven2 itself by integrating it into their tools and Trygve is doing the same with maven2 in Continuum. Wagon and Maven SCM are also serving as use cases for Plexus components that can be used as POJOs and Ant tasks as well. So there is excellent coverage for the testing of embeddability. But it's an iterative process and not something you're going to "up front" but the system has to be past a threshold in order to be able to make iterative changes that are effective and using something like plexus makes this possible. > > What you are thinking of as most sensible is in fact exactly what I'm > > doing. > > In part, yes. I still think the line's been crossed in a few cases. There's nothing that can ever be done about that. No design is ever going to be adequate to begin with. But there are already 4 or 5 people who understand what's there which is already better than what we have with maven1 and those numbers will only improve in favour of the newer code. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
