Maven repository for Strongback

[primetoxinz]

It would be helpful to get Strongback into a maven repository for use with systems such as gradle.
It would allow using Strongback along side of GradleRIO instead of having to be redistributed through the CLI

[rhauch]

We could put the Strongback JARs into Maven Central, but the you would have to deal with third party libraries that are now required by the 2017 WPILib (see wpilibsuite/GradleRIO#16). But you actually can make that work with Strongback now in the same way that link suggests dealing with 3rd party libs by just downloading the Strongback Java Library JARs directly in the archives on our releases page.

In short, I'm not sure that putting Strongback JARs into Maven Central would really help much. It totally would if all the other JARs were already in Maven Central. (And if they were, we'd be building with Maven or Gradle rather than the archaic Ant!)

[HeroCC]

It doesn't need to be included in Maven Central, you can use Sonatype Nexus or Artifactory on a selfhosted server.

[primetoxinz]

I'd like to point out with the current GradleRIO I am able to get all dependencies from Maven except Strongback! so with some work it could be done. Here is our build.gradle for this year using this setup.

[rhauch]

Who uploads those artifacts? Last time I spoke with the WPI folks, they had no plans to use Maven.

[primetoxinz]

It appears that some of the 3rd party libraries are being hosted by the GradleRIO dev at http://dev.imjac.in/maven/thirdparty (Namely CTRE libraries) but the rest of it is all on http://first.wpi.edu/FRC/roborio/maven/release

[agausmann]

That's interesting, I never knew there was an official Maven repository (assuming since it is from the WPI website). That might make a maven build process more desirable, but we would still have to maintain Ant compatibility.

[jmcshane]

I am looking further into this as the team I am associated with is interested in using the library and uses a gradle based build like @primetoxinz. I believe that I could create a maven structure that could build jars for each of the strongback projects for publishing in the maven format.

I think the format for use by teams with a gradle/maven build would just be to add strongback adjacent to the build.gradle dependencies outlined in wpilibsuite/GradleRIO#16. I'll try to get this documented along with a PR when I get the maven project setup complete.

Is this something that the strongback team is interested in? It moves away from the CLI type pattern, but it may support more teams with existing maven/gradle structures incorporating your library.

[rhauch]

@jmcshane sure, we'd be interested in supporting teams that use Maven or Gradle, as long as we kept support for the current approach as the WPILib documentation and Eclipse plugins are still all Ant-based. I'd even be fine with changing the build system of Strongback over to Maven/Gradle, as long as we're able to keep producing the same outputs. Personally, I use Maven at work and really dislike Ant, but we went that way to keep things as close to the idiomatic WPILib approach. The problem has always been dealing with the dependencies when they are not available in a Maven repository.

So, I do have a few questions/concerns:

1. Is it just me, or is the WPI Maven repository out of date?
2. What happens during the beta period? The WPILib beta artifacts cannot be disseminated or re-hosted elsewhere?
3. Owners of all 3rd party libraries would need to approve of hosting their artifacts in a Maven repository. These are often part of the companies' products, and so I would not be surprised if they refused to allow the artifacts to be hosted elsewhere.

[jmcshane]

@rhauch I don't know the answer to your first two questions, those questions would need to be addressed to the owners of those artifacts.

In response to your third question, there are ways to deal with the non-public dependencies using gradle/maven as well. If these dependencies exist for current strongback code (I imagine that's what the third-party-libraries repository is for), there could be documentation for optionally cloning that library into a project as a git-style sub-module and referencing it within the pom.xml or build.gradle.

[rhauch]

Well, the third party library repository was temporary while the vendors provided non-Windows versions of their libraries for FRC. I just deleted it.

The CLI tool downloads the repositories as required from their official locations.

[jmcshane]

I do see how the ant build downloads the files directly from their official locations from the vendors. I'll check and see if I can incorporate that structure within a gradle project.

My thought is that I can lay out some basic examples for bringing those third party dependencies into a project in a gradle or maven project. I'll do some investigation and put more info in the PR as it develops.

[jmcshane]

It appears that the WPI maven repository is up to date with the way that ant downloads the libraries. The gradle project will now be flexible enough to select a version of the library, and it will be possible to load the same properties file in both ant and gradle.

The PR should be good to go and the jars that get published are:

• strongback.jar
• strongback-tools.jar
• strongback-testing.jar

I haven't defined any of the publishing mechanisms, I'll leave that up to the repository owner to decide the best hosting mechanisms for the jars.

I will be adding documentation for how gradle and maven projects can reference the ctre and navx libraries. Each build system has an ability to reference ant tasks, which is why I created the third-party.xml and thirdparty.properties file in the PR.

[SUPERCILEX]

Since it looks like this repo is dead, I've setup a maven to easily use Strongback with Gradle. Add JitPack and then add the Strongback lib. It's that simple. 😄