You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Christoph Wilhelms <Ch...@t-online.de> on 2003/09/19 07:32:29 UTC
Antidote TODO (WAS:RE: antidote diff)
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 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