te-code-users Mailing List for TE-Code
Brought to you by:
atownley
Menu
▾
▴
te-code-users — General user discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew S. T. <ato...@ei...> - 2006-06-30 14:18:27
|
Hi JP, I agree that this type of thing would be a good addition, but it would certainly add a lot of complexity to the help output generators. I know I put the RequiredOptionConstraint in the package, but I'm still sorta arguing with myself about the oxymoron of having something 'optional' be 'required' for correctness. :) What I have often done in this case in later tools I've written is simply added the required parameters to the description given to the constructor of the CommandParser (see the current examples/feather.java, line 59). If the required arguments aren't terribly obvious, you can then include the information in the preamble with either the AutoHelpListener.setHeader() or the CommandParser.setExtraHelpText() method, depending on your preference (based on the current source in CVS). While you lose the benefits of being able to handle the action in the execute method of your CommandOption class, it is, as I said, arguably more correct. Of course, if you need/want to do it this way for some other reasons, then that's different. :) Of the things I still want to do with the library (when I can get some time away from the "real job"), this is pretty low on my priority list. I do agree it would be useful, however, so feel free to contribute a patch against the current CVS if you would like. If it looks good and has unit tests, I'll accept it into the codestream. Thanks very much for the feedback, ast On Tue, 2006-06-27 at 22:32, SourceForge.net wrote: > Feature Requests item #1513562, was opened at 2006-06-27 15:06 > Message generated for change (Comment added) made by jbeaudry > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=567061&aid=1513562&group_id=82738 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: Interface Improvements (example) > Group: None > Status: Open > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Nobody/Anonymous (nobody) > Summary: Modify usage according to contraints > > Initial Comment: > Hi, > > I was wondering if it would be possible to have the > displayed usage tailored according to the contraints added? > > For example, if I have my 'program', with a mandatory > option called 'name' and execute it like this: > > bash#program > > I get the message: > > error: option 'name' is required. Exiting. > Usage: program [-n|--name <arg>] > > Since 'name' is not optional, ideally the usage would show: > > error: option 'name' is required. Exiting. > Usage: program -n|--name <arg> > > You could imagine more complicated scenarios when at > last one option of a group is mandatory. > > Thanks, > JP > > > ---------------------------------------------------------------------- > > Comment By: JP Beaudry (jbeaudry) > Date: 2006-06-27 16:32 > > Message: > Logged In: YES > user_id=829770 > > Doh, didn't mean to put in an anonymous request. > > Feel free to contact me if I can clarify the above. > > Thanks > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=567061&aid=1513562&group_id=82738 -- Andrew S. Townley <ato...@ei...> http://atownley.org |
|
From: Andrew S. T. <ato...@ei...> - 2006-03-15 17:36:18
|
Hi Toby, I'm just following up on the bug you entered back in December. I'm not sure how the tracker is supposed to work, but I would've figured that I would get an email that something was there. Apparently I didn't, so I only accidentally noticed that you'd filed it. I was wondering if you were still seeing the problem, and if so, you might provide some more information. I'd like to see your code (if possible) and know what version you're using. I'm very curious what's going on there, because I haven't seen that error in normal usage, and I thought I had tests for these sorts of things, but apparently not. I can't use the code in CVS HEAD to duplicate it because there's been some changes and 868 doesn't have a call to substring anymore. Again, apologies for not following up with you about this sooner. Please direct any support requests to the mailing list, and then at least I'm guaranteed to see them. :) ast -- Andrew S. Townley <ato...@ei...> http://atownley.org |
|
From: Andrew S. T. <ato...@ei...> - 2006-03-15 17:17:31
|
Hi Folks, I was just wondering if anyone on the list was interested in giving some feedback to the parts of the library they do/don't use and why. This summer, I'm going to try and finish my clean-up work and release a new RC with some of the enhancements I was attempting to do for a prospective user. They're all pretty-much there in CVS head (and only relate to the Java command-line parsing part), but they aren't rigorously tested yet. I've a lot on my plate at the moment, but I know it's been ages since I've released anything new. Any feedback will be considered when trying to decide where the libraries are going. Cheers, and thanks for your support. ast -- Andrew S. Townley <ato...@ei...> http://atownley.org |
|
From: Zachary L. <deu...@gm...> - 2006-03-08 14:47:51
|
Hi Andrew,
Yup, after creating MANIFEST.MF it compiles fine.
I'm not doing something major with it. It works fine for what I need it for=
.
Thanks for good code! =3D)
Zac
On 3/7/06, Andrew S. Townley <ato...@ei...> wrote:
>
> Hi Zac,
>
> You're running from the source release, I take it? I actually hadn't
> realized there was a problem here, but it seems that the MANIFEST.MF
> isn't part of the bundle. Oops.
>
> Here's the contents:
> $ cat MANIFEST.MF
> Manifest-Version: 3.0
> Main-Class: com.townleyenterprises.common.Version
>
> So, if you just add that file in the root of your source tree, it should
> build fine. Let me know if you have any more problems or questions.
>
> I haven't tested it with Java 1.5 much, so I'm interested in any
> feedback you may have. Last time I checked it, I didn't have any
> trouble. Unfortunately, the projects I'm using it for at the moment are
> only able to use JDK 1.4.
>
> Hope this helps,
>
> ast
>
> On Sat, 2006-03-04 at 04:51, Leung Ngai-Hang Zachary wrote:
> > Hi,
> >
> > I'm using Apache Ant version 1.6.5, Java version 1.5.0_06. When I
> compile
> > prerelease3, I get the following message. prerelease2 compiles ok
> though.
> > Any idea what is the matter?
> >
> > Zac
> >
> >
> >
> > Buildfile: build.xml
> > [taskdef] Could not load definitions from resource clovertasks. It
> could
> > not be found.
> >
> > builddate:
> > [propertyfile] Updating property file:
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/version.date
> >
> > verstamp:
> >
> > compile:
> > [mkdir] Created dir:
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> > [copy] Copying 12 files to
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> > [copy] Copied 18 empty directories to 4 empty directories under
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> > [javac] Compiling 110 source files to
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/common/AppConfig.java:90:
> > warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> > com.townleyenterprises.common has been deprecated
> > [javac] public static void registerAppSupplier(ConfigSupplier s=
)
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/common/AppConfig.java:122:
> > warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> > com.townleyenterprises.common has been deprecated
> > [javac] public static void
> > registerPersistenceSupplier(ConfigSupplier s) [javac]
> > ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/common/AppConfig.java:171:
> > warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> > com.townleyenterprises.common has been deprecated
> > [javac] public static ConfigSupplier
> > getPersistenceConfigSupplier()
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/PersistenceConfig.java:48:
> > warning: [deprecation] com.townleyenterprises.common.AppConfig in
> > com.townleyenterprises.common has been deprecated
> > [javac] import com.townleyenterprises.common.AppConfig;
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/SQLProvider.java:45:
> > warning: [deprecation] com.townleyenterprises.common.AppConfig in
> > com.townleyenterprises.common has been deprecated
> > [javac] import com.townleyenterprises.common.AppConfig;
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/SQLProvider.java:47:
> > warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> > com.townleyenterprises.common has been deprecated
> > [javac] import com.townleyenterprises.common.ConfigSupplier;
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/SQLProvider.java:111:
> > warning: [deprecation] com.townleyenterprises.common.AppConfig in
> > com.townleyenterprises.common has been deprecated
> > [javac] String vendor =3D
> > AppConfig.get("database.type");
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/SQLProvider.java:117:
> > warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> > com.townleyenterprises.common has been deprecated
> > [javac] ConfigSupplier cs =3D
> > AppConfig.getPersistenceConfigSupplier();
> > [javac] ^
> > [javac]
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3
> /java/com/townleyenterprises/persistence/SQLProvider.java:117:
> > warning: [deprecation] com.townleyenterprises.common.AppConfig in
> > com.townleyenterprises.common has been deprecated
> > [javac] ConfigSupplier cs =3D
> > AppConfig.getPersistenceConfigSupplier();
> > [javac] ^
> > [javac] Note: Some input files use unchecked or unsafe operations.
> > [javac] Note: Recompile with -Xlint:unchecked for details.
> > [javac] 9 warnings
> >
> > jar:
> >
> > BUILD FAILED
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build.xml:148:
> > Manifest file:
> > /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/MANIFEST.MF
> does
> > not exist.
> >
> > Total time: 14 seconds
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > te-code-users mailing list
> > te-...@li...
> > https://lists.sourceforge.net/lists/listinfo/te-code-users
> --
> Andrew S. Townley <ato...@ei...>
> http://atownley.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> te-code-users mailing list
> te-...@li...
> https://lists.sourceforge.net/lists/listinfo/te-code-users
>
--
Commit your way to the LORD;
trust in him, and he will act.
Psalm 37:5
|
|
From: Andrew S. T. <ato...@ei...> - 2006-03-06 17:34:06
|
Hi Zac,
You're running from the source release, I take it? I actually hadn't
realized there was a problem here, but it seems that the MANIFEST.MF
isn't part of the bundle. Oops.
Here's the contents:
$ cat MANIFEST.MF
Manifest-Version: 3.0
Main-Class: com.townleyenterprises.common.Version
So, if you just add that file in the root of your source tree, it should
build fine. Let me know if you have any more problems or questions.
I haven't tested it with Java 1.5 much, so I'm interested in any
feedback you may have. Last time I checked it, I didn't have any
trouble. Unfortunately, the projects I'm using it for at the moment are
only able to use JDK 1.4.
Hope this helps,
ast
On Sat, 2006-03-04 at 04:51, Leung Ngai-Hang Zachary wrote:
> Hi,
>
> I'm using Apache Ant version 1.6.5, Java version 1.5.0_06. When I compile
> prerelease3, I get the following message. prerelease2 compiles ok though.
> Any idea what is the matter?
>
> Zac
>
>
>
> Buildfile: build.xml
> [taskdef] Could not load definitions from resource clovertasks. It could
> not be found.
>
> builddate:
> [propertyfile] Updating property file:
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/version.date
>
> verstamp:
>
> compile:
> [mkdir] Created dir:
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> [copy] Copying 12 files to
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> [copy] Copied 18 empty directories to 4 empty directories under
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> [javac] Compiling 110 source files to
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:90:
> warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> com.townleyenterprises.common has been deprecated
> [javac] public static void registerAppSupplier(ConfigSupplier s)
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:122:
> warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> com.townleyenterprises.common has been deprecated
> [javac] public static void
> registerPersistenceSupplier(ConfigSupplier s) [javac]
> ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:171:
> warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> com.townleyenterprises.common has been deprecated
> [javac] public static ConfigSupplier
> getPersistenceConfigSupplier()
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/PersistenceConfig.java:48:
> warning: [deprecation] com.townleyenterprises.common.AppConfig in
> com.townleyenterprises.common has been deprecated
> [javac] import com.townleyenterprises.common.AppConfig;
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:45:
> warning: [deprecation] com.townleyenterprises.common.AppConfig in
> com.townleyenterprises.common has been deprecated
> [javac] import com.townleyenterprises.common.AppConfig;
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:47:
> warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> com.townleyenterprises.common has been deprecated
> [javac] import com.townleyenterprises.common.ConfigSupplier;
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:111:
> warning: [deprecation] com.townleyenterprises.common.AppConfig in
> com.townleyenterprises.common has been deprecated
> [javac] String vendor =
> AppConfig.get("database.type");
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:117:
> warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
> com.townleyenterprises.common has been deprecated
> [javac] ConfigSupplier cs =
> AppConfig.getPersistenceConfigSupplier();
> [javac] ^
> [javac]
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:117:
> warning: [deprecation] com.townleyenterprises.common.AppConfig in
> com.townleyenterprises.common has been deprecated
> [javac] ConfigSupplier cs =
> AppConfig.getPersistenceConfigSupplier();
> [javac] ^
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [javac] 9 warnings
>
> jar:
>
> BUILD FAILED
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build.xml:148:
> Manifest file:
> /media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/MANIFEST.MF does
> not exist.
>
> Total time: 14 seconds
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> te-code-users mailing list
> te-...@li...
> https://lists.sourceforge.net/lists/listinfo/te-code-users
--
Andrew S. Townley <ato...@ei...>
http://atownley.org
|
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-03-04 04:51:44
|
Hi,
I'm using Apache Ant version 1.6.5, Java version 1.5.0_06. When I compile
prerelease3, I get the following message. prerelease2 compiles ok though.
Any idea what is the matter?
Zac
Buildfile: build.xml
[taskdef] Could not load definitions from resource clovertasks. It could
not be found.
builddate:
[propertyfile] Updating property file:
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/version.date
verstamp:
compile:
[mkdir] Created dir:
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
[copy] Copying 12 files to
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
[copy] Copied 18 empty directories to 4 empty directories under
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
[javac] Compiling 110 source files to
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build/classes
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:90:
warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
com.townleyenterprises.common has been deprecated
[javac] public static void registerAppSupplier(ConfigSupplier s)
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:122:
warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
com.townleyenterprises.common has been deprecated
[javac] public static void
registerPersistenceSupplier(ConfigSupplier s) [javac]
^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/common/AppConfig.java:171:
warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
com.townleyenterprises.common has been deprecated
[javac] public static ConfigSupplier
getPersistenceConfigSupplier()
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/PersistenceConfig.java:48:
warning: [deprecation] com.townleyenterprises.common.AppConfig in
com.townleyenterprises.common has been deprecated
[javac] import com.townleyenterprises.common.AppConfig;
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:45:
warning: [deprecation] com.townleyenterprises.common.AppConfig in
com.townleyenterprises.common has been deprecated
[javac] import com.townleyenterprises.common.AppConfig;
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:47:
warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
com.townleyenterprises.common has been deprecated
[javac] import com.townleyenterprises.common.ConfigSupplier;
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:111:
warning: [deprecation] com.townleyenterprises.common.AppConfig in
com.townleyenterprises.common has been deprecated
[javac] String vendor =
AppConfig.get("database.type");
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:117:
warning: [deprecation] com.townleyenterprises.common.ConfigSupplier in
com.townleyenterprises.common has been deprecated
[javac] ConfigSupplier cs =
AppConfig.getPersistenceConfigSupplier();
[javac] ^
[javac]
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/java/com/townleyenterprises/persistence/SQLProvider.java:117:
warning: [deprecation] com.townleyenterprises.common.AppConfig in
com.townleyenterprises.common has been deprecated
[javac] ConfigSupplier cs =
AppConfig.getPersistenceConfigSupplier();
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 9 warnings
jar:
BUILD FAILED
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/build.xml:148:
Manifest file:
/media/DEUTSIXFIVE/computer/options/te-common-3.0.0-pre3/MANIFEST.MF does
not exist.
Total time: 14 seconds
|
|
From: Andrew S. T. <ato...@ei...> - 2005-10-29 12:47:37
|
Hi T.J., I'm glad you're finding the parser useful. I had forgotten that I didn't make a release for pre3 of the .NET edition. I've not had a lot of time to put into the project for a while, but a couple of months ago, in my spare time, I started working on the Java edition again to make sure adequate tests were in place and to perform some minor refactoring/enhancements requested by a user. If I remember correctly, I didn't release the pre3 version because the Java and .NET got somewhat out of sync as each was contributing refinements to the other (as I ported bits, other bits ended up needing refactoring in the original). However, the existing command.* classes should be stable. At the moment, I'm up to my eyeballs in some things for work, but in the meantime, if you have access to a CVS client, CVS head has all of what you're looking for in (as far as I remember) release condition. If you can't get to CVS, I can send you a snapshot bundle, but it would be easiest for you to check it out yourself. One thing someone noticed was that the build file isn't compatible with the latest version of NAnt (which is annoying because they keep changing the format of the file). This has been fixed in CVS as well. What's in CVS compiles with 0.85-rc3 of NAnt and all of the unit tests currently pass, except for testEndOfArgsNone for the command parser which after an hour of messing around with making sure CVS would work for you, I can't figure out what's busted (I should be working on my other stuff). Patches welcome... :) Immediate next steps for me with the project at the moment are: 1) Finish the refactoring of the Java Edition's command line parser 2) Verify backward compatibility of pre4 with rest using the still-a-work-in-progress regression tests in http://cvs.sourceforge.net/viewcvs.py/te-code/functionalqa/. 3) Back-port all of the Java changes into the .NET version as it is arguably the cleanest of the two 4) Extend the functionalqa test harness to know about compilation of .NET executables 5) Verify functional compatibility between the Java and .NET editions 6) See what's left to do to sync up the functionality of at least the command, common, config, filter, io and trace packages. 7) Remove build of unfinished/unstable packages from the core (so you know which are which) 8) Release 3.0.0-rc1 of both editions. Of course, there's actually a lot of work involved in all this. Given the rate that I'll be able to work on it in the near future (getting married in December), it will likely be at least March before #8 gets completed. That being said, I am reasonably confident that what is there is stable (there's only been one or two minor issues raised in the last 12 months that I'm aware of, and they have workarounds). The above is more house-cleaning and synchronization between the two. There shouldn't be much, if any, major new functionality overall. However, .NET will get filters and enhancements to the configuration stuff present in the Java edition as well as at least some solution for dealing with the .NET configuration files, but I don't really consider that major enhancements--it's stuff that was originally intended to be there from the beginning. If there's a desire for all this to happen sooner, I can't do it without help. I will certainly consider patches/additions from users in this area (as well as others, but I want to get 3.0 released as priority #1). Let me know how you get on, and I'm glad to know you're using the library. BTW, if you don't minding me asking, how did you find out about it? Cheers, ast On Fri, 2005-10-28 at 16:42, TJ Brown wrote: > I downloaded the .Net version of the libraries > (te-common.NET-3.0.0-pre2) to try the command line parsing classes. > I've been very pleased so far, however, I did notice that the > implementation is missing several classes that are described in the > documentation. The missing classes include: MutexOptionConstraint, > OptionConstraint, RequiredOptionConstraint, and > RequiresAnyOptionConstraint. These classes would be very helpful for > me. Would it be possible to make the latest implementation available? > > Thanks and good work. > T.J. -- Andrew S. Townley <ato...@ei...> http://atownley.blogspot.com |
|
From: TJ B. <tj...@gm...> - 2005-10-28 15:42:53
|
I downloaded the .Net version of the libraries (te-common.NET-3.0.0-pre2) t= o try the command line parsing classes. I've been very pleased so far, however, I did notice that the implementation is missing several classes that are described in the documentation. The missing classes include: MutexOptionConstraint, OptionConstraint, RequiredOptionConstraint, and RequiresAnyOptionConstraint. These classes would be very helpful for me. Would it be possible to make the latest implementation available? Thanks and good work. T.J. |
|
From: Andrew S. T. <ato...@ei...> - 2005-06-22 15:46:05
|
Kat, Glad it was helpful. Rest of the answers are in-line. On Tue, 2005-06-21 at 18:27, Kathiresan Nellayappan wrote: > 1. I am trying to include te-common.jar into our jar file. Is it OK to > re-pack the jar file ? What I mean is, extract the class files from > te-common.jar and re-package the class files into our own jar file. You can do what you need to do, but you do know you can use the Class-Path attribute in the jar MANIFEST.MF to specify the classpath you need. However, the license says you can do with it what you need to do. There's nothing prohibiting you repackaging the classes. > 2. In order to include te-common.jar's class files, what should our > software do in terms of MPL ? > The TE-Code license is derived from BSD, not the MPL, although they are quite similar. The specific requirements for including any part of te-common are specified rather explicitly in the license (http://te-code.sourceforge.net/LICENSE.html). Unless you trim out the bits not relating to the command package, you will also need to include the corresponding licenses from Jaxor and Sun. This isn't normally a big deal. If you look at the libro source, you'll see one way of making sure multiple licenses are included. Also, all of the licenses should appear (likely in an appendix) in any documentation shipped with your software. Hopefully, this clears up any questions you might have. If not, just let me know. ast -- Andrew S. Townley <ato...@ei...> http://atownley.blogspot.com |
|
From: Kevin R. <or...@gm...> - 2005-06-21 17:57:30
|
Hi Andrew, Thanks for the reply, I understand how you intended the default values to work much better now. I see that the way we have used arguments isn't compatible with this. The command my example comes from is called "website" and it manages aspects of a website directory. When called with the "-s" option, without a parameter, it reports status information for the current directory. If the "-s" option is specified with a parameter, it reports status information for the specified directory. I'm begining to suspect this approach to using arguments was wrong and in this case the directory parameter shouldn't be associated with this option. Rather, I should pick it up via CommandParser.getUnhandledArguments() and make the "-s" option a simple switch. Thanks for the help, Kevin |
|
From: Andrew S. T. <ato...@ei...> - 2005-06-21 17:14:29
|
Kat, Just looking at this further last night, I found out what is happening. The only solution I can offer right now without breaking the way the library works is to say you must associate your option and it's argument with '=', e.g. abcTool -launchedToolOpts="-optionA <arg1> -optionB -optionC <arg2>" The reason the library behaves this way is so that it can detect problems like: abcTool -launchedToolOpts -optionX -optionY foo where no argument has been specified to launchedToolOpts. Admittedly, the check for this case is a bit crude and includes a "FIXME: this could be better" comment, but if you use the '=' you can do what you need today. I'm open to suggestions on how to implement the check so that it does what I need and what you want (assuming you would prefer to not have to specify the '=' between the option and value). Please let me know if this is acceptable to you. Cheers, ast On Mon, 2005-06-20 at 10:44, Andrew S. Townley wrote: > Kat, > > Sorry I missed this. Please see earlier post as to the explanation. > Still, it's no excuse for not replying for 4 months... :( > > The answer is that this appears to be a bug. By the time the options > get to the parser, they appear to lose any string grouping you may have > specified on the command line due to them starting with '-'. > > I won't have a chance to look at this further today, but I'll get back > to you in the next couple of days. > > Again, apologies for the tardy response. > > ast > > > Hi, > > > > We have a requirement wherein a set of options corresponding to a > particular > > tool (which is launched from within our tool) have to be passed in > (as an > > argument to an option) to our command line tool. For example: > > > > Let"s assume that the command line tool is called "abcTool". There"s > an option > > for abcTool called "-lanchedToolOpts". > > > > abcTool -launchedToolOpts "-optionA <arg1> -optionB -optionC <arg2>" > -optionX > > <value> -optionY > > > > abcTool also needs to process other options like -optionX, -optionY > as > > settings for itself. The expectation here is that the argument to > > launchedToolOpts should be stored AS IS and passed onto to > launchedTool, > > verbatim. > > > > Any suggestions on how this could be achieved using TE-Common Java > libraries? > > > > Thanks > > -Kat. -- Andrew S. Townley <ato...@ei...> http://atownley.blogspot.com |
|
From: Andrew S. T. <ato...@ei...> - 2005-06-20 09:44:13
|
Kat, Sorry I missed this. Please see earlier post as to the explanation. Still, it's no excuse for not replying for 4 months... :( The answer is that this appears to be a bug. By the time the options get to the parser, they appear to lose any string grouping you may have specified on the command line due to them starting with '-'. I won't have a chance to look at this further today, but I'll get back to you in the next couple of days. Again, apologies for the tardy response. ast > Hi, > > We have a requirement wherein a set of options corresponding to a particular > tool (which is launched from within our tool) have to be passed in (as an > argument to an option) to our command line tool. For example: > > Let"s assume that the command line tool is called "abcTool". There"s an option > for abcTool called "-lanchedToolOpts". > > abcTool -launchedToolOpts "-optionA <arg1> -optionB -optionC <arg2>" -optionX > <value> -optionY > > abcTool also needs to process other options like -optionX, -optionY as > settings for itself. The expectation here is that the argument to > launchedToolOpts should be stored AS IS and passed onto to launchedTool, > verbatim. > > Any suggestions on how this could be achieved using TE-Common Java libraries? > > Thanks > -Kat. -- Andrew S. Townley <ato...@ei...> http://atownley.blogspot.com |
|
From: Andrew S. T. <ato...@ei...> - 2005-06-20 09:27:36
|
Kevin,
First off, sincerest apologies for missing this. There was apparently
some issue with me getting mail from the mailing lists. I just noticed
that there were two messages when I went looking to see why I hadn't
seen this before. Thanks for contacting me directly, or I wouldn't have
caught this!
Now, to answer your question:
The original intention of the default value was not to specify a default
parameter substitution, but rather to indicate the value which would be
used <em>if the parameter was not specified</em>.
The net effect is the same, but the semantics are different. Basically,
if the switch is given on the command line, the expectation is that you
will be overriding the default value, not that you expect the default
value to be substituted. I've used this a lot in systems I've written.
If you modify your program slightly:
$ cat OptionalArg.java
import com.townleyenterprises.command.CommandOption;
import com.townleyenterprises.command.CommandParser;
import com.townleyenterprises.command.DefaultCommandListener;
public class OptionalArg {
public static void main( String[] args ) {
CommandOption _option = new CommandOption(
"status", 's', true, null, "show status", "."
);
CommandParser _parser = new CommandParser( "OptionalArg" );
_parser.setExitOnMissingArg( true, -100 );
_parser.addCommandListener(
new DefaultCommandListener(
"options",
new CommandOption[] {
_option
}
)
);
_parser.parse( args );
System.out.println(_option.getArg());
}
}
and then run it, I think you'll notice they system is doing what you
wanted, but not exactly how you expected it to work:
$ java OptionalArg
.
I tried this with the latest release of the library:
$ java com.townleyenterprises.common.Version
TE Common API: 3.0.0-pre3 (Build 83; 2005-02-06 22:15:21 GMT)
I know that a long time ago, the default value was only used for the
display of the autohelp, but that changed at some point. Now, the
default value is evaluated if the argument is not matched, therefore,
you can just use the value in your software without needing to check to
see if it was matched or not.
If this isn't the behavior you're after and you can't modify the way
your command lines are being called, we can think through alternative
solutions.
Let me know if this helps.
Cheers,
ast
On Fri, 2005-06-17 at 13:32, Kevin Rogers wrote:
> Hi,
>
> First off my apologies for emailing you directly, but I haven't had
> any responses via the te-code users mailing list. I ran into a problem
> with default values for command line arguments and would appreciate
> any pointers if I'm trying to do things the wrong way. My original
> message to the mailing list follows:
>
> I'm trying to migrate the Perl parts of our application(MillScript -
> http://www.millscript.org/)
> into Java, using your command line argument parser. I've run into a
> problem and would appreciate any help you can offer. We have several
> interfaces to MillScript, with various options and my problem lies
> with options that take an optional argument, e.g.
>
> website -s
> or
> website -s /a/path/to/some/folder
>
> In this example, when no argument is specified the application
> defaults to using the current folder.
>
> For simplicity I've cut down my example Java implementation to the following:
>
> import com.townleyenterprises.command.CommandOption;
> import com.townleyenterprises.command.CommandParser;
> import com.townleyenterprises.command.DefaultCommandListener;
>
> public class OptionalArg {
>
> public static void main( String[] args ) {
> CommandOption _option = new CommandOption(
> "status", 's', true, null, "show status", "."
> );
> CommandParser _parser = new CommandParser( "OptionalArg" );
> _parser.setExitOnMissingArg( true, -100 );
> _parser.addCommandListener(
> new DefaultCommandListener(
> "options",
> new CommandOption[] {
> _option
> }
> )
> );
> _parser.parse( args );
> }
> }
>
>
> Unfortunately this doesn't work, as the default value for the argument
> is only used in the auto help feature. I was wondering if this should
> work as I expect it, i.e. the default value is used if no argument is
> specified? As it stands, the following happens:
>
> bash-2.05$ java -cp .:te-common.jar OptionalArg -s
> error: option --status requires parameter '<arg>'. Exiting.
> Usage: OptionalArg [-s|--status <arg>] [-?|--help] [--usage]
>
> Regards,
> Kevin
--
Andrew S. Townley <ato...@ei...>
http://atownley.blogspot.com
|
|
From: Kevin R. <or...@gm...> - 2005-06-01 10:12:08
|
Hi,
I'm trying to migrate the Perl parts of our application(MillScript)
into Java, using your command line argument parser. I've run into a
problem and would appreciate any help you can offer. We have several
interfaces to MillScript, with various options and my problem lies
with options that take an optional argument, e.g.
website -s
or
website -s /a/path/to/some/folder
In this example, when no argument is specified the application
defaults to using the current folder.
For simplicity I've cut down my example Java implementation to the followin=
g:
import com.townleyenterprises.command.CommandOption;
import com.townleyenterprises.command.CommandParser;
import com.townleyenterprises.command.DefaultCommandListener;
public class OptionalArg {
public static void main( String[] args ) {
CommandOption _option =3D new CommandOption(
"status", 's', true, null, "show status", "."
);
CommandParser _parser =3D new CommandParser( "OptionalArg" );
_parser.setExitOnMissingArg( true, -100 );
_parser.addCommandListener(
new DefaultCommandListener(
"options",
new CommandOption[] {
_option
}
)
);
_parser.parse( args );
}
}
Unfortunately this doesn't work, as the default value for the argument
is only used in the auto help feature. I was wondering if this should
work as I expect it, i.e. the default value is used if no argument is
specified? As it stands, the following happens:
bash-2.05$ java -cp .:te-common.jar OptionalArg -s
error: option --status requires parameter '<arg>'. Exiting.
Usage: OptionalArg [-s|--status <arg>] [-?|--help] [--usage]
Regards,
Kevin
|
|
From: Kathiresan N. <ka...@ca...> - 2005-02-18 01:25:44
|
Hi, We have a requirement wherein a set of options corresponding to a particular tool (which is launched from within our tool) have to be passed in (as an argument to an option) to our command line tool. For example: Let's assume that the command line tool is called "abcTool'. There's an option for abcTool called "-lanchedToolOpts". abcTool -launchedToolOpts "-optionA <arg1> -optionB -optionC <arg2>" -optionX <value> -optionY abcTool also needs to process other options like -optionX, -optionY as settings for itself. The expectation here is that the argument to launchedToolOpts should be stored AS IS and passed onto to launchedTool, verbatim. Any suggestions on how this could be achieved using TE-Common Java libraries? Thanks -Kat. |
2 messages has been excluded from this view by a project administrator.
