ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: non ant classes used in tasks??-- j2ee hot deployer
Date Fri, 26 Apr 2002 07:18:22 GMT

----- Original Message -----
From: "David Jencks" <davidjencks@directvinternet.com>
To: "Ant-dev" <ant-dev@jakarta.apache.org>
Sent: Thursday, April 25, 2002 20:36
Subject: non ant classes used in tasks??-- j2ee hot deployer


> I started working on a JBossHotDeploymentTool to fit with the other j2ee
> hot deployment tools.  However I would like some policy clarification
about
> use of classes not now shipped with ant before I spend much time on it.

ok. you are implementing under serverdeploy, right?

>
> Implementing this requires several classes from javax.management
> (ObjectName and a bunch of exceptions) and one JBoss specific class.  I
> could presumably distort my code so as to use reflection on the JBoss
> class, however I'm not very interested in trying to do without the jmx
> classes.

we can link to JMX no problems; you need to make your class compilation
conditional on those files being there.

JBoss will be trouble if it is GPL; we cant link to it directly or via
reflection as that forces us into GPL-ing everything. If it aint; no
problem.


> Assuming my coding style was unobjectionable, and I finished this, would
it
> get accepted with the requirements for including these classes?  Due to
the
> design of the DeployTool task it does not appear possible to ship this
> sub-task with JBoss yet have it available as a subtask.

well, we can code knowledge of subtasks into the ant core, and link to some
ant task in jboss itself.

> On the other hand
> I am a little confused about the utility of having a task whose subtasks
> all deploy to different app servers.  I would think that the infrequency
of
> one target needing to deploy to several different app server brands would
> make an arrangement where each app server gets its own task would perhaps
> make more sense.

interesting point. I Think the view is that <serverdeploy> can state the
commonality; subclasses for the specifics. I'd probably have one target per
target system, with one server type in each.



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message