maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Ewins <Brian.Ew...@btinternet.com>
Subject Re: New tomcat plugin
Date Wed, 04 Dec 2002 17:03:20 GMT
Fair enough. I still don't agree that this should necessarily go in there.

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:Brian.Ewins@btinternet.com] 
>>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 of 
>>
>>creating new 
>>
>>>one (in addition to j2ee and war - may be these two would be merged 
>>>too?).
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Brian Ewins [mailto:Brian.Ewins@btinternet.com]
>>>>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 the 
>>
>>source, to go in
>>
>>>>jakarta-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 = 
>>
>>http://freedonia:8080/manager 
>>
>>>maven.tomcat.username = flywheel maven.tomcat.password = swordfish 
>>>(read the tomcat manager how-to!!)
>>>
>>>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 
>>
>>server docs for 
>>
>>>details.
>>>
>>>CAVEAT: this is not an official plugin, so don't rely on this for
>>>production scripts unless you're happy that this copy is 
>>
>>all you need.
>>
>>>-Baz
>>>
>>>BTW: Is there a reason why there's no 'plugin' plugin? 
>>
>>Seems like most
>>
>>>of 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 
>>
>>wrapper for the 
>>
>>>>tomcat ant tasks. Should I just attach it on jira, or...?
>>>>
>>>>-Baz
>>>>
>>>>
>>>>-- 
>>>>To unsubscribe, e-mail:   
>>>><mailto:turbine-maven-user-unsubscribe@jakarta.apache.org>
>>>>For additional commands, e-mail: 
>>>><mailto:turbine-maven-user-help@jakarta.apache.org>
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:   
>>
>><mailto:turbine-maven-user-unsubscribe@jakarta.apache.org>
>>
>>For additional commands, e-mail: 
>>
>>><mailto:turbine-maven-user-help@jakarta.apache.org>
>>>
>>>
>>
>>--
>>To unsubscribe, e-mail:   
>><mailto:turbine-maven-user-unsubscribe@jakarta.apache.org>
>>
>>For additional commands, e-mail: 
>><mailto:turbine-maven-user-help@jakarta.apache.org>
>>
>>
>>
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-maven-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-maven-user-help@jakarta.apache.org>
> 
> 


Mime
View raw message