Hi Michal, Quoting "michal.maczka" <[EMAIL PROTECTED]>: > > > > -----Original Message----- > > From: Aslak Hellesøy [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 25, 2003 10:46 PM > > To: Maven Users List > > Subject: RE: Container start/stop + packaging (was RE: WebLogic > Server > > plugin)
[snip] > > As I understand the purpose of at Jakarta Commons, components developed > under this initiative > should be highly reusable across many projects. > This set of API which we are discussing id rather not that > "frequently needed". > > Maybe Maven itself can open an umbrella for development of such > subprojects? > I don't think it belongs to Maven. In the same way as I wouldn't put it under the Eclipse project umbrella. It is something more generic that can be used by Maven plugins, by Eclipse plugins, etc. Putting it under a given tool's umbrella is dangerous as it may incite tying it to that tool thus making it not reusable by other projects. We've had this example with Ant and the Zip task for example. I would rather have seen the zip code as a commons project and then write a wrapper for Ant than the other way around. > I don't know what are the objectives for Maven project. > But I would like to see what we call Maven now, more thinner and > equipped > only with > set of real core plugins. Other plugins should be easily > downloadable/deployable > only on user demand. sure. This is the direction. > > I think if such separation would happen why not to create subproject > directly under Maven? I don't view this project as a Maven plugin, nor being Maven related. It is as much Centipede-related, Ant-related as it is Maven-related... That said, I do agree that there will be a Maven plugin that *wraps* around this API to make it easily usable by Maven users. > > I see possibly a lot of categories of projects: > > 0) Everything related to repository access > 1) Appserver Control API > 2) Version Control API (unified access to CVS, SVN, VSS ) etc > 3) Issue Tracking System API (pure Java API for accessing JIRA, Scarab > etc) > 4) Continuous integration build system > 5) Maven IDE > 6) etc.. I agree with all of these but only for plugins. I believe we should be *very* careful not to implement business logic in the plugin itself. In other word, the plugin should wrap existing frameworks. For example, the checkstyle plugin wraps the checkstyle framework and that is good. Same with all the others. This provides reusability. Things that could be separated from Maven (and this is the plan as defined by Jason) are for example: - SCM code - API for downloading/uploading to a remote repository What do yout think? Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
