We Keep Coding

Resolving "Multiple Jar files" aka "scanned from multiple locations"

I am working on a jetty service, and when starting it, I get a lot of:
SomeClass scanned from multiple locations: jar: jar1!Someclass.class, jar2!Someclass.class
So a single class is provided by two jars, and which I get on runtime is undefined, which is not good. Looking at other issues I found that tattletale can help diagnosing the problem. The report, in the Multiple Jar files section lists the same classes as jetty upon startup and which jars they were in.
A subset of the conflicts are:
And looking at
mvn dependency:tree -D verbose
I get:
+- ca.uhn.hapi.fhir:hapi-fhir-jpaserver-base:jar:3.7.0:compile
| | ...
| +- org.jscience:jscience:jar:4.3.1:compile
| | \- org.javolution:javolution:jar:5.2.3:compile
And so it seems that my fhir-base-jpaserver-base dependency pulls jscience that pulls javolution. But jscience and javolution supply some of the same classes. No other dependency to javolution exists.
My question is then, how do I go about solving this?
I could do some stuff in pom.xml but I suppose jscience needs javolution, and might break?

Sounds like a bug in jscience with how they packaged their jar, might want to file an issue with them.
They should either ...
have a proper/focused jar and dependencies.
or a standalone uber jar with no dependencies.
Not mixing the two concepts.
Meanwhile, just use the <dependency>/<exclusions> to exclude specific transitive dependencies that are causing you duplicate classes.
Also, you might want to run any of the various duplicate class/resource checker maven plugins to find any other cases you might have present on your project.

cloudbuild.yaml for javafx (jdk8u201) with other dependencies

I'm setting up a GitRepo, with different modules of a project. It has some legacy code, some C/C++ for Ardino, and a JavaFX project with some dependencies and Kotlin files in it.
What I actually need is, to build that JavaFx project on pull requests, targeting the develop branch
I already have an empty cloudbuild.yaml in my repository root. What I want is a non-Docker continous integration, so on pull request, I need an artifact build, so the executable can be downloaded for the other project members. GitHub and Google Cloud are connected, only the config is needed.
What is also specific, that I want to build with jdk8u201 (because of the licensing)
The folder structure is something like that:
+- legacy
+- Arduino_codes
+- JavaFX_project
| +- FILES...
+- cloudbuild.yaml
+- .git
If it is possible, that would be great if the builded version would be downloadable, or stored in a specific place in the repository

Try to add :3.5.0-jdk-8 to gcr.io/cloud-builders/mvn if you use maven. Result gcr.io/cloud-builders/mvn:3.5.0-jdk-8
It helped me. More info and cases you can find here.

can't create entity manager, when add relationships [duplicate]

I'm trying to upgrade to Hibernate 3.5.3-FINAL.
When running my unit tests, I now receive the following exception:
java.lang.NoSuchMethodError: javax.persistence.OneToMany.orphanRemoval()Z
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1837)
My classpath contains the following JAR's:
From the hibernate dist:
antlr-2.7.6.jar
commons-collections-3.1.jar
dom4j-1.6.1.jar
javassist-3.9.0.GA.jar
jta-1.1.jar
slf4j-api-1.5.8.jar
cglib-2.2.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
hibernate3.jar
Other jars:
blazeds-common-3.2.0.3978.jar
blazeds-core-3.2.0.3978.jar
blazeds-opt-3.2.0.3978.jar
blazeds-proxy-3.2.0.3978.jar
blazeds-remoting-3.2.0.3978.jar
commons-lang-2.3.jar
dbunit-2.4.7.jar
ejb3-persistence.jar // Note, I've tried excluding this, but I get different errors
guava-r05.jar
hsqldb-1.8.0.7.jar
junit-4.1.jar
lambdaj-2.0-with-dependencies.jar
log4j-1.2.14.jar
mockito-all-1.8.0.jar
persistence-api-1.0.jar
spring-security-core-2.0.0.jar
spring.jar
sqljdbc.jar
I've researched this, and I find answers that state my webserver must be JPA2 Compliant:
Unfortunately if your app server is
not JPA 2 compliant, you are likely to
be out of luck
This project is a library, not a webserver project. (Although it is eventually deployed to a webserver, I'm simply running unit tests here)
What am I missing?
<indulgent_rant>
As a sidenote, it's very frustrating that every time I upgrade Hibernate, I find myself spending hours researching conflicting jars for MethodNotFoundException or ClassNotFoundException's. There must be a simpler way?
I thought for sure that with the announcement they were merging the modules back to a single core project, that these conflicts would go away?
</indulgent_rant>

As pointed out by Timo, remove persistence-api-1.0.jar.
Just in case, here are the dependencies I'm using:
org.hibernate:hibernate-entitymanager:jar:3.5.3-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.3-Final:compile
| +- antlr:antlr:jar:2.7.6:compile
| +- commons-collections:commons-collections:jar:3.2:compile
| +- dom4j:dom4j:jar:1.6.1:compile
| | \- xml-apis:xml-apis:jar:1.0.b2:compile
| \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.3-Final:compile
| \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
| \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile
I'm getting them from this single declaration in my pom.xml:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.5.3-Final</version>
</dependency>
This should somehow answer your indulgent rant (if I rephrase: use Maven - or know what you're doing).

Remove these files from project lib location
persistence-api-1.0.jar
ejb3-persistence.jar
add only
javax.persistence-2.0.0.jar
it contains all the required fields and atrributes.
try this it'll work for your problem.
Manish Jaiswal

Try replacing persistence-api-1.0.jar with a JPA 2.0 jar.

Discovered a fix for the issue at least with what I am working with: IBM WebSphere 7 and MyEclipse Blue (Spring), or Bling, ver. 10.6. I created an application that has dependencies on other projects, one of these using Hibernate 3.6.3, requiring JPA 2.0. IBM WS loads JPA 1.0 to support itself ahead of JPA 2.0 and resolves all references to JPA to ver. 1.0. In the case of IBM WS, this causes the error reported above. The only fix I have come across since now includes adding JPA 2.0 as a shared library, then setting the server to load that library ahead of its native classes, similar to the method discussed here:
http://www.mkyong.com/websphere/websphere-7-javaxpersistenceonetomany-orphanremoval-error/
But our server admins will not allow changes to the server-wide classloader policy. So I still needed to find a way to get my project to use JPA 2.0 and not 1.0. I tried a lot of things but finally went for a Hail Mary and it worked.
The fix is to add the JPA 2.0 .jar file to your .war and .ear projects and then edit the Class-Path line in the manifest file in both your .war and .ear projects to point to the .jar files. It seems they must be in both or the approach will not work, so the JPA 2.0 .jar has to be in both the .war and .ear.
In your app (.war project), add hibernate-jpa-2.0-api-1.0.0.Final.jar to the project root. MyEclipse Blue will show it as a file at that location and also listed under "Referenced Libraries" in the Package Explorer view. Then open the manifest file at /WebRoot/META-INF/MANIFEST.MF and make sure the Class-Path line reads:
Class-Path: /hibernate-jpa-2.0-api-1.0.0.Final.jar
In your .ear project, add hibernate-jpa-2.0-api-1.0.0.Final.jar to folder 'lib' at your project root. If there is no 'lib' folder there, create one. Then in /META-INF/MANIFEST.MF, make sure the Class-Path line reads:
Class-Path: /lib/hibernate-jpa-2.0-api-1.0.0.Final.jar
Make sure all files are saved and do a clean build. Then export the .ear and deploy it as usual by the Integrated Solutions Console. But there is another thing you must do before the change will work; it does require changing the class-load policy for the app, but not the server. You are much more likely to get your WAS admin to go for that than changing the classloader policy for the entire server. To make the necessary change, after installing the .ear file, follow the left-hand nav bar click trail "Applications\Application Types\Websphere enterprise applications" and click on the name of your application, then click "Class loading and update detection". Then select "Classes loaded with local class loader first (parent last)" under "Class loader order", then click Apply, then Save. Now back at click trail "Applications\Application Types\Websphere enterprise applications", either start or restart your application. Test out your app and hopefully you will be good to go.
Final note: Evey time you re-deploy your .ear file, you will need to set the classloader option I just discussed. The preference is not retained between deployments.

adding javax.persistence-2.0.0.jar should work fine...

Setting your server's application classloader policy to parent last will resolve this problem so long as you ensure the hibernate-jpa-2.0-api jar file is included in the EAR. If this is possible in your environment it's a much easier solution.
Tested on WebSphere 7.

SRVE9967W: The manifest class path xercesImpl.jar can not be found in jar file

I've been going in circles on this one. We're using WebSphere Liberty, Eclipse, and Maven. I'm getting several warnings like
[WARNING ] SRVE9967W: The manifest class path xercesImpl.jar can not be found in jar file file:/C:/Users/.m2/repository/xalan/xalan/2.7.1/xalan-2.7.1.jar or its parent.
when I start up the server. For all the "class path something.jar"s, they are there in the Maven Dependencies folder in my project, and in my repo though they have a version number attached (e.g. xercesImpl-2.11.0.jar). It claims that the application is available, but if I try to go to the address, I get all kinds of nasty errors, mostly class not found.
When I try to package my project through Maven, I'm getting
[WARNING] Could not transfer metadata org.apache.maven.plugins/maven-metadata.xml from/to all-external-repositories-mirror (http://mirror/m2-repo/content/groups/adc-standard-repositories): null to http://mirror/m2-repo/content/groups/adc-standard-repositories/org/apache/maven/plugins/maven-metadata.xml
I'm about 70% sure this problem comes down to the fact that our project's Maven uses a mirror that I can't access from here, and I'm about 90% sure there is a work around to use my local repo, but I haven't been able to figure out where to look to make that change. I tried searching the entire workspace for any mention of xerces or xalan, but came up with nothing.
I swear it was using my local repo before as long as I had the jars. I also find it strange that it compiles and lets me run tests without complaining about this.
Any ideas, even just on where to look would be greatly appreciated. A good number of the things I found talking about a similar error mention WebSphere (and more specifically Liberty) so I'm also wondering if it has something to do with the way WebSphere deploys.

It has actually nothing with WebSphere. In your xalan-2.7.1.jar which is added to the project, there is META-INF/MANIFEST.MF file. And in it, you will find classpath like this:
Manifest-Version: 1.0
Created-By: 1.3.1
Main-Class: org.apache.xalan.xslt.Process
Class-Path: xercesImpl.jar xml-apis.jar serializer.jar
as you can see classpath refers to xercesImpl.jar, unfortunately your build is creating xercesImpl-2.11.0.jar, so it just cannot be resolved. However this is only a warning and application should run fine if the xercesImpl classes are available in the classpath.

Import new Maven module in Eclipse automatically

I have a multi-module Maven project in a Subversion repository with many developers working on it with Eclipse + M2Eclipse. Now if a developer adds a module, others need to do an SVN update from the command line (as Eclipse doesn't see the common root of the Maven project), and import the new module manually as an Eclipse project.
Is there a way to do this automatically?
My project structure looks like this:
Working Copy Eclipse Workspace
working copy root -X->
+- parent ---> +- parent
| \- pom.xml | \- pom.xml
+- child1 ---> +- child1
| \- pom.xml | \- pom.xml
+- child2 ---> +- child2
\- pom.xml \- pom.xml

You can have a pom in the root, that will have parent, child1, child2, etc as modules. After SVN update if there a new module was added, you can run
mvn eclipse:clean eclipse:m2eclipse
from the eclipse tools button (right of the debug and run buttons)
If you are using TortoiseSVN you can set a post-update client side hook, but each developer will have to set it independently.

May be buckminster project can help you check FAQ. Hope it helps

Is there a way to do this automatically?
To do what? To avoid importing the new module manually as an Eclipse project? AFAIK, this is currently not supported, you'll have to add it manually (it should be possible to do it programmatically though, there is such a request for the Maven Eclipse plugin - MECLIPSE-75 - couldn't find one for Maven Intergration for Eclipse).
That said, does adding a module really happen so often? Your situation might be different but, to my experience, you'll reach a stable point quite fast and adding a module will become something unusual.
Nevertheless, good team communication is the best solution I found to deal with this. When a developer add a new module, it is a duty for him to let others team members know that he introduced a change and to describe the required steps to take the modification into account. Nobody is omniscient, nobody can read in others mind, active communication is the key to good collaboration.

you can also use maven-eclipse-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<wtpversion>2.0</wtpversion>
<projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
</configuration>
</plugin>
refresh the project after importing it from svn
or you can also right click the project and click on 'enable dependency management'