I'm using Eclipse 4.4 Java EE with maven. I need to work with some methods that are marked as restricted. So I configured the required access restriction rules in eclipse. An everything's working.
But then I run Maven/Update Project and after that all the previously configured rules are gone. So the question is: how to tell maven about the rules?
If the methods are restricted due to the Java execution environment that Maven configures on your project (e.g. you want to use Java 7 methods while the project is configured for a Java 6 execution environment), then you should configure the Maven compiler plugin in the POM to use the Java version that you want to use (e.g. via the maven.compiler.source and maven.compiler.target) properties.
Related
So first off, a little background.
I am working on converting an Eclipse Java Web Project to Gradle. We use the Vaadin framework and currently manage the project with Ant/Maven/Ivy. We have another project that contains common code that the web project depends on. In both projects our library files, JARs, are simply included in the source and committed to our VCS. With the switch to Gradle we will be using the preferred method of pulling our dependencies from a repository; mainly Maven Central.
I have completed creating the Gradle build scripts that correspond to our current Ant build scripts. I have one Gradle build script for each project, as well as one at the root for configuration injection along with the settings file. I am using the java and eclipse plugins for both projects and additionally the war and vaadin plugins for the web project.
Now to the problem. When I use Gradle to construct the WAR it works perfectly and the WEB-INF/lib directory contains only the JARs that I would expect, based on the dependency configuration. However, when I use Tomcat inside Eclipse to publish the project I end up with a bunch of additional JARs in the WEB-INF/lib directory. Most of the JARs are harmless and just unnecessary, which is why I have excluded them from the WAR, but there are a couple that are actually problematic because Tomcat already has them. In one case it just ignores the JAR and I get the usual message of:
[Tomcat] validateJarFile(*) - jar not loaded.
In the other case I actually receive exceptions in the console, which is troubling even if the application appears to work correctly. I also noticed that all the dependencies associated with the testCompile configuration are also being published, which really doesn't seem right.
The exact offending JARs are tomcat-jdbc and servlet-api-2.5. The tomcat-jdbc JAR is required for compiling our common code. The servlet-api-2.5 JAR is actually just a transitive dependency of vaadin-client-compiler. I have removed the dependency for the vaadin-client-compiler in our web project, because it doesn't appear to be necessary, but it looks like it is still being pulled in by a configuration in the vaadin plugin for Gradle. However, in both cases I am using the providedCompile configuration of the war plugin to exclude them form the WAR.
So my question is, how do I keep Tomcat/Eclipse from publishing these JARs? How do Gradle and Tomcat/Eclipse communicate, or do they at all? From what I can gather it seems that Gradle and Tomcat/Eclipse only communicate indirectly via the .classpath, that the eclipse plugin for Gradle modifies. Also, I have tried the eclipse-wtp plugin for Gradle. It did not seem to resolve the issue because the problematic JARs were still being copied. I am actually not even sure whether I need to use this plugin or if I can just simply use the eclipse plugin.
I should also add that I did install the Gradle Integration for Eclipse "plugin" via the Eclipse Marketplace. With that I used the Configure -> Convert to Gradle Project option that it adds as well as the Gradle -> Refresh Dependencies functionality that it provides. Other than that, I found it to be a little buggy so I've mostly been running Gradle via the command line.
Below is the output of running gradle -v on my machine:
------------------------------------------------------------
Gradle 1.10
------------------------------------------------------------
Build time: 2013-12-17 09:28:15 UTC
Build number: none
Revision: 36ced393628875ff15575fa03d16c1349ffe8bb6
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.8.0_05 (Oracle Corporation 25.5-b02)
OS: Mac OS X 10.9.3 x86_64
Please let me know if additional clarification is required. I assume I must be doing something wrong or missing some configuration because surely my scenario is quite common. Many developers use Tomcat inside Eclipse to test web applications locally and with the popularity of Gradle I would be surprised if someone hasn't run into this before. It would seem the main difference with our switch to Gradle, as far as Tomcat/Eclipse are concerned, is that our dependencies are now being loaded from a repository instead of being linked directly in the source.
Any help is greatly appreciated.
However, when I use Tomcat inside Eclipse to publish the project I end up with a bunch of additional JARs in the WEB-INF/lib directory. Most of the JARs are harmless and just unnecessary, which is why I have excluded them from the WAR, but there are a couple that are actually problematic because Tomcat already has them.
This is a known problem with the gradle eclipse tooling. The problem is that it doesn't understand about dependencies with 'provided' scope. See this issue for some details:
https://issuetracker.springsource.com/browse/STS-2380
There is a workaround for this problem. Some common dependencies that 'cause problems' can be globally excluded via a list of regexps you specify in the preferences. Open menu "Window >> Preferences >> Gradle >> WTP". That's where you can add regexps that will be used to exclude jars from the 'deployment assembly'.
I have the following issue.
I have a dao library using the atomikos JTA transaction manager.
Also I have a web project that includes that dao library.
And although the tomcat lib folder includes all the required atomikos libraries, I still need to include the atomikos dependency (maven) with scope compile on the library (such that it is packaged along, or at least Eclipse knows it has to be packaged along).
If the library is not packaged along I get Class not found exceptions when deploying under eclipse/STS.
Since the Atomikos libraries are only required for development environments, I don't want these libraries to have scope compile (or runtime).
How can I change my tomcat eclipse setup such that I can set my atomikos dependencies with scope provided in my dao library.
Any suggestions?
Using Eclipse, I have configured one Java EE project to include in its class path the JBoss 7.1 Runtime.
(I did this with the "Add Library" button in "Project properties" -> "Java build path" -> "Libraries").
I use Maven to build the project and "normally" this works fine.
However, when I debug this application the Java EE source classes are not available. Just in case I took a look in the JBoss runtime but apparently the sources are not there. My main question is: Could someone please tell me what is the best way to add the Java EE sources to my Eclipse project so they will be available when debugging?
Also, if I am working with Maven is fine to add the Java EE libraries as the JBoss Runtime, as I am currently doing in my project? or it is considered a better approach to declare the dependency on Java EE in the project POM instead?
I started to wonder if the JBoss runtime approach was the "correct" way to add the Java EE binary classes, since strangely enough Maven from time to time fails compiling the application since it cannot see anymore the Java EE classes. I solve this deleting the JBoss Runtime from the build path (in the Eclipse project configuration) and adding them again. Fortunately, this compilation does not happen often, so I have been able to work doing this workaround until now.
Thanks for any feedback.
I've just installed Eclipse Indigo for EE and Java EE 6 SDK/JRE from Sun. I need all those to compile a 3rd party Java project using the "javax.*" classes. What I cannot understand how to reach those classes?
How can I import or otherwise connect to "javax.*" classes inside Eclipse?
They're in the Java EE implementation. In other words, they're in the application server. For example, Glassfish, JBoss AS, Tomcat, etc.
In Eclipse, just integrate the target server in Servers view and associate the dynamic web project with it. You can select it during dynamic web project creation wizard:
or afterwards via Targeted Runtimes in project's properties:
Once associated the project with the application server, Eclipse will do all the necessary magic to make those classes available during compiletime. To verify it, the associated server should be listed as Library in project's Build Path property:
Note once again, you don't need to change/fiddle anything in there! If you did some attempts beforehand while shooting in the dark in order to "fix" this problem, then you should make sure that you've undone it all, or things may still go wrong.
See also:
How do I import the javax.servlet API in my Eclipse project?
Make sure you have all the settings in preferences set. Go to 'Window' -> 'Preferences' and then check the 'Installed JREs', point it to your newest and greatest jre within downloaded jdk. If that doesn't work, download jdk and eclipse Java EE again and start from scratch. Also make sure you have a java and javac added to your PATH (either on Linux or Windows)
We're using Eclipse 3.4.1 with SpringSource dm Server 1.0. There are two Targeted Runtimes defined (Project / Properties / Targeted Runtimes).
The one we setup is called
SpringSource dm Server (Runtime) v1.0
There is one pre-defined called
SpringSource v1.0
We find that, even though we select SpringSource dm Server (Runtime) v1.0, Eclipse seems to frequently change the Targeted Runtime back to SpringSource v1.0.
Yes, we click Apply and OK on the properties screen.
Anyone seen that before? Any idea how to fix it?
EDIT
Here are images of our Targeted Runtimes and Run Configuration screens.
Targeted Runtime http://johannsen.us/SO/TargetedRuntime.png
Run Config http://johannsen.us/SO/RunConfig.png
Changing the target runtime will not change where your run configuration points.
You need to go into your Run/Debug configuration and change the execution environment there to point to the desired target.
Personally, I think this behaviour is confusing. I recommend filing a bug against Eclipse to make this easier to use.
The problem was that the POM file specified a name of SpringSource v1.0, while the Eclipse runtime environment only had a server defined with the name SpringSource dm Server (Runtime) - which is the default name suggested by Eclipse when creating the server.
Defining a server with a name of SpringSource v1.0, matching what is stated in the POM, resolved the issue.