[modules-dev] Initial repository management tool

[Andreas Sterbenz]

Dave Bristor wrote:
> 
>>  . the Boolean.getBoolean() code in the comments can fail if there is 
>> a security manager
> 
> Hmm, I had the security manager at one point, anyway it's back now: thanks.

Right. It would only fail if there is unprivileged code on the stack, i.e. 
not when started from the command line but potentially in the future 
when/if we support invocation via something like the JSR 199 Tools API.

>>  . commands and JRepo constructor: it would seem clearer to me if the 
>> code to initialize the static 'commands' Map was in a static 
>> initializer rather than under a check in the constructor
> 
> Since Command is not static, a "this" is required for their 
> construction, so they can't be done statically.  Command is not static 
> because it makes use of ToolBase.usageError, etc.  Perhaps it would be 
> better to have "ToolHelper" (name?), and have JRepo create an instance 
> of it.  It's not much of a class and is only valuable *if* we convert 
> Jam.java to also use it.  What do you think?  I'm starting to tend that 
> way...

I see. I don't have any clever suggestions right now. We can figure that 
out later.

>>  . getMAIText(): should this really say "platform?" if platform is 
>> null, etc? Rather than an empty string, or "generic", or "n/a"?
> 
> I like "generic" for platform and arch, if for no other reason than I'm 
> used to it in bugster.  Do you have a suggestion for time and file?  I 
> kind of want to convey what it is that's unknown.  I left them as-is for 
> now, but am open to suggestions.  Perhaps it would help if there were 
> column headings?

For time and file, I can imagine "n/a", "-", or "" (leaving it blank). 
Column headings would seem useful.

>>  . the distinction between "list" and "find" (and "query") seems 
>> rather subtle. Do we need those as separate commands? Or could module 
>> name and version merely be optional parameters?
> 
> I used ruby "gems" as a model, as suggested by Stanley and the EG:
>     http://rubygems.org/read/chapter/2#page3
>     http://docs.rubygems.org/read/book/2
> Gem has separate commands for list vs. query.  Unix, etc. have directory 
> listing sepate from directory searching.  That's the rationale.  
> Conceptually listing and findind seem separate to me (my $0.02).

Well, I use "ls" both to list all files and to list ("find") a particular 
file:

# ls -l
# ls -l JRepo.java
# ls -l *.java

Unix find serves a different purpose. I use it when I need to use its more 
complex options (-type, -perm, -mtime, etc) or to search for something in 
a large directory hierarchy.

The current JRepo "list" and "find" don't have that those differences and 
there is no conflict in their options, so I am not sure what the advantage 
of keeping them separate is. FWIW, "gem list" also supports listing 
modules with a given name.

Andreas.