I have scala mvn project. Version of scala was 2.12.3 and scoverage-maven-plugin. 1.3.0 After updating scala version from 2.12.3 to 2.12.13 I have got an error
[ERROR] error: java.lang.NoSuchMethodError: scala.tools.nsc.Global.reporter()Lscala/tools/nsc/reporters/Reporter;
By looking at https://github.com/scoverage/sbt-scoverage/issues/321 and related commits it seems like using scalac-scoverage v1.4.3 would fix it, so I tried to force it to use a different one like this:
<plugin>
<groupId>org.scoverage</groupId>
<artifactId>scoverage-maven-plugin</artifactId>
<version>${scoverage.plugin.version}</version>
<configuration>
<scalaVersion>2.12.13</scalaVersion>
<scalacPluginVersion>1.4.3</scalacPluginVersion>
</configuration>
</plugin>
but I've got a new error:
Failure to find org.scoverage:scalac-scoverage-plugin_2.12:jar:1.4.3 in http://repo.mal.internal/content/groups/public was cached in the local rep
ository, resolution will not be reattempted until the update interval of internal.mirror has elapsed or updates are forced
but scalaVersion param accept only 2.10 or 2.11 or 2.13. How I can fix this error?
According to the maven repo page for now there is not 1.4.3 version for the scoverage-maven-plugin:
In the mentioned issue they use a different plugin: scalac-scoverage-plugin.
Related
This may be an old question but is still pending a solution. The entire question stemmed from a small detail in the development of Apache Spark, one of the largest open source project in history.
During the delivery and release of Spark 1.x and 2.x. A key library dependency (Apache Hive 1.x) was found to have introduced too many obsolete transitive dependencies, and prone to cause conflict if deployed with YARN/HDFS. Realising that the team won't have enough resource to enforce the mono-repo principal (namely, ensuring that each library in the dependency tree can only have 1 version), a hard fork of Apache Hive was made, compiled and published:
https://github.com/JoshRosen/hive
https://mvnrepository.com/artifact/org.spark-project.hive/hive-common/1.2.1.spark2
It's only difference with the official Apache Hive is that all source code references to the package "org.apache.hive" was replaced with "org.spark-project.hive".
This is obviously a lousy way of using another project: the new code won't keep up with the development of Apache Hive community, or mundane, repetitive works are required to keep it up to date. This also introduces dangerous exploits where an unsigned jar could be used to swap out the migrated jar (also unsigned) in an Apache Spark installation. As a result, after Spark 3.0 the migrated project was discontinued: With enough resources, the new original Apache Hive 2.x was introduced with most obsolete dependencies upgraded.
One would hope that after 5 years of the release of Apache Spark 2.0, such process should be largely automated by the improvement of all the compilation tools and plugins. Specifically, 2 plugins (maven shade plugin and gradle shadow plugin) are specifically designed for relocation of packages in dependencies, and can be used to generate the migrated bytecode of Apache Hive directly from the canonical Hive. But a quick experiment quickly revealed that none of them can accomplish such a simple task:
https://github.com/tribbloid/autoshade
This project contains 2 subprojects that only exist for repacking, one written in maven and another in gradle.
The maven subproject uses maven shade plugin to relocate json4s into repacked.test1.org.json4s:
<dependencies>
<dependency>
<groupId>org.json4s</groupId>
<artifactId>json4s-jackson_${vs.scalaBinaryV}</artifactId>
<version>4.0.4</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<!-- <createSourcesJar>true</createSourcesJar>-->
<createDependencyReducedPom>true</createDependencyReducedPom>
<dependencyReducedPomLocation>${project.build.directory}/dependency-reduced-pom.xml</dependencyReducedPomLocation>
<!-- <generateUniqueDependencyReducedPom>true</generateUniqueDependencyReducedPom>-->
<keepDependenciesWithProvidedScope>false</keepDependenciesWithProvidedScope>
<promoteTransitiveDependencies>false</promoteTransitiveDependencies>
<!-- <shadedClassifierName>${spark.classifier}</shadedClassifierName>-->
<relocations>
<relocation>
<pattern>org.json4s</pattern>
<shadedPattern>repacked.test1.org.json4s</shadedPattern>
</relocation>
</relocations>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The gradle project uses shadow plugin to relocate json4s into repacked.test2.org.json4s:
dependencies {
api("org.json4s:json4s-jackson_${vs.scalaBinaryV}:4.0.4")
}
tasks {
shadowJar {
exclude("META-INF/*.SF")
exclude("META-INF/*.DSA")
relocate("org.json4s", "repacked.test2.org.json4s")
}
}
After that, a third project (in gradle, but it doesn't matter) declared both as dependencies and use Scala to access the new relocated class:
dependencies {
api(project(":repack:gradle", configuration = "shadow"))
api("com.tribbloids.autoshade:repack-maven:0.0.1")
}
class Json4sTest {
classOf[test1.org.json4s.Formats]
classOf[test2.org.json4s.Formats]
}
Surprisingly, it cannot be compiled:
[Error] /home/peng/git-proto/autoshade/main/src/main/scala/com/tribbloids/spookystuff/Json4sTest.scala:7:11: Symbol 'term org.json4s' is missing from the classpath.
This symbol is required by ' <none>'.
Make sure that term json4s is in your classpath and check for conflicting dependencies with `-Ylog-classpath`.
A full rebuild may help if 'package.class' was compiled against an incompatible version of org.
[Error] /home/peng/git-proto/autoshade/main/src/main/scala/com/tribbloids/spookystuff/Json4sTest.scala:7:28: type Formats is not a member of package repacked.test1.org.json4s
[Error] /home/peng/git-proto/autoshade/main/src/main/scala/com/tribbloids/spookystuff/Json4sTest.scala:10:11: Symbol 'term org.json4s' is missing from the classpath.
This symbol is required by ' <none>'.
Make sure that term json4s is in your classpath and check for conflicting dependencies with `-Ylog-classpath`.
A full rebuild may help if 'package.class' was compiled against an incompatible version of org.
[Error] /home/peng/git-proto/autoshade/main/src/main/scala/com/tribbloids/spookystuff/Json4sTest.scala:10:28: type Formats is not a member of package repacked.test2.org.json4s
The 1st and 3rd error messages will not appear if referring to a non-existing class, it can be speculated that the package migration was incomplete and inconsistent, completely useless comparing to a manual migration of source code that the Apache Spark team did before.
So why is it so hard for such a simple task to be automated? What extra steps are required in either maven or gradle to make it work?
At this moment (Oct 13 2022), the only working solution is through sbt. The following built file is used in https://github.com/tribbloid/autoshade/blob/main/repack/sbt/build.sbt, which called AssemblyPlugin to publish a shaded assembly jar:
project
.in(file("."))
.settings(commonSettings)
.settings(
scalacOptions += "-Ymacro-annotations",
libraryDependencies ++= Seq(
"org.json4s" %% "json4s-jackson" % "4.0.4"
),
addArtifact(
Artifact("repack-sbt", "assembly"),
sbtassembly.AssemblyKeys.assembly
),
ThisBuild / assemblyMergeStrategy := {
case PathList("module-info.class") => MergeStrategy.discard
case x if x.endsWith("/module-info.class") => MergeStrategy.discard
case x =>
val oldStrategy = (ThisBuild / assemblyMergeStrategy).value
oldStrategy(x)
},
artifact in (Compile, assembly) := {
val art = (artifact in (Compile, assembly)).value
art.withClassifier(Some("assembly"))
},
ThisBuild / assemblyJarName := {
s"${name.value}-${scalaBinaryVersion.value}-${version.value}-assembly.jar"
},
ThisBuild / assemblyShadeRules := Seq(
ShadeRule.rename("org.json4s.**" -> "repacked.test3.org.json4s.#1").inAll
)
)
.enablePlugins(AssemblyPlugin)
after publishing:
sbt "clean;publishM2"
...
[success] Total time: 0 s, completed Oct. 13, 2022, 4:19:49 p.m.
[info] Wrote /home/peng/git-proto/autoshade/repack/sbt/target/scala-2.13/repack-sbt_2.13-0.0.1-SNAPSHOT.pom
[info] Strategy 'discard' was applied to 9 files (Run the task at debug level to see details)
[info] Strategy 'rename' was applied to 4 files (Run the task at debug level to see details)
[info] published repack-sbt_2.13 to file:/home/peng/.m2/repository/com/tribbloids/autoshade/repack-sbt_2.13/0.0.1-SNAPSHOT/repack-sbt_2.13-0.0.1-SNAPSHOT-sources.jar
[info] published repack-sbt_2.13 to file:/home/peng/.m2/repository/com/tribbloids/autoshade/repack-sbt_2.13/0.0.1-SNAPSHOT/repack-sbt_2.13-0.0.1-SNAPSHOT-javadoc.jar
[info] published repack-sbt_2.13 to file:/home/peng/.m2/repository/com/tribbloids/autoshade/repack-sbt_2.13/0.0.1-SNAPSHOT/repack-sbt_2.13-0.0.1-SNAPSHOT.jar
[info] published repack-sbt_2.13 to file:/home/peng/.m2/repository/com/tribbloids/autoshade/repack-sbt_2.13/0.0.1-SNAPSHOT/repack-sbt_2.13-0.0.1-SNAPSHOT.pom
[info] published repack-sbt_2.13 to file:/home/peng/.m2/repository/com/tribbloids/autoshade/repack-sbt_2.13/0.0.1-SNAPSHOT/repack-sbt_2.13-0.0.1-SNAPSHOT-assembly.jar
[success] Total time: 3 s, completed Oct. 13, 2022, 4:19:53 p.m.
...
Any class in the assembly jar can be referred within the new repackage repacked.test3.org.json4s.
It is yet to know which part of the sbt plugin did correctly to make it possible. Once it has been figured out, the same subroutine should ideally be ported to maven-shade-plugin and gradle-shadow-plugin respectively
Migrating Drools from 6.5.0.Final to Drools 7.36.1.Final , I am facing issue in resolving org.kie:kie-maven-plugin:7.36.0.Final dependency issue as below
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin org.kie:kie-maven-plugin:7.36.0.Final or one of its dependencies could not be resolved: The following artifacts could not be resolved: xmlpull:xmlpull:jar:1.2.0, xpp3:xpp3_min:jar:1.2.0: Could not find artifact xmlpull:xmlpull:jar:1.2.0
POM entry
<plugin>
<groupId>org.kie</groupId>
<artifactId>kie-maven-plugin</artifactId>
<version>7.36.1.Final</version>
<extensions>true</extensions>
</plugin>
Hi same problem with versions higher than 7.31.
Since they changed the dependencies in kie-parent.pom
from
<version.xmlpull>1.1.3.1</version.xmlpull>
<version.xmlunit>1.3</version.xmlunit>
<version.xpp3>1.1.4c</version.xpp3>
to
<version.xmlpull>1.2.0</version.xmlpull>
<version.xmlunit>1.3</version.xmlunit>
<version.xpp3>${version.xmlpull}</version.xpp3>
I try lot of tricks and can't solve the problem yet.
1.2.0 it's an ea version located in https://repository.jboss.org/nexus/content/repositories/ea/.
It can be found at: https://mvnrepository.com/artifact/xmlpull/xmlpull/1.2.0. I have no clue why it is not listed here: https://mvnrepository.com/artifact/xmlpull/xmlpull so maven can resolve it.
you can download it and put it into your local m2 repository or into your company maven repository like nexus or artifactory.
You need to add one of those repo-s in your build, so maven can find it:
https://mvnrepository.com/repos/jboss-ea
https://mvnrepository.com/repos/jboss-thirdparty-releases
On building my workspace, my Java 6 Maven project is marked with an error (a Maven problem):
Could not calculate build plan: The repository system is offline but the artifact org.apache.maven.surefire:surefire:pom:2.7.1 is not available in the local repository.
What strikes me as odd is that it is searching for org.apache.maven.surefire:surefire while the true dependency is org.apache.maven.surefire:maven-surefire-plugin.
My effective pom is showing:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.1</version>
<executions>
I'm using Eclipse Indigo with the m2eclipse plugin. And it compiles correctly when running any Maven goal. I tried cleaning the project, reimporting it, clearing the .metadata file.
Where does this behavior come from? Thanks
The mentioned dependency is the parent project for the maven-surefire-plugin and should usually not given directly only via the maven-surefire-plugin itself.
Furthermore What strikes me as odd is that it is searching for org.apache.maven.surefire:surefire while the true dependency is org.apache.maven.surefire:maven-surefire-plugin. which is simply wrong, cause the correct groupId and artifactId for the maven-surefire-plugin is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
...
</plugin>
It could be possible having problems while accessing maven central. Apart from the above you should update the maven-surefire-plugin cause the current up-to-date version is 2.15.
I am trying to use fsc (fast scala compiler) with my maven project. My pom.xml has:
...
<execution>
<id>cc</id>
<goals>
<goal>cc</goal>
</goals>
<phase>compile</phase>
<configuration>
<useFsc>true</useFsc>
<once>true</once>
</configuration>
</execution>
...
as discussed in What is the fastest way to compile Scala files using maven?
When I type mvn scala:cc, it hangs on:
[INFO] wait for files to compile...
Running mvn scala:cc -DdisplayCmd=true -Dverbose=true
[INFO] cmd: /bin/sh -c .../java -classpath [redacted] scala.tools.nsc.MainGenericRunner scala.tools.nsc.CompileServer >MainGenericRunner.out 2>MainGenericRunner.err
Which seems odd (shouldn't it not include scala.tools.nsc.MainGenericRunner?) I noticed that MainGenericRunner.out contains
no such file: scala.tools.nsc.CompileServer
which seems to confirm my suspicion.
Has anyone encountered this, or have a work around? I'd really like to use fsc to speed up my builds. I found one user with a similar output on google groups, but no follow ups.
Running scala 2.8.1 and maven 3.0.3 on OSX
When you invoke mvn scala:cc maven will use execution id default-cli (or something similar) which is not configured in your pom. Because of that maven will be using defaults of cc goal. Currently your pom is configured to execute cc goal with your customizations during "compile" phase. So, running something like mvn compile or mvn install should be working as you expect.
I'm using embedded jetty server to build a war, I ran maven clean through eclipse, then maven install. I get a bunch of "not supported" errors
\RoleDao.java:[86,13] generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
public List<Role> findAllRoles()
UserAuth.java:[44,1] annotations are not supported in -source 1.3
(use -source 5 or higher to enable annotations)
#SuppressWarnings("deprecation")
Anyone have an idea? Thanks
The error message states that you are defining language level of 1.3. This is the default of older versions of the Maven Compiler Plugin like 2.0. Upgrade to a newer version like 2.3.2 or even the latest 2.5.1 and the default will be 1.5 and it should work just fine.
And while you are at it also upgrade to the latest version of Maven (3.0.4) so that these newer versions of the Maven Compiler Plugin are the default.
This is problem with defaults as Manfred pointed. To get rid of this nasty error you can upgrade maven version, maven-compiler-plugin version or configure version in you pom.xml
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.5</source>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
value from source is then passed to compiler as -source argument, to ind out what values are accepted, check this page javac and search for -source release