I am facing this weird requirement where I am supposed to create a web page using GWT widgets in an existing spring-maven web project but the corp security doesn't allow me to install any Eclipse plugins. I have the latest SDK but thats about it.
Is there any way to achieve this?
The Google Plugin for Eclipse (GPE), just like so many other Eclipse plugins, is not mandatory; it's just an aid.
But first, if “the corp security doesn't allow me to install any plugin” only means you're not allowed to use the Eclipse marketplace or contact update sites, it's worth mentionning that you can download the update site as a ZIP to be used locally: https://developers.google.com/eclipse/docs/install-from-zip
If that isn't allowed either, then let's look at the features provided by the GPE and how you can possibly do the same without the plugin:
Wizard for creating new projects: you're in a Maven project, so you're not concerned.
Running and debugging: you can do the same with a Java Application launcher. Choose com.google.gwt.dev.DevMode as the Main Class, add the com.google.gwt:gwt-dev JAR to the classpath (you can also add it as a dependency with scope provided, and ignore the warning printed by the gwt-maven-plugin) if needed, add your source folders to the classpath and pass the appropriate arguments.
Wizards: let's be honest, they won't boost your productivity that much.
GWT Compilation: you can do the same with a Java Application launcher. Choose the com.google.gwt.dev.Compiler as the Main Class, add gwt-dev and your source folders to the classpath and pass the appropriate arguments.
Editors: you'll lose the formatting and highlighting of JSNI methods, as well as reference checking of your JSNI references, the auto-complete in UiBinder, and validation of UiBinder and ClientBundle references. All those will be done only when you GWT-compile your project.
RPC: you'll lose the validation of your RPC interfaces and quick-fix to keep your sync and async interfaces in sync. Validation will be done only when you GWT-compile your project.
JUnit: you can do the same with a JUnit launcher: just make sure you add gwt-dev and your source folders to the classpath, and pass the appropriate options as a gwt.args system property (see “Passing Arguments to the Test Infrastructure” in the docs).
Nothing insurmountable.
Related
I created a plain old JAR with some fancy test classes I want to use to make testing more easy and fun.
Everybody knows Eclipse plug-ins aren't for unit testing and Tycho doesn't allow it, but we already managed a setup where we can test plug-ins using Surefire exactly the same way we test pure Maven projects. Using <pomDependencies>consider</pomDependencies> in the config of the target-platform-configuration allows for adding plain old Maven dependencies, so the Tycho build already works with the new fancy test classes.
Not Eclipse though. Plug-ins are missing the library "Maven Depdencies", and even adding it via the "Java Build Path" in the settings does nothing. I can add the project with the test classes there, but that would mean checking it from SVN and adding it to every workspace (I have 100, and I can't rule out that other people are working here, too).
On the other hand I can't just add it to the Manifest.MF because that would mean the test library would be shipped to our customers (which fancy or not is a bad idea). And I don't know how Tycho feels about optional dependencies, it's probably not a fan (and I feel like this would be bad style).
So how can I trick a plug-in in Eclipse into accepting a dependency that is not in the final plug-in?
I'm having troulbe enabling JSF in Eclipse. I have installed the WPT tools that should have had JSF included but when I right click on my project, properties, facets, enable facets I get a warning saying "Further configuration required" I click this, and I'm notified that "At least one user library must be selected" However there are no libraries to select.
I can optionally select "Disable Library Configuration" but I don't know what effects this might have as Eclipse is telling me that i must configure a user library.
Should I download a separate Jar from the Mojarra and add this to my build? Or can I safely disable. Why wasn't it included with WTP like it was supposed to be?
"At least one user library must be selected" However there are no libraries to select.
You have to prepare them yourself by Window > Preferences > Java > Build Path > User Libraries.
I can optionally select "Disable Library Configuration" but I don't know what effects this might have as Eclipse is telling me that i must configure a user library.
When you choose this option, Eclispe will also tell you that the user takes the responsibility of configuring the classpath appropriately via alternate means.
Should I download a separate Jar from the Mojarra and add this to my build? Or can I safely disable.
That's one of the alternative ways. Whether you need to download it yourself depends on the project's target runtime. If it's for example a simple JSP/Servlet container which does not ship with bundled JSF, such as Tomcat 7, then you indeed need to install it yourself. Just dropping the JAR(s) in /WEB-INF/lib is sufficient (or defining it as an user library, of course). Eclipse will automagically do the right things for you (adding to build path, including in exported WAR, etc). However, if it's for example a more full fledged Java EE container, such as Glassfish 3, then you don't need to do anything as it already bundles JSF as part of Java EE API. Just disable the library configuration altogether.
Why wasn't it included with WTP like it was supposed to be?
They have JSF tools included. They do however not include JSF libraries. Or did you read otherwise? If so, where exactly? It must have been a misinformation or misinterpretation.
See also:
JSF 2.0 tutorial with Eclipse and Glassfish
Download javax.faces-2.1.17.jar file and create a new library from manage library option and add the jar file in that library. Click apply, now it will work
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)
With the maven-eclipse-plugin, using mvn eclipse:eclipse, you can specifiy eclipse project natures and builders that will automatically be added to the eclipse project.
Earlier versions of m2eclipse used the configuration block of the maven-eclipse-plugin and also let you activate natures and builders using the same mechanisms. This seems to no longer be the case because a) I can't find any reference to maven-eclipse-plugin in the m2eclipse sources and b) it just doesn't work :-)
So this is my question: is there any way to configure the eclipse project generated by m2eclipse from the pom.xml? Specifically: project builders and natures, but I'd be interested in other options as well.
The following thread summarizes almost everything. First, it explains that m2eclipse doesn't and won't support anything from the Maven Eclipse Plugin anymore because:
Sonatype doesn't maintain it.
It causes them too much troubles.
Second, it states that the m2eclipse way to handle additional project natures and builders is to write project configurators:
(...) we encourage writing configurators to add the natures and builders you want based on what it available in the POM.
See this link for a guide and this project for some existing configurators for checkstyle, findbugs, pmd.
I have now implemented this as a maven plugin I call maven-eclipseconf-plugin.
Unfortunately it's proprietary work for a client, so I can't share it. But let me describe what I do:
Tied to the lifecycle verify, I check for the existence of an eclipse .project file. If it's there, I check it for the presence of the builders and natures I want to automatically add (and you can deactivate this behavior by using a maven property or a stop file with a configurable name). You can also define configuration files that will be written (like .pmd, which is related to this other question of mine). The contents of the Configuration files can be specified inline, it can come from an external file, or from a URL. I also tried to introduce variable substitution in the config files where a special placeholder would be replaced with a multi-moduke-project's root folder, but I had to give up on that approach.
Anyway, the plugin gives me pretty much all the functionality of the maven-eclipse-plugin I ever used (of course there is a lot more though) and I'm happy with that. Perhaps I will build something similar once more in open source when this contract is finished.
Project configurators are the proposed approach. But the latest version of m2e-extensions is from early 2010 and developed against m2eclipse 0.10.x. There is a successor project called m2e-code-quality which is more recent and active and developed against m2eclipse 0.12.x.
But neither m2e-extensions nor m2e-code-quality do support FindBugs at the moment. And there are some other limitations with header files, exclusions and modified JARs.
I have successfully used a universal approach with AntRun, Ant and XMLTask to automatically add project natures, builders and configuration files for Eclipse plugins from pom.xml.
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.