You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Thomas Christen <ch...@active.ch> on 2000/11/26 21:17:30 UTC
[PATCH] Wait and Available
Here it is ;-)
The attached zip contains
- A new Version of Available.java : New attributes "failonerror"
and "not"
- A new Task called Wait (See documentation wait.htm)
- A new Interface called ISupportsTasks : Used to mark
any task as a task supporting nested tasks
- A new Version of ProjectHelper.java :
- Constructor TaskHandler: Type of target changed to Object
- NestedElementHanlder: Methode init changed a lot
- A new Version of Target.java : Only added implements
ISupportTasks and make use of the new methode perform() from
Task (see below)
- A new Version of Task.java : New methode called perform for
a centralized handling of task execution.
Any task can now implement nested task by implementing the Interface
ISupportsTasks. The task then has full control over the sequence of it
netsted tasks.
Hope you will like my minor changes ...
My next step is now to implement the Task called Paralell to let ant execute
Tasks in several threads.
Thomas
AW: [PATCH] Wait and Available
Posted by Thomas Christen <ch...@active.ch>.
> When designing this, if you would, give some though about different
> models for allowing a build to be stopped before completion. This
> includes the case where there is only one thread executing the build
> as well as the multi-thread case.
Threads should allways be stopped with Thread.interrupt(). I my self then
will handle the interruption as good as possible. According to the book
"Concurrent Programmin in Java" written by Doug Lea you could try :
class Terminator {
// Try to kill; return true if known to be dead
static boolean terminate(Thread t, long maxWaitToDie) {
if (!t.isAlive()) return true; // already dead
// phase 1 -- graceful cancellation
t.interrupt();
try {
t.join(maxWaitToDie);
}
catch(InetrruptException e {
}
if (!t.isAlive()) return true; // success
// phase 2 -- trap all security checks
theSecurityMgr.denyAllChecksFor(t);
try
t.join(maxWaitToDie);
}
catch(InetrruptException e {
}
if (!t.isAlive()) return true;
// phase 3 -- minimize damage
t.setPriority(Thread.MIN_PRIORITY);
return false;
}
}
Regards
Thomas
Re: [PATCH] Wait and Available
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
On Sun, Nov 26, 2000 at 09:17:30PM +0100, Thomas Christen wrote:
>
> My next step is now to implement the Task called Paralell to let ant execute
> Tasks in several threads.
>
When designing this, if you would, give some though about different
models for allowing a build to be stopped before completion. This
includes the case where there is only one thread executing the build
as well as the multi-thread case. Given the deadlock dangers of
Thread.stop(), Thread.suspend(), etc. it seems to me that we need some
sort of consistent approach accross tasks to be able to tell them to
stop what they are doing, particularly in the case where they have
forked a process that may take some time to complete. Perhapse an
approach can be developed whereby the current tasks would by default
be considered "halt unfriendly" until someone gets around to
implementing whatever required method provides the mid-build halting
semantics.
Obviously my current motive is the GUI, where the user will want to
halt a build after it has started (currently accomplished with a nice
Ctrl-C). But there are other cases where this will be needed,
including remote monitoring of builds, etc.
Thanks,
sim
--
Mustard Seed Software
mailto:simeon@fitch.net
RE: [PATCH] Wait and Available
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
Thomas,
Before you continue with the multithreading of tasks, you may want to read
the following thread.
http://marc.theaimsgroup.com/?t=96952057200006&w=2&r=1
I am pretty sure there is likely to be some adverse interactions between
running tasks in multiple threads and the management of System.out. For
example, running two non-forked <java> tasks, which both send the output to
a file, will result in both trying to set System.out, one possibly writing
into another's output file and possibly System.out not being reset properly
when the tasks finish. If ant is going to support multithreaded tasks, then
we may need to be more careful in our management of such shared resources.
Also, I'd like to give you some feedback on your patches. Please do not
tabify the files you touch. According to the patch you submitted, you
changed all of Available.java. This makes it very difficult to see what you
really changed and thus to review your patch. Also the tabbing you have
inserted is not actually correct either. In my editor, the Available.java
you submitted looks like this.
public class Available extends Task {
private String property;
private String classname;
private File file;
private String resource;
private Path classpath;
private AntClassLoader loader;
private String value = "true";
/** Task will fail if the resource is not available */
private boolean failOnError = false;
/** Reverse phrase: NOT Availabe */
private boolean notAvailable = false;
public void setClasspath(Path classpath) {
if (this.classpath == null) {
Cheers
Conor
Re: [PATCH] Wait and Available
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
On Tue, Nov 28, 2000 at 08:58:46AM +0100, Thomas Christen wrote:
>
> Since we can calm down the discussion about I or whatever - my question is
> how to proceed. Should I apply the changes my self (e.g. rename the
> Interface, do the formatting with the 4 Blank's instead of Tab's) ? Is there
> someone interest at all ? Is the concept (not the ISupportsTasks !) I
> proposed OK ? Is there a chance to get my posting in to ant ?
There is definate interest in your offerings. It is through such
contributions that Ant has become such a great tool!
I think one of the main issues with the "tabs" (if I remember
correctly), was that your editor was reformatting the whole source
file, making it difficult to determine which changes to the original
you had made, and which were due to reformatting. Although spaces
should be used in leu of tabs, I think the real recommendation was to
turn off auto-reformatting in your editor so only the lines that you
make manual changes to are the ones that show up when you do a
"cvs diff -u".
For getting your submission into Ant, here are the general guidelines
(Antidites, correct me if I get any of this wrong).
1) Read *everything* at
http://jakarta.apache.org/site/guidelines.html and the five links
listed there.
2) Before submitting your patch/addition, make sure you have the /very/
latest version of the source and that your change compiles and
works with it.
3) Make sure your code is propertly documented in JavaDoc format, the
source files have the correct copyright header, and that the code
basically follows the Sun coding conventions document.
4) Make the appropriate changes and/or additions to the documents in
jakarta-ant/docs.
5) Update or add, as appropriate, to the test code in
jakarta-ant/src/testcases so regression testing can be applied to
your offering (and ensure you haven't broken anything).
6) Create the patch file with "cvs diff -u" and post it to the group
along with a jar/zip file containing any new files that you
have. Please create the zip and the diff relative to the
jakarta-ant directory so it is easy to apply your changes,
particularly new source file locations. Post all this to the group
with the subject starting with [PATCH], and include a full
description of what the patch is, why it's useful, and why people
should test is out for you (the sales pitch).
7) Be patient. One of the committers will have to apply the patch,
build it, and test it. The committer may solicit help from others
in the group on this, particularly if the patch involves proprietary
tools that the committer has no access to. The committer may also
request modification so that the code better fits the design or
other constraint. You also have to be prepared to accept a
negative vote on your submission, for one reason or the
other. This is where the discussion gets interesting, and where
you have to keep and open mind while at the same time being an
advocate for your offering. Remember that the discussion isn't
about your intelligence or technical prowess, but about the
suitability of functionality you offer or the design
approach you used. It is meant to be a constructive and objective
discussion (ideally, anyway).
8) If you make subsequent changes to the patch before it is
committed, your continued submissions should still be differences
based on the latest version of the code (i.e. don't diff your
diffs). This is no big deal since that is what "cvs diff" gives
you anyway. Just make sure you include your new files each time.
9) If a week or so goes by and there is no dialog on your submission,
don't assume that people aren't interested in your work. Just send
a polite email asking if anyone has had the chance to look at it,
referencing your original post with a link to the mailing list
archive. Due to the voluntary nature of the project, it is easy
for submissions to drop through the cracks accidentally. It is no
means a commentary on your work.
I hope this helps, and gives you a better feel for how to make sure
your contribution is best offered.
sim
--
Mustard Seed Software
mailto:simeon@fitch.net
RE: [PATCH] Wait and Available
Posted by Conor MacNeill <co...@m64.com>.
> -----Original Message-----
> From: Jon Tirsén [mailto:jon.tirsen@emm.com]
> Sent: Wednesday, 29 November 2000 0:52
> To: ant-dev@jakarta.apache.org
> Subject: RE: [PATCH] Wait and Available
>
>
> Except for the "I" I really do like to concept.
>
> But then again I'm not either a committer or a supporter of
> the general law
> of ant: "If it's not simple it's not ant." :-)
>
Fine. What is *your* vision of ant then? :-)
> It's a bit sad that the actual discussion got drowned by a naming and
> tabbing discussion... :-(
Jon, the reason I asked Thomas about his tabs is not because I have a
particular distaste of tabs but more because of the fact that he
completely reformatted the source files making it difficult to see what
changes he had made. As a committer, I want to understand any patch I
commit to make sure it works, that it doesn't break ant, etc. To me that
is the responsibility of a committer.
I hope Thomas can resubmit the patch in a format where I can clearly
understand his changes. BTW, I would have removed the "I" anyway :-)
Conor
RE: [PATCH] Wait and Available
Posted by Jon Tirsén <jo...@emm.com>.
Except for the "I" I really do like to concept.
But then again I'm not either a committer or a supporter of the general law
of ant: "If it's not simple it's not ant." :-)
It's a bit sad that the actual discussion got drowned by a naming and
tabbing discussion... :-(
> -----Original Message-----
> From: Thomas Christen [mailto:chr@active.ch]
> Sent: Tuesday, November 28, 2000 8:59 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: [PATCH] Wait and Available
>
>
> > Regardless of where you stand on this issue, I think the discussion is
> > getting a little crazy.
>
> Absolutely right ! It was never my intention to convince anyone in this
> group ! I only didn't know it better and now since all this email flooding
> over me - hopefully I do !
>
> Since we can calm down the discussion about I or whatever - my question is
> how to proceed. Should I apply the changes my self (e.g. rename the
> Interface, do the formatting with the 4 Blank's instead of Tab's)
> ? Is there
> someone interest at all ? Is the concept (not the ISupportsTasks !) I
> proposed OK ? Is there a chance to get my posting in to ant ?
>
> Please tell me.
>
> Thanks
> Thomas
>
RE: [PATCH] Wait and Available
Posted by Thomas Christen <ch...@active.ch>.
> Regardless of where you stand on this issue, I think the discussion is
> getting a little crazy.
Absolutely right ! It was never my intention to convince anyone in this
group ! I only didn't know it better and now since all this email flooding
over me - hopefully I do !
Since we can calm down the discussion about I or whatever - my question is
how to proceed. Should I apply the changes my self (e.g. rename the
Interface, do the formatting with the 4 Blank's instead of Tab's) ? Is there
someone interest at all ? Is the concept (not the ISupportsTasks !) I
proposed OK ? Is there a chance to get my posting in to ant ?
Please tell me.
Thanks
Thomas
RE: [PATCH] Wait and Available
Posted by Jon Tirsen <jo...@emm.com>.
Check out this part of the linked docs:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
Quote:
Classes
Class names should be nouns, in mixed case with the first letter of each
internal word capitalized. Try to keep your class names simple and
descriptive. Use whole words-avoid acronyms and abbreviations (unless the
abbreviation is much more widely used than the long form, such as URL or
HTML).
Examples:
class Raster;
class ImageSprite;
Interfaces
Interface names should be capitalized like class names.
Examples:
interface RasterDelegate;
interface Storing;
> -----Original Message-----
> From: Simeon H.K. Fitch [mailto:simeon@fitch.net]
> Sent: Tuesday, November 28, 2000 3:26 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: [PATCH] Wait and Available
>
>
> On Mon, Nov 27, 2000 at 04:46:04PM -0800, Steve Loughran wrote:
> >
> > > Thomas, I do not like the "I" convention, myself. In general, I do not
> > like
> > > embedding type information into names as types can be changed
> and get out
> > of
> > > sync with the name. Indeed, interfaces often start life as abstract
> > classes.
> >
> > type is bad -it is brittle and the compiler usually handles type safety
> > anyway. functionality is a different case. Does the 'I' specify type or
> > behaviour?
>
> <flame-fodder description="Go ahead, make my day!">
> Regardless of where you stand on this issue, I think the discussion is
> getting a little crazy. If it isn't specified or disallowed in
>
> http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
>
> then, as they say, "When in Rome, do as the Romans do.". That is,
> follow the conventions of the existing code base. If the interfaces in
> the existing code base already have the 'I' prefix or the 'Intf'
> postfix, then great. Otherwise (as is our case) don't use it, unless
> you can convince the whole group to rename all the interfaces.
> </flame-fodder>
>
> sim
>
Re: [PATCH] Wait and Available
Posted by "Simeon H.K. Fitch" <si...@fitch.net>.
On Mon, Nov 27, 2000 at 04:46:04PM -0800, Steve Loughran wrote:
>
> > Thomas, I do not like the "I" convention, myself. In general, I do not
> like
> > embedding type information into names as types can be changed and get out
> of
> > sync with the name. Indeed, interfaces often start life as abstract
> classes.
>
> type is bad -it is brittle and the compiler usually handles type safety
> anyway. functionality is a different case. Does the 'I' specify type or
> behaviour?
<flame-fodder description="Go ahead, make my day!">
Regardless of where you stand on this issue, I think the discussion is
getting a little crazy. If it isn't specified or disallowed in
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
then, as they say, "When in Rome, do as the Romans do.". That is,
follow the conventions of the existing code base. If the interfaces in
the existing code base already have the 'I' prefix or the 'Intf'
postfix, then great. Otherwise (as is our case) don't use it, unless
you can convince the whole group to rename all the interfaces.
</flame-fodder>
sim
Re: [PATCH] Wait and Available
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Conor MacNeill" <co...@ebinteractive.com.au>
To: <an...@jakarta.apache.org>
Sent: Monday, November 27, 2000 14:03
Subject: RE: [PATCH] Wait and Available
> Thomas, I do not like the "I" convention, myself. In general, I do not
like
> embedding type information into names as types can be changed and get out
of
> sync with the name. Indeed, interfaces often start life as abstract
classes.
type is bad -it is brittle and the compiler usually handles type safety
anyway. functionality is a different case. Does the 'I' specify type or
behaviour?
I think it just boils down to a style issue: the I prefix is certainly
windows/COM style, but that's a world where we use C in front of classes and
m_ ahead of methods. Even the C# language has abandoned those concepts.
I tend to use ISomething, except when I use the SomethingIntf style instead.
Who knows which is better?
> A classic example of this problem from Windows is the wParam member of the
> Windows message which is not a word but a long in Win32 :-)
It becomes a 64 bit 'word param' on win64...
-Steve
RE: [PATCH] Wait and Available
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
> From: Thomas Christen [mailto:chr@active.ch]
> Sent: Tuesday, 28 November 2000 4:45
> To: ant-dev@jakarta.apache.org
> Subject: AW: [PATCH] Wait and Available
>
>
> > The use of the prefix "I" for interfaces is not idiomatic to Java
> > (according to JLS) (rather one should use the suffix Impl for
> > implementation if needed to separate them both).
> I or not I seams to be the question? Before reading the book "java 2
> performance and idiom guide" writen by Craig Larman and Rhett Guthrie, I
> thoght the same way as you do. They say : "Many developers are
> moving to the
> I-convention because it instantly communicates the fact that the code
> construct is an interface. This is important because interfaces are the
> prefered way of specifying APIs and abstractions. Because of this, we
> recommend beginning intrafce names with I.". I don't argue about
> this idiom
> but since we began using it, even in large Java-projects, the conceptual
> model becam clearer and readable.
>
Thomas, I do not like the "I" convention, myself. In general, I do not like
embedding type information into names as types can be changed and get out of
sync with the name. Indeed, interfaces often start life as abstract classes.
A classic example of this problem from Windows is the wParam member of the
Windows message which is not a word but a long in Win32 :-)
Conor
AW: [PATCH] Wait and Available
Posted by Thomas Christen <ch...@active.ch>.
> The use of the prefix "I" for interfaces is not idiomatic to Java
> (according to JLS) (rather one should use the suffix Impl for
> implementation if needed to separate them both).
I or not I seams to be the question? Before reading the book "java 2
performance and idiom guide" writen by Craig Larman and Rhett Guthrie, I
thoght the same way as you do. They say : "Many developers are moving to the
I-convention because it instantly communicates the fact that the code
construct is an interface. This is important because interfaces are the
prefered way of specifying APIs and abstractions. Because of this, we
recommend beginning intrafce names with I.". I don't argue about this idiom
but since we began using it, even in large Java-projects, the conceptual
model becam clearer and readable.
> I don't see it anywhere else in the code for Ant so I guess it's
> not project-standard for Ant either. (As with most Java-projects.)
No problem, was used to the I-convention. We can stick to the standard - if
exists at all.
Thomas
RE: [PATCH] Wait and Available
Posted by Jon Tirsén <jo...@emm.com>.
The use of the prefix "I" for interfaces is not idiomatic to Java (according
to JLS) (rather one should use the suffix Impl for implementation if needed
to separate them both). I don't see it anywhere else in the code for Ant so
I guess it's not project-standard for Ant either. (As with most
Java-projects.)
> -----Original Message-----
> From: Thomas Christen [mailto:chr@active.ch]
> Sent: Sunday, November 26, 2000 9:18 PM
> To: Ant-Dev
> Subject: [PATCH] Wait and Available
>
>
> Here it is ;-)
>
> The attached zip contains
> - A new Version of Available.java : New attributes "failonerror"
> and "not"
> - A new Task called Wait (See documentation wait.htm)
> - A new Interface called ISupportsTasks : Used to mark
> any task as a task supporting nested tasks
> - A new Version of ProjectHelper.java :
> - Constructor TaskHandler: Type of target changed to Object
> - NestedElementHanlder: Methode init changed a lot
> - A new Version of Target.java : Only added implements
> ISupportTasks and make use of the new methode perform() from
> Task (see below)
> - A new Version of Task.java : New methode called perform for
> a centralized handling of task execution.
>
> Any task can now implement nested task by implementing the Interface
> ISupportsTasks. The task then has full control over the sequence of it
> netsted tasks.
>
> Hope you will like my minor changes ...
>
> My next step is now to implement the Task called Paralell to let
> ant execute
> Tasks in several threads.
>
> Thomas
>