I have a github repo that I created a Release for. While creating the release I manually added a .jar file. Lets call it exampleLibrary.jar
This would be github.com/MyExampleRepo/Releases
I have a project I want to add a dependency for to use this exampleLibrary.jar file I added in my release v1.0
This project using Ivy.xml for resolving dependencies.
To get the jar from github using maven with pom.xml I imagine it would look something like this:
<dependency>
<groupId>com.github.User</groupId>
<artifactId>Repo name</artifactId>
<version>Release tag</version>
</dependency>
How would I do this using Ivy.xml? This is what I have tried:
<dependency org="com.github" name="MyExampleRepo" rev="v1.0"/>
According to Oracle documentation the schemagen tool is removed from the JDK as part of JEP 320 (http://openjdk.java.net/jeps/320).
That JEP points to Maven artifacts that now supply the missing tools. The coordinates of the artifacts are wrong in the JEP, updated coordinates are found in an answer to this question:
Which artifacts should I use for JAXB RI in my Maven project?
What is missing however is how to invoke the tools. There are shell scripts pointed to in the JEP that are in the JAXB-RI Git repository. However those scripts remain undocumented and difficult to invoke. The build instructions in that git repo indicated it is built with a standard "mvn clean install", however that does not produce an output structure that matches the 'bin' folder used in the documentation here: https://javaee.github.io/jaxb-v2/doc/user-guide/ch04.html#tools-schemagen
Ideally I would like to run schemagen from Gradle, avoiding the shell scripts as they are not obtained from the maven dependency.
My current attempt, adapted from a working version that called the old schemagen.exe, looks like this:
(There is more in the 'real' build.gradle file to specify my application's dependencies, etc.)
configurations {
schemagenTool
}
dependencies {
schemagenTool "org.glassfish.jaxb:jaxb-jxc:${jaxbVersion}"
}
task schemaGen(type: Exec, dependsOn: [compileJava,configurations.schemaGenTool]) {
workingDir projectDir
executable 'java'
doFirst {
file('build/Schemas').mkdirs()
args '--module-path', "${configurations.schemaGenTool.asPath}",
'-m', 'jaxb.jxc/com.sun.tools.jxc.SchemaGeneratorFacade',
// Note: automatic module name is NOT com.sun.tool.jxc
// as documented
// Args to schemagen (these worked for the schemagen.exe)
'-d', 'build/Schemas',
'-classpath', "${compileJava.destinationDir}${File.pathSeparator}${configurations.compile.asPath}",
"src/main/java/path/to/my/ModelClass.java"
//println "\nschemagen: ${args.join(' ')}\n"
}
doLast {
// Above creates "build/Schemas/schema1.xsd" (despite printing a different path!)
// Rename it
def destFile = file('build/Schemas/model.xsd')
destFile.delete()
if (!file('build/Schemas/schema1.xsd').renameTo(destFile)) {
throw new GradleException("Failed to write new build/Schemas/model.xsd")
}
}
}
However, that results in an error:
Error occurred during initialization of boot layer
java.lang.module.ResolutionException: Modules jaxb.runtime and jaxb.core export package com.sun.xml.bind.marshaller to module relaxngDatatype
The issue seems to be known with the jaxb-*:2.3.0 version - #jaxb-v2/issues/1168. Additionally, this would be resolved with a future release as marked in the known issues of jaxb running over java-9.
You can resolve this following the comment -
Please try 2.4.0-b180725.0644 - this is JPMS modularized RI working on
JDKs with java.xml.bind module (9,10) and those without it (11-ea)
or try downloading the binary distribution from the same link.
Schemagen and xjc shell scripts are only put into binary distribution in ./bin directory.
For build tools there are plugins out there (Maven / Gradle) which does invoke schemagen and xjc APIs, providing user with simple configuration.
Your attempt to invoke com.sun.tools.jxc.SchemaGeneratorFacade manually is also correct, here is similar example for Maven. However you are probably putting 2.3.0 on module path, which has a split package problem. Putting on classpath will resolve the issue for 2.3.0. Next release of JAXB will be JPMS ready and have module descriptors declared. You can try the beta build (2.4.0-b180725.0644), here is a correct set of dependencies:
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId> <!--jaxb runtime-->
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-xjc</artifactId> <!--java generation-->
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-jxc</artifactId> <!--schema generation-->
</dependency>
If trying to use the schemagen in the jaxb-ri download directly, note the JAXB_PATH in schemagen.bat is inconsistent with the mod directory in the jaxb-ri.zip file.
E.g. to use schemagen.bat:
As at now, download jaxb-ri-2.3.1.zip from https://maven.java.net/content/repositories/releases/com/sun/xml/bind/jaxb-ri/2.3.1/ (the 2.4.0-betas also had the mod/javax.activation-api.jar missing)
Use these steps to run schemagen.bat, setting JAXB_HOME as appropriate:
set JAXB_HOME=C:\Java\jaxb-ri-2.3.1
set CLASSPATH=%JAXB_HOME%/mod/relaxng-datatype.jar;%JAXB_HOME%/mod/javax.activation-api.jar
%JAXB_HOME%\bin\schemagen.bat -cp myjar1.jar;myjar2.jar -d target com.company.ClassName1 com.company.ClassName2
(This was against JDK 11)
I have a multi-module maven project with three modules core, utils and test-utils
Core has the following dependencies definition
<dependency>
<groupId>my.project</groupId>
<artifactId>utils</artifactId>
</dependency>
<dependency>
<groupId>my.project</groupId>
<artifactId>test-utils</artifactId>
<scope>test</scope>
</dependency>
I have added Java 9 module-info.java definitions for all three modules and core's looks like this:
module my.project.core {
requires my.project.utils;
}
However I cannot figure out how to get core's test classes to be able to see the test-utils classes during test execution. When maven-surefire-plugin attempts the test run I get class not found.
If I add a requires my.project.testutils; to core's module-info.java:
module my.project.core {
requires my.project.utils;
requires my.project.testutils; //test dependency
}
Then at compile time I get an error that the my.project.testutils module can't be found (presumably because it's only brought in as a test dependency).
How does one work with test dependencies in a Java 9 modular world? For obvious reason's I don't want my main code to pull in test dependencies. Am I missing something?
With maven and java9, if your my.project.testutils is a test scope dependency, you don't need to explicitly include(requires) it in the module descriptor.
The test dependencies are taken care via the classpath itself. So you can simply remove the testutils and it would be patched by maven while executing tests.
module my.project.core {
requires my.project.utils;
}
Refer to the slide 30 pertaining to maven-compiler-plugin.
I would also suggest you take a look at Where should I put unit tests when migrating a Java 8 project to Jigsaw and this comment by Robert confirming on the implementation that maven follows.
Edit: Created a sample project drawing an analogy that the main module is same as your core, the dependency on guava is same as your utils and the junit dependency is same as your testutils.
I am trying to build a simple Java project with Maven. In my pom-file I declare JUnit 4.8.2 as the only dependency. Still Maven insists on using JUnit version 3.8.1. How do I fix it?
The problem manifests itself in a compilation failure: "package org.junit does not exist". This is because of the import statement in my source code. The correct package name in JUnit 4.* is org.junit.* while in version 3.* it is junit.framework.*
I think I have found documentation on the root of the problem on http://maven.apache.org/plugins/maven-surefire-plugin/examples/junit.html but the advice there seems to be meant for Maven experts. I did not understand what to do.
Just to have an answer with the complete solution to help the visitors:
All you need to do is add the junit dependency to pom.xml. Don't forget the <scope>test</scope>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
#Dennis Roberts: You were absolutely right: My test class was located in src/main/java. Also the value of the "scope" element in the POM for JUnit was "test", although that is how it is supposed to be. The problem was that I had been sloppy when creating the test class in Eclipse, resulting in it being created in src/main/java insted of src/test/java. This became easier to see in Eclipse's Project Explorer view after running "mvn eclipse:eclipse", but your comment was what made me see it first. Thanks.
my problem was a line inside my pom.xml i had the line <sourceDirectory>${basedir}/src</sourceDirectory> removing this line made maven use regular structure folders which solves my issue
removing the scope tag in pom.xml for junit worked..
I had the same problem. All i did was - From the pom.xml file i deleted the dependency for junit 3.8 and added a new dependency for junit 4.8. Then i did maven clean and maven install. It did the trick. To verify , after maven install i went project->properties-build path->maven dependencies and saw that now the junit 3.8 jar is gone !, instead junit 4.8 jar is listed. cool!!. Now my test runs like a charm.. Hope this helps somehow..
Add this dependency to your pom.xml file:
http://mvnrepository.com/artifact/junit/junit-dep/4.8.2
<!-- https://mvnrepository.com/artifact/junit/junit-dep -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit-dep</artifactId>
<version>4.8.2</version>
</dependency>
I had my files at the correct places, and just removing <scope>test</scope> from the JUnit dependency entry solved the problem (I am using JUnit 4.12). I believe that with the test scope the dependency was just being ignored during the compilation phase. Now everything is working even when I call mvn test.
My case was a simple oversight.
I put the JUnit dependency declaration inside <dependencies> under the <dependencyManagement/> node instead of <project/> in the POM file. Correct way is:
<project>
<!-- Other elements -->
<dependencies>
<!-- Other dependencies-->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
</dependencies>
<project>
I had a quite similar problem in a "test-utils" project (adding features, rules and assertions to JUnit) child of a parent project injecting dependencies.
The class depending on the org.junit.rules package was in src/main/java.
So I added a dependency on junit without test scope and it solved the problem :
pom.xml of the test-util project :
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
pom.xml of the parent project :
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
How did you declare the version?
<version>4.8.2</version>
Be aware of the meaning from this declaration explained here (see NOTES):
When declaring a "normal" version such as 3.8.2 for Junit, internally this is represented as "allow anything, but prefer 3.8.2." This means that when a conflict is detected, Maven is allowed to use the conflict algorithms to choose the best version. If you specify [3.8.2], it means that only 3.8.2 will be used and nothing else.
To force using the version 4.8.2 try
<version>[4.8.2]</version>
As you do not have any other dependencies in your project there shouldn't be any conflicts that cause your problem. The first declaration should work for you if you are able to get this version from a repository. Do you inherit dependencies from a parent pom?
Me too had the same problem as shown below.
To resolve the issue, below lines are added to dependencies section in the app level build.gradle.
compile 'junit:junit:4.12'
androidTestCompile 'com.android.support.test:runner:0.5'
Gradle build then reported following warning.
Warning:Conflict with dependency 'com.android.support:support-annotations'.
Resolved versions for app (25.1.0) and test app (23.1.1) differ.
See http://g.co/androidstudio/app-test-app-conflict for details.
To solve this warning, following section is added to the app level build.gradle.
configurations.all {
resolutionStrategy {
force 'com.android.support:support-annotations:23.1.1'
}
}
I had a similar problem of Eclipse compiling my code just fine but Maven failed when compiling the tests every time despite the fact JUnit was in my list of dependencies and the tests were in /src/test/java/.
In my case, I had the wrong version of JUnit in my list of dependencies. I wrote JUnit4 tests (with annotations) but had JUnit 3.8.x as my dependency. Between version 3.8.x and 4 of JUnit they changed the package name from junit.framework to org.junit which is why Maven still breaks compiling using a JUnit jar.
I'm still not entirely sure why Eclipse successfully compiled. It must have its own copy of JUnit4 somewhere in the classpath. Hope this alternative solution is useful to people. I reached this solution after following Arthur's link above.
I also ran into this issue - I was trying to pull in an object from a source and it was working in the test code but not the src code. To further test, I copied a block of code from the test and dropped it into the src code, then immediately removed the JUnit lines so I just had how the test was pulling in the object. Then suddenly my code wouldn't compile.
The issue was that when I dropped the code in, Eclipse helpfully resolved all the classes so I had JUnit calls coming from my src code, which was not proper. I should have noticed the warnings at the top about unused imports, but I neglected to see them.
Once I removed the unused JUnit imports in my src file, it all worked beautifully.
Find the one solution for this error if you have code in src/main/java Utils
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<version>3.9.1</version>
</dependency>
Changing the junit version fixed this for me. Seems like version 3.8.1 didn't work in my case. Issue fixed upon changing it to 4.12
I met this problem, this is how I soloved it:
Context:
SpringBoot application
Use maven to manage multiple modules
Add junit's maven dependency in root POM's dependencyManagement(rather than dependencies, their differences can be found here)
Intend to test class or folder inside one of the root module's child module
PS: If your situation does not match the context above, this solution may not solve your problem.
Steps
right click at the class or folder you want to test:
Choose More Run/Debug -> Modify Run Configuration
Change the module option to the one you want to test from root module
By default , maven looks at these folders for java and test classes respectively -
src/main/java and src/test/java
When the src is specified with the test classes under source and the scope for junit dependency in pom.xml is mentioned as test - org.unit will not be found by maven.
I have a library i share on jcenter for maven and gradle users to add to their dependencies. This library uses some common stuff like gson, guava, etc. It is part of a large multi-module project but i only deploy the one child module to the repositories. The complete parent pom.xml is here:
https://github.com/bsautner/com.nimbits/blob/master/pom.xml
The child pom that results in the library's pom is here:
https://github.com/bsautner/com.nimbits/blob/master/nimbits_io/pom.xml
The child pom has dependencies like this:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
Pretty standard. When I import my library into an android project (gradle in this case) I need to include a transitive=false like this:
compile ('com.nimbits:nimbits_io:3.9.47') {
transitive = false
}
If I don't do this, android builds fail with many errors like this one:
Error:Gradle: Execution failed for task
':app:packageAllDebugClassesForMultiDex'.
java.util.zip.ZipException: duplicate entry: org/slf4j/impl/StaticLoggerBinder.class
My understanding is that my jar has duplicate dependencies already in the android project.
I don't get what i'm doing wrong, and why i need to use that flag. If i set these dependencies as "provided" I'd need my users to add my libraries to their dependencies. How do I share a library with dependencies without causing duplicate errors with the user. No other libraries require this flag, so i must be doing something wrong