The argument I'd use is this: the set of control features supported by all j2ee servers do not match. The design of the j2ee plugin (which I will admit I hadn't looked at. Looks pretty useful!) is to support a /generic/ set of features. The best way to support that while providing access to the full featureset of servers for those who use only one, is to provide a per-server plugin, then have the generic plugin call the desired feature of the server plugin.
The issue is one of whether you want the generic plugin to support the intersection or the union of features of all j2ee servers. I'd say 'intersection' is the only choice that makes sense. If the j2ee plugin only supports an intersection of features, and I was to migrate this code into tomcat-4.x.jelly, (the tomcat support script in j2ee), then any features not in the intersection would be unavailable. That means having a separate tomcat, iPlanet, JBoss, etc, plugin, with calls to them from the j2ee plugin, gives the best of all worlds.
However - I can see the point of adding some support to j2ee to call the tomcat plugin, and ditching the 'war' plugin. But it's still not 'deploy'. It 'deploy-war' or some such. By analogy, look at the j2ee plugin's 'j2ee:validate-war'. Its not 'j2ee:validate' for a reason.
Anyway, this is just my opinion. I'm donating the code, its the ASF's to do what they want with now.
-Baz
Alexei Barantsev wrote:
Look at implementation of j2ee - it is pluggable. And I suggest to add deploy, not war:deploy.-----Original Message-----
From: Brian Ewins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 7:11 PM
To: Turbine Maven Users List
Subject: Re: New tomcat plugin
The deploy stuff is non-standard. We'd just annoy people who use <pick-any-other-server>. It would make more sense to do something like:
<goal name="war:deploy">
// if server is tomcat then...
<attainGoal name="tomcat:deploy"/>
// if server is iPlanet then...
<attainGoal name="iPlanet:deploy"/>
// etc...
</goal>
also, j2ee != war. There are a plethora of different *AR files you can deploy on j2ee servers; this tomcat goal is purely about deploying webapps on tomcat.
I remember there was supposed to be some JSRs standardising J2EE deployment and management (using JMX); dunno if they're finalized yet, but until they are, and are supported, there's going to be a need for per-platform goals.
-Baz
Alexei Barantsev wrote:
I'd suggest to add deploy goal to j2ee plugin instead ofcreating new
one (in addition to j2ee and war - may be these two would be merged too?).
-----Original Message-----
From: Brian Ewins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 04, 2002 6:37 PM
To: Turbine Maven Users List
Subject: Re: New tomcat plugin
Since no-one's replied... here it is. The zip is thesource, to go inhttp://freedonia:8080/managerjakarta-turbine-maven/src/plugins-build, the jar should work if dropped into your plugins directory. Since there is no catalina-ant.jar in ibiblio, you will need to get one for yourself- download a release from: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/bin/
and copy 'CATALINA_HOME/server/lib/catalina-ant.jar' to
'MAVEN_HOME/repository/tomcat/jars/catalina-ant-4.1.12.jar'.
To use it in a project, add something like this to your
project.properties: maven.tomcat.url =
maven.tomcat.username = flywheel maven.tomcat.password = swordfish (read the tomcat manager how-to!!)server docs for
and type:
maven tomcat:deploy
Your webapp will be built and deployed onto the server. There are xdocs
for everything if you want more details.
The plugin depends on a jar from TC 4.1.12, but some of the manager app
functions will work fine on earlier tomcats - see your
details.
CAVEAT: this is not an official plugin, so don't rely on this for
production scripts unless you're happy that this copy isall you need.-Baz
BTW: Is there a reason why there's no 'plugin' plugin?Seems like mostwrapper for theof the plugin maven.xml's are the same? Brian Ewins wrote:I've written a tomcat plugin I'd like to donate, once I'm through testing. It needs catalina-ant.jar (not on ibiblio as far as I can
see).Its pretty small and straightforward, since its just a
<mailto:[EMAIL PROTECTED]>tomcat ant tasks. Should I just attach it on jira, or...?
-Baz
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
For additional commands, e-mail:
--<mailto:[EMAIL PROTECTED]>
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
