I am trying to use the babel webjar plugin in my project that is built with playframework 2.5, which basically runs sbt to build the project.
When I put
addSbtPlugin("org.webjars" %% "babel" % "6.3.26-1" )
in project/plugins.sbt, I get this error:
[info] Resolving org.webjars#babel;6.3.26-1 ...
[warn] module not found: org.webjars#babel;6.3.26-1
<trying other repositories>
[warn] https://repo1.maven.org/maven2/org/webjars/babel_2.10_0.13/6.3.26-1/babel-6.3.26-1.pom
The pom file is located at http://repo1.maven.org/maven2/org/webjars/babel/6.3.26-1/babel-6.3.26-1.pom. This is almost the address that sbt tried, but sbt added the scala version.
Is there a way to tell sbt to not add the scala version? I tried this version and a single percent sign, and both of them added the scala version.
I am using sbt 0.13.9.
Related
Maven provides a plugin (versions-maven-plugin) that allows to retrieve the latest available versions for all the dependencies of a project.
However, the result is polluted by dependencies when their naming scheme has evolved over time.
Perfect example of this is commons-beanutils. I get this result in Maven:
[INFO] --- versions-maven-plugin:2.5:display-dependency-updates (default-cli) # dataimport ---
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] commons-beanutils:commons-beanutils ......... 1.9.3 -> 20030211.134440
The real last version (as of this writing) is 1.9.3, but back in 2003, version number was based on a timestamp.
Is there a workaround that would allow the Maven plugin to get the real last version? By ignoring a range of versions?
Until I find a solution, I can't reasonably use the Maven feature allowing to automatically update all dependencies.
Googling about this problem, it looks like no one complains about it - and as a result the version 20030211.134440 is still heavily used while quite old.
You can use parameter rulesUrl to pass to this plugin path to file with rules of version comparision.
See http://www.mojohaus.org/versions-maven-plugin/use-latest-versions-mojo.html#rulesUri .
Format of this file you can see there: http://www.mojohaus.org/versions-maven-plugin/rule.html .
While running sbt assembly, the command runs for some time and throws the following error on Windows 7:
[warn] Strategy 'discard' was applied to 4 files
[warn] Strategy 'first' was applied to 199 files
[info] Assembly up to date: C:\spark_\spark-1.0.2\assembly\target\scala-2.10\spark-assembly-1.0.2-hadoop1.0.4.jar
sbt.ResolveException: download failed: javax.xml.stream#stax-api;1.0-2!stax-api.jar
at sbt.IvyActions$.sbt$IvyActions$$resolve(IvyActions.scala:217)
at sbt.IvyActions$$anonfun$update$1.apply(IvyActions.scala:126)
Any ideas on how to solve this?
In the official documentation of Apache Spark there's the section Downloading that says:
If you’d like to build Spark from scratch, visit building Spark with Maven.
where you can find the command that worked fine for me (just two days ago on Mac OS X with Java 8):
mvn -Pyarn -Phadoop-2.4 -Dhadoop.version=2.4.0 -DskipTests clean package
p.s. I wish they'd sticked to sbt as the build tool for official releases, though.
running sbt clean before sbt assembly solved the above problem.
I'm trying to make a Jenkins plugin that uses a library that requires spring-core 3.2.2 (cloudfoundry-client-lib). I simply used the mvn command to create a skeleton plugin, then added my Maven dependency to pom.xml and a few simple code lines that uses the library. I'm not getting any problem running the skeleton plugin without my dependency.
Upon compiling with "mvn package", I'm getting a test error:
WARNING: Failed to scout hudson.security.PAMSecurityRealm
java.lang.InstantiationException: java.lang.NoClassDefFoundError: org/springframework/core/env/EnvironmentCapable
Looks like this is a class that appeared in spring-core 3.1.0. So I looked at the Maven dependency tree:
[INFO] --- maven-dependency-plugin:2.3:tree (default-cli) # stackato-jenkins ---
[INFO] org.wiwiweb:cf-test-jenkins:hpi:1.0-SNAPSHOT
[INFO] \- org.cloudfoundry:cloudfoundry-client-lib:jar:1.0.2:compile
[INFO] \- org.springframework:spring-webmvc:jar:3.2.2.RELEASE:compile
[INFO] \- org.springframework:spring-core:jar:2.5.6.SEC03:compile
So Maven tells me it's using spring-core 2.5.6 because of spring-webmvc 3.2.2? This is strange because, looking online, spring-webmvc 3.2.2 depends on spring-core 3.2.2. Looking at the verbose version of the tree, looks like jenkins-core depends on spring-core 2.5.6... This makes me suspicious that the problem is from Jenkins.
Anyway, if it's just a version conflict, then overriding Maven's decision by explicitly saying I want spring-core 3.2.2 in my pom.xml should solve the problem, right?
I did this, then did not get a compile error. Problem solved!... not.
In runtime, after activating this plugin in Jenkins and running a build with this, as soon as the code runs into a line that uses the library I added, the Jenkins output tells me this:
FATAL: org.springframework.util.CollectionUtils.unmodifiableMultiValueMap(Lorg/springframework/util/MultiValueMap;)Lorg/springframework/util/MultiValueMap;
java.lang.NoSuchMethodError: org.springframework.util.CollectionUtils.unmodifiableMultiValueMap(Lorg/springframework/util/MultiValueMap;)Lorg/springframework/util/MultiValueMap;
UnmodifiableMultiValueMap() is a method that was added in spring-core 3.1, so this means Jenkins is still trying to run my plugin with the old version of spring-core, even though I explicitly said I wanted the newest one in my plugin's pom.xml!
So I'm stuck on this. I'm not even sure if it's a Maven or a Jenkins issue. I'll sum up the whole thing in two questions:
Why is Maven not compiling the plugin with a correct version of spring-core unless I explicitly tell him to? It should be able to follow dependencies without me giving it hints.
Why is Jenkins running my plugin with an older version of spring-core than the one it was compiled with, and how can I make it use the correct one?
If you're picking up dependencies from the Jenkins install rather than from your plugin the solution is actual quite easy to implement. Per the Jenkins documentation, simply add the maven-hpi-plugin to the build in the pom.xml of your Jenkins plugin and set it to load the plugin classes first:
<build>
<plugins>
<plugin>
<groupId>org.jenkins-ci.tools</groupId>
<artifactId>maven-hpi-plugin</artifactId>
<configuration>
<pluginFirstClassLoader>true</pluginFirstClassLoader>
</configuration>
</plugin>
</plugins>
</build>
Try to "shade" the CF client lib using the Maven Shade plugin, as it seems Jenkins doesn't like plugins that are using a different version of Spring than the one it uses internally itself.
Even if your own plugin doesn't use Spring directly, but the CF library does, I believe this still applies. The person that suggested shading in the jenkinsci-dev mailing list seems to be involved in Jenkins plugins development, so he might know about this more than others.
These being said, I would get the source code for cf-client-lib, I would change the pom.xml to consider shading for org.springframework package, as well (because cf-client-lib already uses shading for org.codehaus.jackson package) and I would use this "shaded" version of cf-client-lib in the Jenkins plugin.
I have multiple apps and inline plugins I want to be all next to each other so in IntelliJ I can have them all open at once and edit anything in any of them, refactoring work across all of them, etc.
And I want to have a top level build that will build everything.
I'm using grails 2.2.4 and maven
I looked at create-multi-project-build and all manner of links that talked about it but can't get it to work with the inline plugin. When it gets to building the app, for some reason it tries to compile the plugin files and gets lots of compile errors because it is not seeing the plugin's dependencies.
NOTE: Apparently the plugin pom.xml doesn't have the dependencies. So, is there a bug, or am I doing something wrong that would make it not find dependencies?
[INFO] --- grails-maven-plugin:2.2.4:maven-compile (default-maven-compile) # my-app ---
|Loading Grails 2.2.4
|Configuring classpath
|Running pre-compiled script
.
|Environment set to development
......Warning
|
No plugin [my-plugin-0.1-SNAPSHOT] installed, cannot uninstall
....
|Compiling 132 source files
.Error
|
Compilation error: startup failed:
Compile error during compilation with javac.
/path/to/file/in/my-plugin:3: package groovyx.net.http does not exist
import groovyx.net.http.AsyncHTTPBuilder;
^
etc. (lots more of the same kind of errors)
Is there some way to get this to work? If this maven build is the only option, I'd really like a solution that does not require manually editing the pom's. That way I can just regenerate them whenever I need to update the build.
Are there other straightforward options to creating a multi-module build for this case?
Further detail:
Running grails test-app in the plugin or in the app work successfully.
My Play/SBT project needs to depend on a third-party Java library that is distributed in source form and can be built with either Ant or Maven. Its root directory contains pom.xml and build.xml.
I am thinking of having this library added as a git submodule and have SBT build it as a subproject. I tried adding
externalPom(baseDirectory(_ / "pathToLibrary" / "pom.xml"))
to my build settings, but I ended up with the following compiler error:
[info] Compiling 32 Scala sources and 5 Java sources to /home/thesamet/project]
[error] (compile:compile) scala.reflect.internal.MissingRequirementError: object scala.runtime in compiler mirror not found.
[error] Total time: 1 s, completed Aug 23, 2013 11:46:20 AM
An external pom can only be used to obtain library dependencies of the maven project but not compile it.
You can add an sbt build configuration for the external project or easier, you can publish the third-party module to a corporate Maven or Ivy repository or just local with mvn install and add ~/.m2 as file resolver to your SBT project.