I'm trying to upgrade my struts2 web app from guice2.0 to guice3.0.
I'm trying to test it out using maven jetty.
I've successfully upgraded my pom.xml to use the correct version and groupId for the 3.0 release, but if I call mvn jetty:run
I see that it is trying to download
guice-3.0-no_deps.jar
which throws a build error and can't be found the central repository?
I don't get this error if I don't include any guice extensions.
Any ideas?
Thanks
I posted this question also to the guice user group.
This is the answer I received.
The guice-3.0-no_deps.jar is a build-time artifact that's used to compile the extensions, but is not required at runtime - it's not on maven central because the Guice team didn't want people depending on this "uber-jar" by mistake. The extensions have an optional dependency to guice-3.0-no_deps.jar (so they can compile) but they also have a non-optional dependency to guice-3.0.jar for the runtime case.
Well-behaved maven plugins should see that the the no_deps dependency is optional and not throw a build error if it's missing, so this sounds like a bug in the jetty plugin. To workaround the Jetty bug you can explicitly hide this dependency as follows:
<dependency>
<groupId>com.google.inject.extensions</groupId>
<artifactId>guice-struts2</artifactId>
<version>3.0</version>
<exclusions>
<exclusion>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>3.0</version>
</dependency>
Note that we can't do this in the original build pom because we still need the no_deps dependency when doing the original compilation.
Related
I get vaadin-client-compiler artifact (which brings Jetty with it) included with my production project. Am I supposed to ?
To reproduce I'm starting from scratch and letting Maven generate a Vaadin multimodule project for me:
mvn
-DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-application-multimodule
-DarchetypeVersion=7.6.2
-DarchetypeRepository=http://repo.maven.apache.org/maven2/
-DgroupId=com.acme
-DartifactId=VaadinTest1
-Dversion=1.0.0-SNAPSHOT
-Dpackage=com.acme.vaadintest1
-Dbasedir=D:\\dev\\java
-DthemeName=mytheme
-DwidgetsetName=MyAppWidgetset
-DuiName=MyUI
-Darchetype.interactive=false
--batch-mode archetype:generate
Then in the parent project I execute:
mvn -Pproduction clean install
After this is done I look into the WAR file generated in the "xxx-production" project and notice it contains vaadin-client-compiler, Jetty, and what not.
I've found this ticket and by looking at the last comment it seems I shouldn't have anything like that in my production WAR. I hesitate to change my POMs as they are generated by the archetype and I guess at some level supposed to represent kind of a Vaadin best-practice approach. I wouldn't want to second guess that. Or ?
The problem with these artifacts being part of the classpath is that
it balloons the size of the WAR
it creates some problems wrt Atmosphere which supposedly gets confused because it finds Jetty on the classpath. (Atmosphere is used under the hood by Vaadin)
The result is that you'll get SEVERE error like this in the log when deploying on Tomcat 8:
14-Feb-2016 16:42:30.368 SEVERE [localhost-startStop-1] org.atmosphere.cpr.DefaultAsyncSupportResolver.newCometSupport Failed to create comet support class: class org.
atmosphere.container.JettyServlet30AsyncSupportWithWebSocket, error: null
To sum up:
Is it correct that I'm not supposed to have these artifacts in a
Vaadin 7.6.2 production project ?
How to solve ?
I believe I've found the answer. It seems Vaadin team was/is fully aware of this but it is kind of a left-over from the old days when there was some kind of annoying bug.
In your xxx-widgetset project you'll see something like this in the POM for that project:
<dependencies>
<!-- Versions for these are configured in the parent POM -->
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
... you'll see more deps here if you've added
... Vaadin add-ons to your project.
</dependencies>
See the TODO comments ??
Well, it just so happens that the bug mentioned in ticket 14788 doesn't happen anymore, at least not on 7.6.2. So you can now safely do what the TODO comment says.
This has reduced my WAR size by 50-70 pct.
It seems to me there's no longer any good reason why this archetype generation doesn't actually do what TODO comment says. Currently you'll have to manually correct it every time you generate a new project skeleton.
If you work with a different webserver (in your case Tomcat 8) you don't need the provided jetty-plugin.
As the archetype has some jetty-dependencies you can exclude them with the
exclusions tag in the Maven POM file.
Example
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<version>${vaadin.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlets</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-annotations</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-util</artifactId>
</exclusion>
</exclusions>
Moreover delete/comment out all unnecessary "jetty" dependencies found in the module POM files.
I am running into the following error
java.lang.NoSuchFieldError: WRITE_DURATIONS_AS_TIMESTAMPS
at com.fasterxml.jackson.datatype.joda.ser.DurationSerializer.<init>(DurationSerializer.java:28)
at com.fasterxml.jackson.datatype.joda.ser.DurationSerializer.<init>(DurationSerializer.java:25)
at com.fasterxml.jackson.datatype.joda.JodaModule.<init>(JodaModule.java:45)
I checked to see what versions of jackson-datatype-joda are available. It appears that maven has excluded all version mismatches.
Any other reason this might cause serialization errors?
The problem is that among the maven dependencies (mind that it could be a transitive one) you have incompatible versions of jackson-datatype-joda and jackson-databind. Incompatible in the sense that jackson-databind's SerializationFeature class is missing the WRITE_DURATIONS_AS_TIMESTAMPS field. To see what dependencies maven brings you can run the following command in the terminal (or you can use an IDE's maven plug to search and analyse the maven dependency tree):
mvn dependency:tree | grep databind
the outcome will most probably be something like:
[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
The version of course can vary but the important thing is that the WRITE_DURATIONS_AS_TIMESTAMPS field is only available since version 2.5
You can exclude a transitive dependency like this:
<dependency>
<groupId>group.id</groupId>
<artifactId>artifact-id</artifactId>
<version>${artifact.version}</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
If it's not a transitive dependency you need to update version of jackson-databind.
I got it resolved by using following dependency as this dependency has overridden any other version used:
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-joda</artifactId>
<version>2.5.3</version>
</dependency>
I had same error. I had included all jackson*2.7.0 libraries under WEB-INF/lib/ and i was still getting that error. I am using wildfly 8.2 and it had jackson 2.4.1 libraries under modules and somehow it was loading 2.4.1 jars from that location. So I had to manually upgrade them to 2.7.0 which fixed the issue. I was under impression that if I did not mention it to load jackson jars in deployment configuration file, it would not load wildfly jars. I guess I was wrong.
I have one Spring application(CustomerPort). In this I am using one open source jar(commons-lang.2.4). And my CustomerPort using other module, as jar, which using different version "commons-lang.2.2".
Since the other module using commons-lang.2.2, my application also refereeing modules opensource jar instead of commons-lang.2.4.
Could you plz let me how to exclude commons-lang.2.2 in Pom.xml file
use the <scope> tag to correct the scope of these transitive dependencies. Read this for more info on maven dependency scopes
In the pom.xml for CustomerPort, where you specify the dependency on the other jar module, you can specify an exclusion for commons-lang. This will prevent Maven from bringing in the commons-lang transitive dependency from the other jar.
<dependency>
<groupId>otherModuleGroupId</groupId>
<artifactId>otherModuleArtifactId</artifactId>
<version>otherModuleVersion</version>
<exclusions>
<exclusion>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
</exclusion>
</exclusions>
</dependency>
Verify that its doing the right thing by running mvn dependency:tree in CustomerPort.
More info on excluding transitive dependencies here
I try to compile maven web project with
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws</artifactId>
<version>3.0.5-FINAL</version>
</dependency>
The problem is that when I try compile it I get the following errors:
[ERROR] Failed to execute goal on project inferx-d2aserver: Could
not resolve dependencies for project
com.inferx:inferx-d2aserver:war:4.0: The following artifacts could not
be resolved: maven-plugins:maven-cobertura-plugin:plugin:1.3,
maven-plugins:maven-findbugs-plugin:plugin:1.3.1,
org.springframework.ws:spring-ws:jar:3.0.5.RELEASE: Failure to find
maven-plugins:maven-cobertura-plugin:plugin:1.3 in
http://repository.springsource.com/maven/bundles/release was cached in
the local repository, resolution will not be reattempted until the
update interval of com.springsource.repository.bundles.release has
elapsed or updates are forced -> [Help 1] [ERROR]
I use Apache Maven 3.0.3, Java: 1.7.0 OS: Windows 7 (64 bit)
I am not sure if this is the same case since my dependencies is different. I got similar error message with the same dependencies error so I removed both dependencies from ~/.m2/repository/jaxen/jaxen/1.1.3/jaxen-1.1.3.pom and the project is compile fine now.
I was also facing similar issue. I just excluded jaxen from Jdom dependency and it worked for me.
jdom 1.1.2 includes jaxen 1.1.3 which imports those artifacts.
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.1.2</version>
<exclusions>
<exclusion>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
</exclusion>
</exclusions>
</dependency>
It look like your pom or parent pom contains a wrong definition of the maven-coberatura-plugin which should be fixed first. Furthermore remove the folder in your local repository.
From the error message related to cobertura version, it looks like you may be having a pom.xml corresponding to maven 1.
The following are maven 1.x versions of the plugins and not supported.
maven-plugins:maven-cobertura-plugin:plugin:1.3,
maven-plugins:maven-findbugs-plugin:plugin:1.3.1
Removing the pom is not the solution; in future builds may be you need them. Best solution according to my opinion is to modify the POM of corresponding jars. Like if you are getting error because of any jar; actually there is the dependency defined in its POM. So use <exclude>. That will work for sure.
Problem is a bit stupid but I can't find any spring3.0-with-dependencies.jar. Is it assumed that I should find all necessary dependencies by myself?
May I use dependencies from spring 2.5 in this case? UPD: answer is no, I can't. So, where are the dependencies??
I guess they don't release them any more. You can have the dependencies automatically if you use maven or ivy. All you need is to define the dependencies in your pom.xml like this:
<pom>
...
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>3.0.0.RELEASE</version>
</dependency>
</dependencies>
...
</pom>
Maven will bring all the dependencies transitively.
If you are using Maven, you can get Spring 3.0 jars (and their transitive dependencies) from the central repository. Simply add this to your pom.xml:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.0.0.RELEASE</version>
</dependency>
For more details, more artifacts, check out Obtaining Spring 3 Artifacts with Maven (and please, don't use EBR if you don't need it or I guarantee the nightmare).
Usually the readme.txt file has the dependencies listed for each module. With that you can usually get them easiest from the maven repository... or better yet, with maven (http://maven.apache.org).