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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
