[jira] [Work logged] (MAHOUT-2086) use consistent SBT resolvable jar naming scheme with the correct convention

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MAHOUT-2086?focusedWorklogId=376402&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-376402 ]

ASF GitHub Bot logged work on MAHOUT-2086:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 23/Jan/20 18:12
            Start Date: 23/Jan/20 18:12
    Worklog Time Spent: 10m 
      Work Description: andrewpalumbo commented on pull request #391: MAHOUT-2086: use consistent SBT resolvable jar naming scheme with the correct convention
URL: https://github.com/apache/mahout/pull/391
 
 
   ### Purpose of PR:
   Please give a short description of what this PR is for.
   
   Fix naming of release artifacts.  using e.g.:
   
   ```
   apache-mahout_${scala.compat.version}-${project-version}-bin
   ```
   
   ### Important ToDos
   Please mark each with an "x"
   - [ x] A JIRA ticket exists (if not, please create this first)[https://issues.apache.org/jira/browse/mahout/]
   - [ x] Title of PR is "MAHOUT-XXXX Brief Description of Changes" where XXXX is the JIRA number.
   - [x ] Created unit tests where appropriate
   - [x ] Added licenses correct on newly added files
   - [ x] Assigned JIRA to self
   - [x ] Added documentation in scala docs/java docs, and to website
   - [ x] Successfully built and ran all unit tests, verified that all tests pass locally.
   
   If all of these things aren't complete, but you still feel it is
   appropriate to open a PR, please add [WIP] after MAHOUT-XXXX before the
   descriptions- e.g. "MAHOUT-XXXX [WIP] Description of Change"
   
   Does this change break earlier versions?
   n
   Is this the beginning of a larger project for which a feature branch should be made?
   n
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 376402)
    Remaining Estimate: 0h
            Time Spent: 10m

> use consistent SBT resolvable jar naming scheme with the correct convention
> ---------------------------------------------------------------------------
>
>                 Key: MAHOUT-2086
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-2086
>             Project: Mahout
>          Issue Type: Bug
>    Affects Versions: 14.1
>            Reporter: Andrew Palumbo
>            Assignee: Andrew Palumbo
>            Priority: Critical
>             Fix For: 14.1
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
>  currently we build jars for each module, module_x, in its respective target directory.. naming that module as
> {code:java}
>  $MAHOUT_HOME/module_x/target/mahout-module-x_${scala.compat.version}-{project.version}.jar.{code}
> and then copy using an ant plugin via the {{pom.xml}} each jar file to the {{/lib}} directory.  [~pferrel]  has had issues resolving via SBT.  
> It seems that our artifacts should be resolvable by SBT e.g, for core math, Scala_2.12, mahout v14.1:
> {code:java}
>  libraryDependencies += "org.apache.mahout" % "mahout-core_2.12" % "14.1"{code}
> Currently we have our Spark build pegged to 2.4.3.
> Had trouble finding A naming convention for artifacts in the Scala docs.  However, this Spark style guide[1], makes the case for:
> {{module-x_scalaVersion-projectVersion.jar}}
>  
> This means that only the distribution artifacts jars need to be changed, If anything.
>  
>  
> h2. JAR Files
> You can build projects that support multiple Spark versions or just a single Spark version.
> h3. Projects that support a single Spark version
> JAR files built for a specific Spark version should be named like this:
>  
> {{spark-testing-base_2.11-2.1.0_0.6.0.jar}}
> Generically:
>  
> {{spark-testing-base_scalaVersion-sparkVersion_projectVersion.jar}}
> {{}}
> If you're using sbt assembly, you can use the following line of code to build a JAR file using the correct naming conventions.
>  assemblyJarName in assembly := s"${name.value}_${scalaBinaryVersion.value}-${sparkVersion.value}_${version.value}.jar"
>  If you're using {{sbt package}}, you can add this code to your {{build.sbt}} file to generate a JAR file that follows the naming conventions.
>  artifactName :=
> { (sv: ScalaVersion, module: ModuleID, artifact: Artifact) => artifact.name + "_" + sv.binary + "-" + sparkVersion.value + "_" + module.revision + "." + artifact.extension }
> h3. Projects that support multiple Spark versions
> JAR files built for multiple Spark version should be named like this:
> {{spark-testing-base_2.11-0.6.0.jar}}
> Generically:
> {{spark-testing-base_scalaVersion-projectVersion.jar}}
> {{}}
> If you're using sbt assembly, you can use the following line of code to build a JAR file using the correct naming conventions.
>  assemblyJarName in assembly := s"${name.value}_${scalaBinaryVersion.value}-${version.value}.jar"
>  If you're using {{sbt package}}, you can add this code to your {{build.sbt}} file to generate a JAR file that follows the naming conventions.
>  artifactName :=
> { (sv: ScalaVersion, module: ModuleID, artifact: Artifact) => artifact.name + "_" + sv.binary + "-" + module.revision + "." + artifact.extension }
>  
>  
> [[1] https://github.com/mrpowers/spark-style-guide|https://github.com/mrpowers/spark-style-guide]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)