Closed Zabot closed 9 years ago
Looks great. The only question is whether you want to handle the TODO mentioned above now or later, and that's up to you.
BTW, I think we should hold off on the install
script. Let's get a build and release mechanism working, and then we can add another script that installs or upgrades Strongback.
One more thing: you said the directory structure would include:
├── libs
│ ├── logCon.jar
│ └── newProject.jar
Why create 2 JAR files? Wouldn't it just be easier to create a single strongback-executable.JAR
? And speaking of that, what do you think about renaming the strongback-executable
project (and JAR) to strongback-tools
?
I thought we talked about having one strongback
script (well, one for Windows and one for everything else) whose second parameter would be the 'command'. Kind of like 'git'. The benefit is that we have fewer scripts to manage, and there's only one "executable" for users to learn and remember.
@Zabot, I'd suggest having the script look at the first parameter and using it to pick the class file to run as main, and passing all other parameters as-is. But, it'd be nice if it could support a help
command ... not sure if that should be a Java class or in the script itself. (Normally, I'd put it in the script, but I also don't write windows scripts. :-) )
Bat file works in wine, I don't have a native windows machine to test it on right now. Both scripts do have a help
option; right now it just spits out the sub-commands that can be used, but it can do more or less in the future.
@Zabot, can you combine the scripts into one? I'd really like to have a single executable.
I did, strongback.bat
for windows and strongback.sh
for everyone else.
@Zabot, sorry about that. Looks good to me. Is there anything else you want to wait for, or can this be merged?
Its good to go. Anything else can be taken care of in separate issues.
Thanks, @Zabot. Nice work, as usual.
Here it is, there still is a bit of cleanup to do, but its pretty much ready to go, and it does affect #4, so I wanted to get it pushed.
NewProject
functions as both anew project
and aconvert project
if the override flag is set. It doesn't set any eclipse settings (classpath variables or user libraries), that will be handled by either another command, or instructions to the user, in case their wpilib is in a strange place.LogDecoder
got copied, the old one still works, but it can probably be deprecated if not removed entirely now.IncludeInBuild
should be copied into the distributed file by #4.strongback.properties
should end up in the root of the distribution. That is the only file that needs to go somewhere specific, everything else can use a variable instrongback.properties
. Below is the structure for the distribution file that I used for testing. In the actual distribution, the links will be replaced by the file they are linking to,/
is the repository root.Before merge:
Add strongback 'install' script/appSupersedes #14 Closes #6
Distribution file structure: