[Zabot]

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 a new project and a convert 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.
• There aren't any shell scripts yet, but because the parsing is handled by the Java, they won't need to do anything other than call Java.
• The user ant scripts still need some tweaking, but that's outside the scope of this PR.
• All of the files in IncludeInBuild should be copied into the distributed file by Creating a build system #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 in strongback.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 shell scripts
• Add license headers
• Add strongback 'install' script/app

Supersedes #14
Closes #6

Distribution file structure:

strongback
    ├── bin
    │   ├── strongback.sh -> /strongback-tools/scripts/strongback.sh
    │   └── strongback.bat -> /strongback-tools/scripts/strongback.bat
    ├── java
    │   ├── ant
    │   │   ├── build.properties -> /ant/strongback/build.properties
    │   │   └── build.xml -> /ant/strongback/build.xml
    │   ├── libs
    │   │   └── strongback.jar
    │   └── templates
    │       ├── build.properties.template -> /ant/project/build.properties.template
    │       ├── build.xml.template -> /ant/project/build.xml.template
    │       ├── classpath.template -> /IncludeInBuild/classpath.template
    │       ├── project.template -> /IncludeInBuild/project.template
    │       ├── Robot.java.template -> /IncludeInBuild/Robot.java.template
    │       └── TestRobot.java.template -> /IncludeInBuild/TestRobot.java.template
    ├── libs
    │   └── strongback-tools.jar
    └── strongback.properties -> /IncludeInBuild/strongback.properties

[rhauch]

Yes. Basically, we need a properties file in the JAR (e.g., org/strongback/strongback.properties) that would look like:

version=${project.version}
buildDate=${project.version}

Ant can either generate this or append to an existing file in the source, or it can even replace these variables when it builds (see here).

Then, we add methods in Strongback to expose these values. For example, we could add this interface:

public static interface Metadata {
    public String version();
    public String buildDate();
}

and then add a method to the Strongback class that reads the properties file and returns the values. Really, Metadata just wraps that properties file using a Properties object:

public static Metadata metadata() {
    InputStream file = Strongback.class.getResourceAsStream("org/strongback/strongback.properties");
    assert file != null;
    Properties props = Properties.load(file);
    return new Metadata() {
        public String version() {
            return props.getProperty("version")
        }
        public String buildDate() {
            return props.getProperty("buildDate")
        }
    };
}

Maven makes it very easy to update these properties files with the Maven-specific properties (like ${project.version}), but Ant should be fine since we'll likely have to specify the version in the build script anyway.

You can either implement this now, or keep your TODO and create an issue to fix it.

[rhauch]

Looks great. The only question is whether you want to handle the TODO mentioned above now or later, and that's up to you.

[rhauch]

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.

[rhauch]

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?

[rhauch]

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.

[rhauch]

@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. :-) )

[Zabot]

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.

[rhauch]

@Zabot, can you combine the scripts into one? I'd really like to have a single executable.

[Zabot]

I did, strongback.bat for windows and strongback.sh for everyone else.

[rhauch]

@Zabot, sorry about that. Looks good to me. Is there anything else you want to wait for, or can this be merged?

[Zabot]

Its good to go. Anything else can be taken care of in separate issues.

[rhauch]

Thanks, @Zabot. Nice work, as usual.