You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Jack J. Woehr" <ja...@purematrix.com> on 2003/09/10 01:16:58 UTC
antidote diff
Hi --
I posted this on user@ ... maybe not the right place.
Trivial antidote diff that clears up 7 of 15 javadoc warnings during build.
Let me know if this is the appropriate forum for such things.
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Conor MacNeill wrote:
> IMHO, I don't think development should be tied to a single IDE.
Well, this is true, but a .java file GUI-edited under NetBeans is hand-editable.
You just don't hand-code inside the areas delineated by guard comments. I hand-edit
Netbeans projects all the time.
It's just so much faster to lay out stuff in NetBeans, and after doing all the work, why
not check in the .form files? They're totally optional to Antidote itself, but they save
work if you *happen to want to use* NetBeans for further GUI development of Antidote.
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
On Thu, 11 Sep 2003 02:12 am, Jack Woehr wrote:
> If I were "attack" the GUI in that fashion (tossing it back into NetBeans)
> would that be acceptable or would that cross some guideline?
IMHO, I don't think development should be tied to a single IDE. You can, of
course, use the features of your favourite IDE, but none of the checked in
artifacts should relate solely to that IDE. Likewise somebody wishing to
participate in Antidote development should not have to use that IDE to do
that development.
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Stefan Bodewig wrote:
> How would that work I anybody wanted to modify the GUI, say add a
> button or something. Not using NetBeans, that is.
Well, that could be a pain. Not that you couldn't do it, and not that it would be even difficult
- but -
the NetBeans fanatic would have to clean up after the manual add. For the expert NB'er
a minute or two of work
Um, how many people are actively coding on the Antidote GUI anyway?
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 11 Sep 2003, Jack J. Woehr <ja...@purematrix.com> wrote:
> Forgive me, Stefan, I believe we have a misunderstanding.
Yes, we had.
> Use NetBeans to maintain the GUI classes.
As long as it doesn't prevent the GUI to be altered using a different
IDE, I'm totally on the fence here. Never use NetBeans, never used
any GUI builder, won't touch the GUI code anyway 8-)
How would that work I anybody wanted to modify the GUI, say add a
button or something. Not using NetBeans, that is.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Stefan Bodewig wrote:
> On Wed, 10 Sep 2003, Jack Woehr <ja...@purematrix.com> wrote:
>
> > though since the last changes seem to have been February there is
> > probably a lot of scope for the interested coder!?
>
> Antidote has had two or three phases of increased development efforts
> with longer breaks of inactivity in between. The last one has been
> winter/early spring this year IIRC. The Ant committer who's currently
> most interested in Antidote has switched jobs by then and may have
> some trouble to keep up with it ATM.
>
> Most Ant committers don't work on Antidote at all. Some of them (me
> included) simply don't enjoy GUI programming at all. In addition it
> is hard to work on something you don't use. I'm absolutely happy with
> using Ant from the command line (errm, XEmacs compile command, that
> is) and others use the integration present in their IDE of choice.
>
> My recollection is different. The NetBeans/Ant integration has been
> developed very early - a couple of months before Antidote started -
> sometime early spring 2000 as opposed to autumn 2000 IIRC.
Forgive me, Stefan, I believe we have a misunderstanding.
What I was saying is that internal code evidence shows that the Netbeans IDE was
used by the coder at some point in development of Antidote gui code. There's some stub
functions in Antidote code that Netbeans inserts in gui widgets. I just inferred that
the author had used NB, then removed the project from NB and turned to 100%
hand coding.
> But as far as I understand it, Antidote has been independent from the
> NetBeans integration. The two projects may have borrowed ideas from
> each other, but they've been independent efforts.
Absolutely. Antidote has interesting standalone potential. That's why I am rooting through
the code like a piggy looking for truffles :-)
> > If I were "attack" the GUI in that fashion (tossing it back into
> > NetBeans) would that be acceptable or would that cross some
> > guideline?
>
> I'm not sure I understand what you mean by "tossing it back".
Use NetBeans to maintain the GUI classes. NetBeans uses .form files (gui-design XML) which
would themselves also be checked in. The .form files are not necessary for compilation but allow
the user-developer to resume GUI development under NetBeans.
I find the following about Antidote source:
* bus idea good
* gui code tight but perfunctory
o MVC model a little inchoate
* functionality minimal so far
Like I said, has great potential. Needs work, but you knew that already :-)
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antidote TODO (WAS:RE: antidote diff)
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> > Maybe the first step is to update the TODO list :-)
Okay, a revised list is attached at the end of this message. Here's
the discussion:
> > * Cleanup build.xml file; make antidote specific.
> >
> > This has been done already, right?
>
> I think so!
Removed.
>
>
> > * Rewrite ACSFactory to use it's own parser rather than
> > the implementation
> > specific com.sun.xml.tree.SimpleElementFactory class
> > (only available
> > in JAXP from Sun).
> >
> > Done? Still TODO?
>
> Has to be rececked, but generally it works fin IMHO
Removed.
> > * Add editors for defining file sets, and other "sets".
> >
> > This has been done already, right?
>
> Particualry! IMHO there could be mor comfort in defining filesets, what
> do you think!?!
I think you mean "partially"? Okay, modified TODO item.
> > * Write wizzard framework.
> >
> > The framework is there, but there are currently no
> > wizards, right?
>
> There is a "not working" example wizard for an entire build-file. IMO
> the wizarg could be used to create targets in addition...
Modified TODO item.
> > * Implement a build progress reporter.
> >
> > What would that look like, compared to the console that
> > currently exists?
>
> I thinks the console is ok, but Sim meant to write a log to a file in
> addition. Obviously the log line formtting has to be definable
> interactively and stored in preferences...
Modified TODO item.
> > * Implement a "Worker Thread" pattern that allows workers to have
> > their work done in a thread property registered with
> > Antidote, and
> > provide support to that worker to provide progress updates via
> > the GUI. Should also provide support for hour-glass cursor
> > handling, and AWT event blocking until task is completed. This
> > would be used for things such as loading files or other tasks
> > that the user must wait for completion.
> >
> > Has this been done or is it still TODO? I think it is still TODO.
>
> It IS a to do! There is no way to stop Ant once it runs from Antidote!
Modified TODO item.
>
> > * Add menu option to select the compiler to use, which then sets
> > the "build.compiler" property. Better yet, create a generic menu
> > building capability that allows the setting of a property from a
> > list of options.
> >
> > Still TODO, right?
>
> It is a todo! I'd propose not just setting the complier, put the option
> to set all Ant -D parameters from the gui and make them storable!
Modified TODO item.
> > * Add ability to put an "all" or "don't care" specifyer
> > on the action
> > "enableOn" and "disableOn" properties.
> >
> > Still TODO, right?
>
> It is not implemented IIRC! Additionally I am not really shure what it
> should do...
Left this the same, since I don't really understand it :-)
> > * Add ability to view task dependencies more fully.
> >
> > Describe this facility?
>
> It should say "target-dependency". It would be nice to be able to show a
> grafic with all the tragets and arrows between them to show the
> dependency (depends). Would be really a feature for many guys using Ant,
> I know...
Modified TODO item.
> > * Add better editors for specific tasks.
> >
> > Examples?
>
> Not only for tasks, but properties in addition. We meant editors just
> like the dependency choose!
Modified TODO item.
> > * Add a Progress Monitor for file loading (especially for
> > slow boxen like
> > mine) .
> >
> > Still TODO, right?
>
> Yes, it is! Progress for loading files and for the time the
> introspection rus would be nice!
Left the same.
> > * Implement some for of refid hyperlinking functionality.
> >
> > Describe this facility?
>
> Not shure what Sim means... Yould someone else drop in here...!?!
Left the same.
> > * Implement context sensitive menus for the console
> > window, allowing
> > an error to be selected and invoked in IDE.
> >
> > "Jump-to" in Antidote itself?
>
> I think integration into IDEs is no BIG project aim anymore or at leas
> ATM...
Modified TODO item.
> > * Write preferences framwork, including persistence support.
> >
> > Trivial, still TODO? I can borrow this from my own open
> > source code.
>
> Would be nice, if the code is under an Apache compatible OSS License
> (like Apache or FreeBSD) LGPL is NOT ok!!
> I'd prefer a small, fast an clean implementation as always ;-).
It seems the nucleus of this is already there. e.g., in core/ProjectManager.java?
Or should this be re-written? Like I said, I've got one of these things already
written in my "SoftWoehr Class Libraries" that I could modify and "Apachify".
> > * Provide some sort of class path debugging support.
> >
> > Describe this facility?
>
> Not 100% shure, but displaying the Ant-build-classpath and introspect
> the jars one by one... Search for Classes and multiple occurrences in
> the classpath... And so on!
Modified TODO item.
> > * Add "syntax" colorization to the console window {done},
> > with a preferences editor for setting up the styles {not-done}.
> >
> > Describe this facility?
>
> Just make the syntax highlighting in the console window configurable via
> the Preferences window! Easy!
Modified TODO item.
> > * Figure out an approach to gracefully stopping a running build.
> >
> > Hmmm ... screech! crash! :-)
>
> As I said before... Uneasy to implement without hooks in Ant
> itself...;-)
Modified TODO item.
> > * Add error handler for SAX parser to better report
> > loading errors.
> >
> > Still TODO?
>
> Yupp! Not done!
Left the same.
> > * Project properties viewer, including the ability to view
> > dependencies (local and cascading).
> >
> > Describe this facility?
>
> As said before: View and modify the Projekt Properties you can override
> using -D with the Ant-Commandline! Cascading means from imported
> build.xmls
Modified TODO item.
> > * Acquire or implement a logging facility.
> >
> > What, are we thinking JLog here?
>
> I'd prefer Log4J. Logkit would be another option... Or the jakarta
> commons logging facility...
Modified TODO item.
>
> > * Eat more dog food.
> >
> > I'm using it! It's not easy to use yet, the editors are
> > not much fun to use compared to merely typing things in
> > NetBeans source editor!
>
> Yes: The editors have to be improved definately!
>
> > Also, I'd add this usability feature:
> >
> > * When you are editing some task or property or target and
> > you decide to delete that thing, the editor should disappear.
>
> Could you explain..
When you delete a target, the editor in which you were editing the
target "hangs around" in the editor window. The editor itself should
go away so that you don't think you are editing a target anymore,
because you are not doing so!
> P.S.: Sorry for answering that late but ATM I am just online every
> second day!
Likewise! See attached modified TODO.
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
Re: Antidote TODO (WAS:RE: antidote diff)
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> > Um, 29Mb of source is not "small" on a 56K modem!
>
> I did not mean the code, for it is c++ anyways! The Application itself
> should to to look at the prefs-dialog :-)
I'm an open sourcer. In general, if I can't build it, I don't run it.
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Antidote TODO (WAS:RE: antidote diff)
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> Um, 29Mb of source is not "small" on a 56K modem!
I did not mean the code, for it is c++ anyways! The Application itself
should to to look at the prefs-dialog :-)
> > This would be overkill IMO. We should be fine with a (maximum) two
> > level hirachy! And remember: Let's keep the "baby" small
> and fast :-)
>
> Good idea
Have fun :-)!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antidote TODO (WAS:RE: antidote diff)
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> > Not familiar with that, but will try to take a look. There is
> > a *possibility* (not a certainty) that I will lose my
> > high-speed connection in the near future, which would make
> > playing with Mozilla a little hard. We'll see what happens.
>
> Mozilla Firebird is mall and fast... Should be no problem for you :-)
Um, 29Mb of source is not "small" on a 56K modem!
> > But ... Preferences and storing them via Properties I
> > understand well. How we handle the GUI side of that "remains
> > to be seen". There is also the NetBeans model of a giant Options tree.
>
> This would be overkill IMO. We should be fine with a (maximum) two level
> hirachy! And remember: Let's keep the "baby" small and fast :-)
Good idea
> Oh: If you need Icons: don't hesitate to tell me! I'll paind them with
> pleasure!
Will do!
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
RE: Antidote TODO (WAS:RE: antidote diff)
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> Not familiar with that, but will try to take a look. There is
> a *possibility* (not a certainty) that I will lose my
> high-speed connection in the near future, which would make
> playing with Mozilla a little hard. We'll see what happens.
Mozilla Firebird is mall and fast... Should be no problem for you :-)
> But ... Preferences and storing them via Properties I
> understand well. How we handle the GUI side of that "remains
> to be seen". There is also the NetBeans model of a giant Options tree.
This would be overkill IMO. We should be fine with a (maximum) two level
hirachy! And remember: Let's keep the "baby" small and fast :-)
Oh: If you need Icons: don't hesitate to tell me! I'll paind them with
pleasure!
Greetings,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Antidote TODO (WAS:RE: antidote diff)
Posted by Jack Woehr <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> You ased me about the Preferences topic: It should fit into the current,
> in most places clean, small and fast, Antidote-code. Oh: And it should
> look similar to the rest of the application ;-). Just an opinion, but I
> think the MozillaFirebird option dialog is one of the nicest I have seen
> ;-).
Not familiar with that, but will try to take a look. There is a *possibility*
(not a certainty) that I will lose my high-speed connection in the near future,
which would make playing with Mozilla a little hard. We'll see what happens.
But ... Preferences and storing them via Properties I understand well. How
we handle the GUI side of that "remains to be seen". There is also the NetBeans
model of a giant Options tree.
--
Jack J. Woehr # "[F]ar in the empty sky a solitary esophagus slept
http://www.well.com/~jax # upon motionless wing; everywhere brooded stillness,
http://www.softwoehr.com # serenity, and the peace of God." - Mark Twain
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Antidote TODO (WAS:RE: antidote diff)
Posted by Christoph Wilhelms <Ch...@t-online.de>.
Hi Jack!
I've committed your updates to the TODO-List. Thanx! I'll integrate it
in the WebPage shortly...
Now it would be really nice, if you pick up a task (a single one if you
do not mind) and implement it- if you like :-)!
You ased me about the Preferences topic: It should fit into the current,
in most places clean, small and fast, Antidote-code. Oh: And it should
look similar to the rest of the application ;-). Just an opinion, but I
think the MozillaFirebird option dialog is one of the nicest I have seen
;-).
If you like to talk about design of specific things THIS is the right
place!
Greetings,
Christoph
P.S.: And do us all (including yourself ;-) a favour and disabe
HTML-E-Mails.... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Antidote TODO (WAS:RE: antidote diff)
Posted by Christoph Wilhelms <Ch...@t-online.de>.
Hi Jack!
> > It's an old, but just in some points outdated TODO-list.
> > Feel free to pic up a task!
I re to my own words first: The TODO-List is old and not updated for a
long time! Additionally it is not by me, but by Simeon. To be honest I
do not understand all points by myself, but I can give advice to some of
them! Let me try to! BTW: Checking and updating that TODO, so that we
can put it on the projects webpage would be a task :-).
> This is the same checked-in TODO list that is in the CVS tree, right?
yup
> Maybe the first step is to update the TODO list :-)
>
> Let's look at some items from TODO List:
>
> * Cleanup build.xml file; make antidote specific.
>
> This has been done already, right?
I think so!
> * Rewrite ACSFactory to use it's own parser rather than
> the implementation
> specific com.sun.xml.tree.SimpleElementFactory class
> (only available
> in JAXP from Sun).
>
> Done? Still TODO?
Has to be rececked, but generally it works fin IMHO
> * Add editors for defining file sets, and other "sets".
>
> This has been done already, right?
Particualry! IMHO there could be mor comfort in defining filesets, what
do you think!?!
> * Write wizzard framework.
>
> The framework is there, but there are currently no
> wizards, right?
There is a "not working" example wizard for an entire build-file. IMO
the wizarg could be used to create targets in addition...
> * Implement a build progress reporter.
>
> What would that look like, compared to the console that
> currently exists?
I thinks the console is ok, but Sim meant to write a log to a file in
addition. Obviously the log line formtting has to be definable
interactively and stored in preferences...
> * Implement a "Worker Thread" pattern that allows workers to have
> their work done in a thread property registered with
> Antidote, and
> provide support to that worker to provide progress updates via
> the GUI. Should also provide support for hour-glass cursor
> handling, and AWT event blocking until task is completed. This
> would be used for things such as loading files or other tasks
> that the user must wait for completion.
>
> Has this been done or is it still TODO? I think it is still TODO.
It IS a to do! There is no way to stop Ant once it runs from Antidote!
> * Add menu option to select the compiler to use, which then sets
> the "build.compiler" property. Better yet, create a generic menu
> building capability that allows the setting of a property from a
> list of options.
>
> Still TODO, right?
It is a todo! I'd propose not just setting the complier, put the option
to set all Ant -D parameters from the gui and make them storable!
> * Add ability to put an "all" or "don't care" specifyer
> on the action
> "enableOn" and "disableOn" properties.
>
> Still TODO, right?
It is not implemented IIRC! Additionally I am not really shure what it
should do...
> * Add ability to view task dependencies more fully.
>
> Describe this facility?
It should say "target-dependency". It would be nice to be able to show a
grafic with all the tragets and arrows between them to show the
dependency (depends). Would be really a feature for many guys using Ant,
I know...
> * Add better editors for specific tasks.
>
> Examples?
Not only for tasks, but properties in addition. We meant editors just
like the dependency choose!
> * Add a Progress Monitor for file loading (especially for
> slow boxen like
> mine) .
>
> Still TODO, right?
Yes, it is! Progress for loading files and for the time the
introspection rus would be nice!
> * Implement some for of refid hyperlinking functionality.
>
> Describe this facility?
Not shure what Sim means... Yould someone else drop in here...!?!
> * Implement context sensitive menus for the console
> window, allowing
> an error to be selected and invoked in IDE.
>
> "Jump-to" in Antidote itself?
I think integration into IDEs is no BIG project aim anymore or at leas
ATM...
> * Write preferences framwork, including persistence support.
>
> Trivial, still TODO? I can borrow this from my own open
> source code.
Would be nice, if the code is under an Apache compatible OSS License
(like Apache or FreeBSD) LGPL is NOT ok!!
I'd prefer a small, fast an clean implementation as always ;-).
> * Provide some sort of class path debugging support.
>
> Describe this facility?
Not 100% shure, but displaying the Ant-build-classpath and introspect
the jars one by one... Search for Classes and multiple occurrences in
the classpath... And so on!
> * Add "syntax" colorization to the console window {done},
> with a preferences editor for setting up the styles {not-done}.
>
> Describe this facility?
Just make the syntax highlighting in the console window configurable via
the Preferences window! Easy!
> * Figure out an approach to gracefully stopping a running build.
>
> Hmmm ... screech! crash! :-)
As I said before... Uneasy to implement without hooks in Ant
itself...;-)
> * Add error handler for SAX parser to better report
> loading errors.
>
> Still TODO?
Yupp! Not done!
> * Project properties viewer, including the ability to view
> dependencies (local and cascading).
>
> Describe this facility?
As said before: View and modify the Projekt Properties you can override
using -D with the Ant-Commandline! Cascading means from imported
build.xmls
> * Acquire or implement a logging facility.
>
> What, are we thinking JLog here?
I'd prefer Log4J. Logkit would be another option... Or the jakarta
commons logging facility...
> * Eat more dog food.
>
> I'm using it! It's not easy to use yet, the editors are
> not much fun to use compared to merely typing things in
> NetBeans source editor!
Yes: The editors have to be improved definately!
> Also, I'd add this usability feature:
>
> * When you are editing some task or property or target and
> you decide to delete that thing, the editor should disappear.
Could you explain...
Greetings,
Christoph!
P.S.: Sorry for answering that late but ATM I am just online every
second day!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> It's an old, but just in some points outdated TODO-list. Feel free to
> pic up a task!
This is the same checked-in TODO list that is in the CVS tree, right?
Maybe the first step is to update the TODO list :-)
Let's look at some items from TODO List:
* Cleanup build.xml file; make antidote specific.
This has been done already, right?
* Rewrite ACSFactory to use it's own parser rather than the implementation
specific com.sun.xml.tree.SimpleElementFactory class (only available
in JAXP from Sun).
Done? Still TODO?
* Add editors for defining file sets, and other "sets".
This has been done already, right?
* Write wizzard framework.
The framework is there, but there are currently no wizards, right?
* Implement a build progress reporter.
What would that look like, compared to the console that currently exists?
* Implement a "Worker Thread" pattern that allows workers to have
their work done in a thread property registered with Antidote, and
provide support to that worker to provide progress updates via
the GUI. Should also provide support for hour-glass cursor
handling, and AWT event blocking until task is completed. This
would be used for things such as loading files or other tasks
that the user must wait for completion.
Has this been done or is it still TODO? I think it is still TODO.
* Add menu option to select the compiler to use, which then sets
the "build.compiler" property. Better yet, create a generic menu
building capability that allows the setting of a property from a
list of options.
Still TODO, right?
* Add ability to put an "all" or "don't care" specifyer on the action
"enableOn" and "disableOn" properties.
Still TODO, right?
* Add ability to view task dependencies more fully.
Describe this facility?
* Add better editors for specific tasks.
Examples?
* Add a Progress Monitor for file loading (especially for slow boxen like
mine) .
Still TODO, right?
* Implement some for of refid hyperlinking functionality.
Describe this facility?
* Implement context sensitive menus for the console window, allowing
an error to be selected and invoked in IDE.
"Jump-to" in Antidote itself?
* Write preferences framwork, including persistence support.
Trivial, still TODO? I can borrow this from my own open source code.
* Provide some sort of class path debugging support.
Describe this facility?
* Add "syntax" colorization to the console window {done},
with a preferences editor for setting up the styles {not-done}.
Describe this facility?
* Figure out an approach to gracefully stopping a running build.
Hmmm ... screech! crash! :-)
* Add error handler for SAX parser to better report loading errors.
Still TODO?
* Project properties viewer, including the ability to view
dependencies (local and cascading).
Describe this facility?
* Acquire or implement a logging facility.
What, are we thinking JLog here?
* Eat more dog food.
I'm using it! It's not easy to use yet, the editors are not much fun to use compared to merely typing things in NetBeans source editor!
Also, I'd add this usability feature:
* When you are editing some task or property or target and you decide to delete that thing, the editor should disappear.
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
Re: antidote diff
Posted by Jack Woehr <ja...@purematrix.com>.
peter reilly wrote:
> if the -d is missing, cvs does not check for new directories.
Arghh! Caught by the oldest trap in the business! :-)
--
Jack J. Woehr # "[F]ar in the empty sky a solitary esophagus slept
http://www.well.com/~jax # upon motionless wing; everywhere brooded stillness,
http://www.softwoehr.com # serenity, and the peace of God." - Mark Twain
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by peter reilly <pe...@corvil.com>.
On Monday 15 September 2003 16:48, Jack Woehr wrote:
>
> Hmm, I just updated my tree and ./build.sh yields the following:
>
> src/main/org/apache/tools/ant/types/selectors/SelectorContainer.java:59:
> package org.apache.tools.ant.types.selectors.modifiedselector does not
> exist import
You need to do cvs -q update -d
if the -d is missing, cvs does not check for new directories.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Jack Woehr <ja...@purematrix.com>.
Erik Hatcher wrote:
>
> I just committed a couple of fixes to bring proposal/xdocs back up to
> speed. Let me know if you encounter any issues running it. Again, run
> the "docs-from-scratch" target to get the full picture. Also, you'll
> need to bump up your memory allocation to get XDoclet happy. I do this:
>
> setenv ANT_OPTS "-Xmx1000m"
>
> you could probably get away with a smaller number, like 512.
>
>
Hmm, I just updated my tree and ./build.sh yields the following:
[09:46:27 jax@snafu:/usr/local/src/apache/apache_src/ant]$ ./build.sh
... Bootstrapping Ant Distribution
... Compiling Ant Classes
src/main/org/apache/tools/ant/types/AbstractFileSet.java:85: package org.apache.tools.ant.types.selectors.modifiedselector does not exist
import org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector;
^
src/main/org/apache/tools/ant/types/selectors/SelectorContainer.java:59: package org.apache.tools.ant.types.selectors.modifiedselector does not exist
import org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector;
^
src/main/org/apache/tools/ant/types/selectors/BaseSelectorContainer.java:63: package org.apache.tools.ant.types.selectors.modifiedselector does not exist
import org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector;
^
src/main/org/apache/tools/ant/types/AbstractFileSet.java:689: cannot resolve symbol
symbol : class ModifiedSelector
location: class org.apache.tools.ant.types.AbstractFileSet
public void addModified(ModifiedSelector selector) {
^
src/main/org/apache/tools/ant/types/selectors/SelectorContainer.java:215: cannot resolve symbol
symbol : class ModifiedSelector
location: interface org.apache.tools.ant.types.selectors.SelectorContainer
void addModified(ModifiedSelector selector);
^
src/main/org/apache/tools/ant/types/selectors/BaseSelectorContainer.java:337: cannot resolve symbol
symbol : class ModifiedSelector
location: class org.apache.tools.ant.types.selectors.BaseSelectorContainer
public void addModified(ModifiedSelector selector) {
^
src/main/org/apache/tools/ant/taskdefs/MatchingTask.java:84: package org.apache.tools.ant.types.selectors.modifiedselector does not exist
import org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector;
^
src/main/org/apache/tools/ant/taskdefs/MatchingTask.java:463: cannot resolve symbol
symbol : class ModifiedSelector
location: class org.apache.tools.ant.taskdefs.MatchingTask
public void addModified(ModifiedSelector selector) {
^
src/main/org/apache/tools/ant/taskdefs/Delete.java:80: package org.apache.tools.ant.types.selectors.modifiedselector does not exist
import org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector;
^
src/main/org/apache/tools/ant/taskdefs/Delete.java:452: cannot resolve symbol
symbol : class ModifiedSelector
location: class org.apache.tools.ant.taskdefs.Delete
public void addModified(ModifiedSelector selector) {
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -deprecation for details.
10 errors
... Failed compiling Ant classes !
Bootstrap FAILED
--
Jack J. Woehr # "[F]ar in the empty sky a solitary esophagus slept
http://www.well.com/~jax # upon motionless wing; everywhere brooded stillness,
http://www.softwoehr.com # serenity, and the peace of God." - Mark Twain
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I just committed a couple of fixes to bring proposal/xdocs back up to
speed. Let me know if you encounter any issues running it. Again, run
the "docs-from-scratch" target to get the full picture. Also, you'll
need to bump up your memory allocation to get XDoclet happy. I do this:
setenv ANT_OPTS "-Xmx1000m"
you could probably get away with a smaller number, like 512.
On Monday, September 15, 2003, at 04:52 AM, Erik Hatcher wrote:
> On Monday, September 15, 2003, at 01:41 AM, Christoph Wilhelms wrote:
>> Atidote was relying on dtd description of tasks and types but i
>> changed
>> this to introspection to gain more flexibility. Additionally the DTDs
>> quickly became outdated! There had be a plan to aotomatically generate
>> metadata/metainformation on tasks and types using xdoclet... I am not
>> shure how far that went. I think Erik Hatcher has to drop in to this
>> discussion to give further information on this!
>
> in proposal/xdocs is a project to generate XML descriptor files for
> each Ant task. this XML file contains meta information that you could
> not get from introspection like the task description (from Javadoc
> comments), and sub-element and attribute descriptions, and provides a
> lot of rich information that would be very handy to antidote, i'd
> suspect.
>
> apparently the build ("docs-from-scratch" target) is broken currently,
> so i'm going to have a quick look into fixing it now.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Monday, September 15, 2003, at 01:41 AM, Christoph Wilhelms wrote:
> Atidote was relying on dtd description of tasks and types but i changed
> this to introspection to gain more flexibility. Additionally the DTDs
> quickly became outdated! There had be a plan to aotomatically generate
> metadata/metainformation on tasks and types using xdoclet... I am not
> shure how far that went. I think Erik Hatcher has to drop in to this
> discussion to give further information on this!
in proposal/xdocs is a project to generate XML descriptor files for
each Ant task. this XML file contains meta information that you could
not get from introspection like the task description (from Javadoc
comments), and sub-element and attribute descriptions, and provides a
lot of rich information that would be very handy to antidote, i'd
suspect.
apparently the build ("docs-from-scratch" target) is broken currently,
so i'm going to have a quick look into fixing it now.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
re: antidote diff
Posted by Christoph Wilhelms <Ch...@t-online.de>.
jax@purematrix.com wrote:
> Christoph Wilhelms wrote:
>
> > One thing that has been started, but has never finished is a Wizard
> > for build-files! Would be nice if you could pick that task up!
>
> Is there a spec or design for this?
There's just the implementation you find in the code (wizard package)
> I was thinking about DTD imports so optional tasks could
> describe themselves to Antidote if the authors of the tasks
> chose to include a DTD for their tasks. Or is that already a
> feature of Antidote?
Atidote was relying on dtd description of tasks and types but i changed
this to introspection to gain more flexibility. Additionally the DTDs
quickly became outdated! There had be a plan to aotomatically generate
metadata/metainformation on tasks and types using xdoclet... I am not
shure how far that went. I think Erik Hatcher has to drop in to this
discussion to give further information on this!
For further tasks to do on Antidote I'd like to point you to tis
document:
http://cvs.apache.org/viewcvs/ant-antidote/TODO?rev=HEAD&content-type=te
xt/vnd.viewcvs-markup
It's an old, but just in some points outdated TODO-list. Feel free to
pic up a task!
Greetings,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> One thing that has been started, but has never finished is a Wizard for
> build-files! Would be nice if you could pick that task up!
Is there a spec or design for this?
> Another thing not implemented is support for "xml-import"
Can you explain xml-import, please?
> and automated
> code generation for antcall providing a preselection of targets
> available (in this or another build-file).
Interesting
> And so on... Probably you have suggestions to extend Antidote aswell!
I was thinking about DTD imports so optional tasks could describe themselves to Antidote
if the authors of the tasks chose to include a DTD for their tasks. Or is that already a feature
of Antidote?
> I'd be happy to discuss them here!
Thank you!
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> jax@purematrix.com wrote:
> Christoph Wilhelms wrote:
>
> > Regarding Jacks Question:
> >
> > IIRC the only GUI-generated code in Antidote is the
> > dependency chooser
> > dialog, and it had been generated using VisualAge 2.0 (by myself in
> > early 2001). All other GUI code you find in Antidote is particualry
> > highly generic and hand coded!
>
> Also sprachst du :-) ... *but* ... If initComponents() and
> exitForm() in org/apache/tools/ant/gui/MainFrame.java
> weren't generated by NetBeans I'd be a very surprised Java
> programmer ... :-)
I bet you are ;-). Just two methodt names? Well, probably they initially
have been generated by NetBeans, but the current content looks pretty
hand coded to me ;-)!
> > There are certain tasks open- specially editors to be
> > written. It has
> > to be worked on stability and so on!
>
> Can you say more about this?
Of course!
One of the main design goals of Antidote is, to keep it small and fast,
but I thik it still could have more comfort in Buildfile development!
One thing that has been started, but has never finished is a Wizard for
build-files! Would be nice if you could pick that task up!
Another thing not implemented is support for "xml-import" and automated
code generation for antcall providing a preselection of targets
available (in this or another build-file).
And so on... Probably you have suggestions to extend Antidote aswell!
I'd be happy to discuss them here!
Greetings,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Christoph Wilhelms wrote:
> Regarding Jacks Question:
>
> IIRC the only GUI-generated code in Antidote is the dependency chooser
> dialog, and it had been generated using VisualAge 2.0 (by myself in
> early 2001). All other GUI code you find in Antidote is particualry
> highly generic and hand coded!
Also sprachst du :-) ... *but* ... If initComponents() and exitForm() in
org/apache/tools/ant/gui/MainFrame.java weren't generated by NetBeans
I'd be a very surprised Java programmer ... :-)
> If you want to take part in Antidote develpoment: You are welcome!
Thank you!
> There are certain tasks open- specially editors to be written. It has to
> be worked on stability and so on!
Can you say more about this?
--
Jack J. Woehr # You measure democracy by the freedom it
Senior Consultant # gives its dissidents, not the freedom
Purematrix, Inc. # it gives its assimilated conformists.
www.purematrix.com # - Abbie Hoffman
RE: antidote diff
Posted by Christoph Wilhelms <Ch...@t-online.de>.
Hi Sefan, Jack and Conor!
> Antidote has had two or three phases of increased development
> efforts with longer breaks of inactivity in between. The
> last one has been winter/early spring this year IIRC. The
> Ant committer who's currently most interested in Antidote has
> switched jobs by then and may have some trouble to keep up
> with it ATM.
Yup, Stefan! You are so right... I still have plans for Antidote, but...
Additonally I'll buy a very old hous shortly and will spend much time
renewing it...
Regarding Jacks Question:
IIRC the only GUI-generated code in Antidote is the dependency chooser
dialog, and it had been generated using VisualAge 2.0 (by myself in
early 2001). All other GUI code you find in Antidote is particualry
highly generic and hand coded! Mostly by the original Antidotedeveloper
Sim Fitch. I had a big discusson with him regarding GUI builder way back
when and now knowing the code well enough I have to agree with him, that
a GUI builder would not add much effort in the fothcome of Antidote
developement!
If you want to take part in Antidote develpoment: You are welcome!
There are certain tasks open- specially editors to be written. It has to
be worked on stability and so on!
@Stefan and Conor: I promise to pick up the Antidote-commits in the
future! I still monitor this list and I am still with you :-)
Greetings,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 10 Sep 2003, Jack Woehr <ja...@purematrix.com> wrote:
> though since the last changes seem to have been February there is
> probably a lot of scope for the interested coder!?
Antidote has had two or three phases of increased development efforts
with longer breaks of inactivity in between. The last one has been
winter/early spring this year IIRC. The Ant committer who's currently
most interested in Antidote has switched jobs by then and may have
some trouble to keep up with it ATM.
Most Ant committers don't work on Antidote at all. Some of them (me
included) simply don't enjoy GUI programming at all. In addition it
is hard to work on something you don't use. I'm absolutely happy with
using Ant from the command line (errm, XEmacs compile command, that
is) and others use the integration present in their IDE of choice.
> My main observation is, "I wish they had continued developing the
> GUI in NetBeans and kept the .form files," (since parts of the
> project apparently started under NetBeans).
My recollection is different. The NetBeans/Ant integration has been
developed very early - a couple of months before Antidote started -
sometime early spring 2000 as opposed to autumn 2000 IIRC.
But as far as I understand it, Antidote has been independent from the
NetBeans integration. The two projects may have borrowed ideas from
each other, but they've been independent efforts.
> If I were "attack" the GUI in that fashion (tossing it back into
> NetBeans) would that be acceptable or would that cross some
> guideline?
I'm not sure I understand what you mean by "tossing it back".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Jack Woehr <ja...@purematrix.com>.
Stefan Bodewig wrote:
> > Trivial antidote diff that clears up 7 of 15 javadoc warnings during
> > build.
>
> Will be committed in a few seconds, thanks
Well, thank you. Will continue to wander through the source in my spare moments.
I grasp Antidote, not sure how far I can go, though since the last changes seem
to have been February there is probably a lot of scope for the interested coder!?
My main observation is, "I wish they had continued developing the GUI in NetBeans
and kept the .form files," (since parts of the project apparently started under
NetBeans).
If I were "attack" the GUI in that fashion (tossing it back into NetBeans) would
that be acceptable or would that cross some guideline?
--
Jack J. Woehr # "[F]ar in the empty sky a solitary esophagus slept
http://www.well.com/~jax # upon motionless wing; everywhere brooded stillness,
http://www.softwoehr.com # serenity, and the peace of God." - Mark Twain
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 09 Sep 2003, Jack J. Woehr <ja...@purematrix.com> wrote:
> I posted this on user@ ... maybe not the right place.
True, development stuff (including patches) should be on the dev list.
> Trivial antidote diff that clears up 7 of 15 javadoc warnings during
> build.
Will be committed in a few seconds, thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 10 Sep 2003, Lajos Pajtek <la...@yahoo.com> wrote:
> This cvs diff should fix the remaining javadoc warnings in
> antidote.
committed, thanks.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: antidote diff
Posted by Lajos Pajtek <la...@yahoo.com>.
Hi,
This cvs diff should fix the remaining javadoc warnings in
antidote.
LP.
--- "Jack J. Woehr" <ja...@purematrix.com> wrote:
> Hi --
>
> I posted this on user@ ... maybe not the right place.
>
> Trivial antidote diff that clears up 7 of 15 javadoc warnings
> during build.
>
> Let me know if this is the appropriate forum for such things.
>
> --
> Jack J. Woehr # You measure democracy by the freedom it
> Senior Consultant # gives its dissidents, not the freedom
> Purematrix, Inc. # it gives its assimilated conformists.
> www.purematrix.com # - Abbie Hoffman
>
>
>
> ATTACHMENT part 2 application/x-gzip
name=antidote_20030909_jax.diff.gz
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com