NicolasRouquette
commented
7 years ago 1) does a couple of things:
- define an SBT release process
- configure settings for publishing artifacts
We were using this release process when we were publishing to an internal Sonatype Nexus repository (see: https://github.com/JPL-IMCE/imce.sbt.plugin#older-notes-for-jpls-internal-workflow)
Now, we're publishing to either bintray (public repos) or artifactory (internal repos). Either way, we don't use the sbt release process. This means the https://github.com/JPL-IMCE/imce.sbt.plugin could be simplified and the template as well.
If you look at the definition of this thing:
def packageReleaseProcessSettings: Seq[Setting[_]] =
Seq(
releaseProcess := Seq(
clearSentinel,
checkUncommittedChanges,
checkSnapshotDependencies,
inquireVersions,
extractStep,
setReleaseVersion,
runCompile,
runTest,
tagRelease,
publishArtifacts,
pushChanges,
successSentinel
)) ++
SettingsHelper.makeDeploymentSettings(Universal, packageBin in Universal, "zip")We don't need the first part anymore; i.e., it could be simplified to:
def packageReleaseProcessSettings: Seq[Setting[_]] =
SettingsHelper.makeDeploymentSettings(Universal, packageBin in Universal, "zip")It's worth making a test if we could replace this line in the template:
.settings(IMCEReleasePlugin.packageReleaseProcessSettings)with:
.settings(SettingsHelper.makeDeploymentSettings(Universal, packageBin in Universal, "zip"))2) "artifact.kind" was intended to be a string for classifying the contents of a maven artifact. These strings were intended to correspond to categories of artifacts in a catalogue.
I suggest providing a mechanism for optionally specifying this "artifact.kind". Add the key/value pair only if the "artifact.kind" is specified.
3) The purpose of the template should be explained in the readme, even if briefly. Based on the name, which includes "scala", I presume it involves scala source code in which case Supersafe is definitely relevant regardless of whether the user has a license or not. If the user has a license, then the scala code will be compiled with extra checking enabled (per the supersafe.cfg); if the user doesn't, then the scala code will be compiled with the "community edition" supersafe checks only.
4) Yes. It's a tricky to design templates because there are many kinds of dependencies.
MD is rather special because we need a special kind of dependency to get the actual MD libraries. There are other frameworks that require non-standard dependencies -- e.g. Eclipse. We currently have several Scala projects that use MD APIs so it could help to refactor them to use a common template for Scala + MD APIs.
Even without considering dependencies (MD, Eclipse, ...); another big difference is mono vs. cross compilation. It would be helpful to have a template for scala source code cross-compiled for the JVM & Node JS like this one: https://github.com/JPL-IMCE/gov.nasa.jpl.imce.oml.tables
sjiherzig
Can you please clarify a few items about the build.sbt file? 1. https://github.com/JPL-IMCE/gov.nasa.jpl.imce.templates.scala.g8/blob/master/src/main/g8/build.sbt#L90 What does the packageReleaseProcessSettings do?
2. https://github.com/JPL-IMCE/gov.nasa.jpl.imce.templates.scala.g8/blob/master/src/main/g8/build.sbt#L121 What convention if any should we recommend for the "artifact.kind" value? Are there specific instructions you think we should provide to users for filling in this value?
3. Do we need to include the Supersafe dependency? I fear it may be too restrictive for certain projects. Should we make this an optional component assuming it's possible to do so?
4. Lastly, I propose removing the MagicDraw dependencies as they're not a typical baseline requirement for this starter project. Please let me know if you foresee any problems in removing the MagicDraw setup step from this template.
Thanks, Brian