This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Sendopts API hard to use | ||
---|---|---|---|
Product: | platform | Reporter: | Petr Hrebejk <phrebejk> |
Component: | Launchers&CLI | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | apireviews, jglick |
Priority: | P2 | Keywords: | API_REVIEW_FAST |
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Petr Hrebejk
2012-03-14 09:12:27 UTC
#1 addressed in ergonomics#54c0eca30d5c #5 addressed in ergonomics#5caef2783920 #3 - Since ergonomics#5630f2e4ddd3 either long or short name is required #2 implemented in http://hg.netbeans.org/ergonomics/rev/6892e1e02b9b which should be reviewed as an API enhancement. #4 is still not addressed and it is not clear how to address it. It does not make much sense to introduce an artificial field (annotated with @Arg) which will not be used for anything. It might make sense to create a special annotation for the class that implements ArgsProcessor (or Runnable) to tell the system this class is about to be called everytime.Something like @ArgsPolicy(always=true) class MyOptions implements Runnable { public void run() { /* always called */ } } An enhancement would be to tight this behavior to grouping of options (not implemented when using @Arg now). In such case there would be @ArgsGrouping(GroupingPolicy.ANY) /* values {ALL|ANY|ONE|SOME} as defined by http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-sendopts/org/netbeans/spi/sendopts/OptionGroups.html */ class MyOptions implements Runnable { public @Arg(longName="nomatch") String never; public void run() { // called if 0-n options is matches - e.g. always. } } the grouping is however a complex operation that will need to wait. To match with functionality of OptionGroups, it needs to support subgroups of options - which would best be expressed as an fields of complex type public MySubOptions subOptions; where the class MySubOptions could have its own fields annotated by @Arg. This is complex and will not happen for 7.2. I am afraid. Integrated into 'main-golden', will be available in build *201203170400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/54c0eca30d5c User: Jaroslav Tulach <jtulach@netbeans.org> Log: #209559: Point 1: CommandLine.usage() works in standalone mode (without openide.util and openide.util.lookup) #1 is contrary to standard practice in any other API - you are assumed to have transitive dependencies on classpath. Ad JG #1. Don't agree. Sendopts has offers some additional features when used in NetBeans, but is capable of running as standalone library. Transitive deps of sendopts is 2 jars of more than 1M size. I don't see why people using the lib in a small command line utility should make theirs distro 1M larger when not necessary. #6 (Additionl bug) Sendopts jar contains OptionAnnotationProcessor. When used as standalone lib and added into a plain J2SE project, the processor likely throws and exception and stops the building process. That results in an empty .jar (not containig any classes) in the dist folder after running "Clean & Build" or "ant jar.". For printing out the ex use -Xdev as javac option (may be) #6 fixed in 2b954be54bfa (In reply to comment #7) > Sendopts has offers some additional features when used > in NetBeans, but is capable of running as standalone library. True, but the same is true of plenty of NB APIs. Refactoring Platform API modules to minimize the size of the dependency footprint from any given starting point is always beneficial, but we do not advocate running any other APIs with some of their declared dependencies missing. > people using the lib in a small command line utility Why? Its raison d'ĂȘtre is to send CLI commands to a running NB Platform-based app using CLIHandler based on $userdir/lock. If you just want a lightweight argument processor for a standalone CLI utility (not making a connection to a running app), use args4j or Commons CLI or the like. (In reply to comment #10) > If you just want a lightweight > argument processor for a standalone CLI utility (not making a connection to a > running app), use args4j or Commons CLI or the like. In case this bug is found by someone interested in CLI parsing library, please ignore the above comment and feel free to use sendopts. It is my intention to make it usable as a standalone API. I think all the issues are fixed, except the #4 - to support grouping/always present option. That one is more an enhancement and will be implemented as soon as somebody finds time and will to do it. Closing for now. Integrated into 'main-golden', will be available in build *201203220400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2b954be54bfa User: Jaroslav Tulach <jtulach@netbeans.org> Log: #209559: Point #6 - making sure the annotation processor is disabled in standalone mode |