ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@interdimensions.com>
Subject Re: [PATCH] ejb/GenericDeploymentTool.java to use Jar task
Date Fri, 02 Mar 2001 06:31:14 GMT

Alrighty.

I looked over the code once more.  Sorry I missed the InnerClass thing.
Attached is the new patch.  Let me know what you think.

I would be willing! to look at refactoring, where do you think ZipUtil,
JarUtil should go?  I'm just afraid that it might touch a lot of the code,
or not be effective enough.

I believe someone mentioned something about recommending changing the
"FileSet" concept to be more in line with a file iterator.  This
recommendation might be very useful to proper task reuse..

By the way, Hi.  My name is Fernando Padilla - but most everyone calls me
fern - Internet Consultant from Boston.

g'night



<babble>
I feel that there is a second side to the coin on refactoring and reasons
for "refactoring", but it's too late for me to have a useful coherent
utterance.  So read below at your own risk..  skipping it at this moment
is totally fine.. I bet this topic will be dealt with later.


I'm going to look at some points for the other side of the coin for just a
sec:

One way to look at tasks, is as antsh might, commands to use and build
upon.  EJBJAR could then be considered a simple "Ant Script" that uses
other "Ant Commands".  The interfaces for tasks should not be varying
wildly, and if they do, it's for a reason.  Look at the thousands of sh
scripts that rely on how gcc, find, etc behave.

I'll say that the task name to task mapping is a short fall, but maybe we
can just instantiate the Task Class we want directly....

Essentially, collecting and reusing code is great.  That's why we should
be using the Jar task, and hopefully soon the Depend task ( another
submission I want to talk about ) to do our dirty work.  The question is,
what's the API into that code.  You want some lower level API?  The crux
of the matter is that the code has to do as much of our dirty work as
possible for it to be useful, yet has to do as little as possible to look
refactored...
</babble>





On Wed, 28 Feb 2001, Conor MacNeill wrote:

> Fern,
>
> Some comments.
>
> I am pretty much against further use of this construct.
>  Jar jarTask = (Jar) getTask().getProject().createTask( "jar" );
>
> I think a better approach would be to refactor the jar'ing code out of the
> Jar task into a utility class. This jaring would then be available as part
> of the core Ant services. I think then there would be a better approach
> than creating and adding a zipfileset for each file that is to go into the
> jar. You wouldn't need to be constrained by the interface made available by
> the Jar task. Of course as part of the refactor the jar task would be
> rewritten to use the new jaring service.
>
> I know this is done in a lot of places in Ant now for exec and java
> services but it is really not the right way to do it. There is an Execute
> class in Ant which provides the Execute service used by the <exec> task. An
> ExecuteJava is there for executing non-forking java classes as provided by
> the <java> task. Having that handle both forked and non-forked java use may
> be nicer. I'm a culprit here, I know, so I will be trying to eliminate all
> my current uses of the above construct.
>
> The fundamental problem with the construct is that a build file may
> redefine a task by taskdef'ing it which shouldn't, but currently could,
> break other tasks.
>
> The other problem with your patch is that it removes the check for Inner
> classes. These need to be included in the jar for it to be valid so it will
> be necessary to have this code come back. Perhaps an initial iteration
> which adds the inner classes to the set of files prior to jaring would
> work.
>
> Conor
>
>
> ----- Original Message -----
> From: "Fernando Padilla" <fern@interdimensions.com>
> To: <ant-dev@jakarta.apache.org>
> Sent: Tuesday, February 27, 2001 4:49 PM
> Subject: [PATCH] ejb/GenericDeploymentTool.java to use Jar task
>
>
> >
> > hi. i promised a patch, I took my time so not to interrupt 1.3b.
> >
> > Attached is a patch to
> > org.apache.tools.ant.taskdefs.optional.ejb.GenericDeploymentTool
> >
> > It used to have custom code to create Jar files.  I patched it to use the
> > Jar task to create it's jar files now.
> >
> > have a look.
> >
> >
> > fern
> >
> >
>
>
> ---------------------------------------------------------------------------
> -----
>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>

Mime
View raw message