Using the Google-Eclipse plugin, I have successfully created, built and deployed (locally) a very basic GWT Web Application.
The thing is: I'm not a huge fan of the project structure GWT (or the Google-Eclipse plugin) set up by default. So I'm trying to set things up in a way that makes logical sense for me, but that still is able to run in DevMode and deploy locally.
So I created a 2nd project but did not set it up as a Web Application; instead I used a normal Java Application. I created my source directories, my EntryPoint implementation (TestModule implements EntryPoint), my TestModule.gwt.xml, my host page HTML, etc. All the artifacts that I did in the first (successful) project.
But now I am in Run Configurations trying to manually set up a run config similar to how the Web Application Wizard created one for me with the first app I built.
In the Run Configurations >> GWT tab it gives me a window where I can add Available Modules. When I click the "Add" button, no matter what I type, it doesn't provide me with an available list of options to choose from.
So I exited out of the Run Configurations dialog, assuming that I need to set up my project properties differently. So I right-clicked my project, went to Properties >> Goodle >> Web Toolkit, and sure enough, see a similar panel that allows me to add Available Modules. It is my belief that if I configure this section correctly, then a list of Available Modules will become available to me when inside the Run Configurations dialog, and I should be able to continue.
Here's what I'm seeing:
Any ideas as to how I can configure my project correctly so that this Available Modules dialog actually presents me with options? Thanks in advance!
Please note: I anticipate many answers to be along the lines of "just use the Web Application wizard, it's so much easier", etc. I understand this and am (temporarily) accepting the caveats of trying to configure my own GWT app without the help of the plugin's Web Application wizard. If I find it to be really, really difficult to "roll my own" here, then I'll cave in and go back to the wizard. But I want to give this my best shot before doing so!
Feel free not to use the Google Plugin for Eclipse (hereafter GPE)! There is no need - its all Java, or at least self contained enough to act like Java as far as Eclipse can tell. If you don't want the wizards, the JSNI autocomplete, UiBinder autocomplete, by all means, you can even leave the plugin out.
To run a GWT project in dev mode, you just need the basic moving parts of the SDK:
* gwt-dev.jar - Dev mode (code server and simply HTTP server), the compiler, and assorted other tools
* gwt-user.jar - GWT language runtime (JavaScriptObject, GWT, etc) and standard events, widgets, and other bits
* optional: gwt-servlet.jar - classes to run in a servlet container for some basic GWT servlets
* optional: requestfactory-*.jar - if you don't use RequestFactory, don't worry about it
You may also need a json.jar and the valdation-api.jar as well as its sources.
This gives you enough to have any project compile in plain Java. The gwt-user.jar and gwt-dev.jar do not belong in your server classpath - don't put them in a WEB-INF/lib/ dir, just keep them on hand to compile your code to JavaScript.
Both Dev Mode and the compiler itself are just classes with a main method, so a standard Eclipse Run/Debug Configuration can start either. Each will have its own options to get going, such as 'where do i find your sources', 'what module are you starting', and in the case of Dev Mode, 'where is the war/ dir for me to serve'.
Avoid GPE entirely:
DevMode:
Make a new Java Run Configuration, and verify that the above classes are on the classpath, as well as your source directories. Set the main class to com.google.gwt.dev.DevMode, add a few params:
-war path/to/war/dir/ my.package.to.ModuleToRun
Everything else is just extra flags to change out it works, and hints for where to start. Take a look at https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#What_options_can_be_passed_to_development_mode for other options available to you
To debug this, run it as a Debug Configuration - Eclipse will complain a bit about how it can't hot swap classes, but ignore these and hit continue. When you make a change in a .java file, save, and refresh the browser - GWT's specialized Dev Mode classloader will pick up the changes.
Compiling:
As above, make a run config with the important classes and jars on the classpath. This time, use the com.google.gwt.dev.Compiler main class, and specify the module(s) to build under the program arguments. Again, there are many options at your disposal to change how it compiles and what additional output it provides, see https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#DevGuideCompilerOptions for more options
Using GPE without the wizards:
The important thing to remember here is that GPE is just papering over a few details - you don't need to use the wizards, but at some level, its all wizards until you are just working in raw Java. Classpath, imports, etc - these are all Java concepts that more or less apply to GWT development, though it adds Modules to help set up deferred binding rules, etc.
The module selection dialog is not necessary, though two other pieces are. First, as you've done, under Google > Web Toolkit turn on "Use Google Web Toolkit", and ensure a valid SDK is selected. This does two things - it adds the necessary jars to the classpath (under 'GWT SDK'), and enables a few other options throughout the project - JSNI autocomplete, Dev Mode, assorted wizards (that we'll ignore). The other piece that is necessary is to go to Google > Web Application, indicate that "This project has a WAR directory", and give it the path to that directory so Dev Mode knows where to start Jetty.
Once this is done, the plugin should be able to let you start from an html file that points at a module with an entrypoint. I'm going to gloss over these details, as this is basic project setup - things that the wizards are good at, examples are full of, and you presumably have read these directions (else you wouldn't be skipping wizards...). From within the previously selected WAR folder, pick such an html file, right click it and select Run As... > Web Application. It is possible that GPE will ask once again for the WAR folder - help it out, and you'll be on your way. Dev Mode will add a View to eclipse rather than a standalone window, and you'll be able to monitor progress from there.
Compiling is then a matter of going to the G icon in your toolbar and selecting "GWT Compile Project...". A dialog will appear asking for the project to use, and the entrypoint(s) to start with, as well as a few other options. Note that if you compile into the war folder then start Dev Mode, you may find that Dev Mode overwrites part of your compiled output for easier Java debugging, thus requiring an additional compile.
Related
Eclipse has to allow that, since javac from JDK allows it without requiring me to contact the CIA for clearance. If eclipse does not allow that, what other Java IDE would allow me. Worst-case scenario I'll just use emacs and terminal.
Screenshot:
Most of the relevant information has already been given in comments, I'm mostly summing it up with a little background and some links:
Firstly, Eclipse does not accept a folder named java.base within your source folder. Such layout is used by javac's multi-module mode, but in an IDE like Eclipse that mode is not needed, since we have projects for grouping the modules. In particular Eclipse requires that each project contains at most one module. Now you are free to either (a) define src/main/java/java.base as a source folder, or (b) move its content one level up (so that packages start directly in src/main/java as in the olden days).
Secondly, for setting up options like --patch-module the UI has been revamped in Eclipse 2019-06, so I suggest to upgrade Eclipse (if not already done). Then you will find a new tab in the Java Build Path configuration dialog called "Module Dependencies" where you can mark your project as patching java.base. (The method from older versions of Eclipse was: find a node "Is Modular" below the library you want to patch and edit (double click) its details. This mode is still supported for a migration period, but it is no longer recommended).
Thirdly, the Java Build Path, which is used for building/compiling (as the name suggests :) ), should also be respected for launching. To make sure that compile-time and runtime see the same set of options, both dialogs (Java Build Path and Run as ...) have a button for showing the textual form of the configured options (called JPMS options in the build path configuration).
It's been about 6 years since I had to do any Java programming, and even longer since I had to do any notable amount of Java programming. While I remember the language, I was always weak on all the other things, such as all the tools for building programs and such. In fact, I've forgotten more than I remember - and I was self taught in the first place.
In the past I based my organization of code on what I had seen in some open source projects, so I had directories set up with something like com/mybiz/util and com/mybiz/network and so on. I'd put the source code for the classes in the appropriate directory and make sure it was in the package that matched that path. Then if I had to change the code (like for a bug fix or to add a new routine in an existing class), it was easy for me - change it and recompile the class. As I recall, imports for the classes in the root directory for my project (it was all tied together) to use these classes were no problem with that setup.
Then someone told me about Eclipse, but the biggest thing I remember doing was refactoring in it. Until then, my IDE was a console window and a text editor.
So I still have a lot of classes in that hierarchy - com/mybiz/util (and so on). But now I'm using this code for personal libraries, so it's in com/tango/util and com/tango/network and such. I've having to make changes here and there to code to make it more universal and to remove stuff that was specific to the business for one reason or another.
I want to use these classes as libraries for my projects in Eclipse now. I'd rather not just compile and put them all into a jar, since many of the classes are still being fine tuned and need recompiling. I'd rather just be able to tell Eclipse, "Use this bundle of source code in the "com/tango..." directory tree and then just use something like "import com.tango.util.FileUtils" in my source code.
Even more, I'd like to be able to specify this as a library or some kind of available source code or resource in Eclipse so it's easily added (or added by default) to each project I create.
Can I do this? Or should I be looking into something else or another way to handle it instead? Again, I'd rather just have the source code included, since it's still being changed around and being recompiled.
For the refactoring "magic" you want to use Eclipse needs to know all source files to execute, so you have to have all your source code added into an Eclipse Java project.
However, if you want to have a set of classes that are available for multiple projects, nobody stops you from creating multiple projects, and setting up dependencies between them. The easiest way to achieve this is to add a dependency in the New Java Project wizard (be careful not to press the finish button after setting up the project name but use the Next button where you can add existing Java projects into the build path).
If all your source code is available in either a single, or some interdependent Eclipse Java projects, then Eclipse will take care of compiling all the classes. Usually, Eclipse is intelligent enough to only recompile what needs to be changed, so this process is really swift (at least most of the time).
I hope this answer is helpful enough - if not, feel free to ask for further information.
Edit: Adding information about Java libraries support.
If your "library" project does not change, but you have a jar for it (typically a case of an externally downloaded library), Eclipse allows you to define User Libraries - libraries that can be added to build path of a Java project. To create such a User Library, open Preferences, go to the page Java/*Build Path*/User Libraries, where you can define libraries that consist of one or more jar files.
However, if you are developing your own libraries, and your project does not go into a gigantic size (e.g. several million lines of code), I recommend adding the library project as source into the Eclipse workspace, as in my experience that is easier to maintain in the long run.
First, I would suggest using IntelliJ (in my opinion it's much better than eclipse) but it is very possible to do this and simple as well. So to save time lets pretend all the classes you need in the future library are Network.class, FileUtils.class, and Helper.class. First make a new folder on your desktop called My Libraries. Right click on it and hit Send To, then Compressed Zip Folder.:
Once that's done drag your class files into the folder.
Open up Eclipse and choose a workspace. Once you've done that, you should show up with the default Eclipse screen. Now hit the File tab and hover over New, then go to Java Project.
You will show up with another screen. Enter the name for your project and click Next. Hit the Libraries tab and then click Add External Jars.
Now navigate to your Compressed Zip and click Open.
You now have your library added.
Here is a little ASCII Chart so you can remember:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Folder -> Class Files -> Compressed Zip -> Eclipse -> New Project -> Next -> Libraries -> Add External Jars -> Compressed Zip (Library)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
What is the purpose of Build Automatically option in Eclipse (Project-->Build Automatically)? Mine will always be checked. But when ever I have some java code changes I still have to do a full build. I was told that it should always be checked. I don't see any benefit in doing so. Please somebody explain.
Eclipse has a good answer on their website:
You have two modes of working: auto-build mode and manual build mode. By default, you are in auto-build mode and Eclipse takes care of compiling source files automatically. Builds occur automatically in the background every time you change files in the workspace (for example saving an editor). Auto-build is convenient because it means problems view, binaries, etc. are are up-to-date at all times. The downside is that in large workspaces auto-builds can be time-consuming if you are changing files in projects with lots of downstream dependent projects.
If auto-build is taking too long and is interfering with ongoing development, it can be turned off. Once in manual build mode, the user is in complete control over when builds occur and what gets built. Project > Build All (Ctrl+B) can be invoked at any time to trigger what auto-build was doing automatically. This allows you to build up a larger set of changes before invoking a build (Eclipse remembers which files have changed so that it does not have to do more work than required when you do ask for a build.
Note that when they say "auto-build mode" they mean if you have checked "Build Automatically", when they say "manual build mode" they mean you do not have "Build Automatically" checked.
Yes, you still have to do a build - but it's done automatically when you save (not an external build like an Ant build, but the "internal" build). If you didn't want to build on save, you'd uncheck the box. Having it build automatically makes some people nervous, I believe.
NOTE
For C/C++ users it's told (from help.eclipse.org):
By default, the Eclipse workbench is configured to build projects automatically. However, for C/C++ development you should disable this option, otherwise your entire project will be rebuilt whenever, for example, you save a change to your makefile or source files. Click Project > Build Automatically and ensure there is no checkmark beside the Build Automatically menu item.
Project - Disable Autobuild option does not always mean autobuild is off. For example "Makegood" test automation plugin will trigger autobuild when Preferences - Run/Debug - launching - (General opt) Build before launch is ON. So turn it off if manual build needed.
One thing that people didn't mention here (and it took a while for me to figure this out too) is that eclipse build (either automatic or manual) would basically follow what you have outlined in the project's "Java Build Path" source tab. So when a file is covered in that build source tab, when you change the file, it gets copied/compiled to the output folder that was specified for that directory/file.
One more difference is:
Most of the time while working on JSPs it helps me when checking "Build Automatically". It automatically picks up the changes in JSPs.
But if you make changes in your java classes/XMLs you need a manual build.
Since I'm using resin server which is run outside eclipse via command prompt, i prefer checking the option.
When i have my server setup in eclipse, i turn it off and use Publish on server.
This is the way i use and the answer is based on my experience.
If Build Automatically is checked, the IDE will automatically compile your Java code whenever you modify and save a file. This does not mean it will completely build and package your entire solution as if you were going to deploy it such as if you are working in a Web project on a WAR module. It basically really just compiles your code.
I'm developing various in-house extensions for JIRA, the issue tracker we use. So far I worked with Netbeans and everything worked like a charm. However, now I need to switch to Eclipse and I'm having struggle setting up the environment for this development project.
First a clarification why I'm using the approach I'm describing here: building JIRA (in an IDE) is not easily done and I'm absolutely not interested in wasting my time to figure out how to do it. Besides, I don't need to build it, I just want to develop extensions and be able to use the IDE's auto-completion and help support (API docs). Atlassian (the company that develops JIRA) provides a "development" package, but it's just a sorry excuse rather than a real solution.
What I did with Netbeans was to create a library bundle with all relevant jar-files, the Java source files and the API documentation. This way I could use auto-completion, "jump to" the source and the API docs would pop-up when needed.
It seems Eclipse doesn't offer such a functionality, at least I couldn't figure out how to add the sources and the API docs to a "User Library" (which I'd then add as a dependency to my project just as with Netbeans).
My next approach was to create a separate project that holds all the stuff and mark that project as a dependency of my project. This works, but it leaves me with another issue: now I get 37k errors reported (all within the "dependency project"). As said, correctly setting up building for this dependency is a major struggle and not my original goal, therefore I'd happily ignore these errors. Automatic building is turned off and changing the "Errors/Warnings" settings under "Java Compiler" for the project didn't change a thing, so I'm kind of lost now.
Okay, let me try to phrase this as questions:
Maybe I just didn't find it: Is there a way to create a dependency bundle (call it whatever you want) in Eclipse that -- besides just carrying jar-files -- gives me the ability to use the API docs and "jump to" the declaration in the sources?
If not, what's the common practice to do in such a situation?
If the "dependency project" solution is the way to go, how can I completely disable compiler errors for that project?
Check this for illustration with images
Add the source code for jar
Add the Javadoc for a jar
Or just right-click on the jar file in the Package Explorer view. Select "Properties" then set the according paths in the "Java Source Attachment" and the "Javadoc Location" field.
When you create user libs via window->preferences->java-build path->user libraries you can specify which jar you need, sources (in archive or folder) && javadoc (from internet, or local, or from archive). Then you can use this lib in your project via context menu on project->Build path->add library->user library-> choose your lib.
Here you acn pick up more info Eclipse help
I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.
Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:
I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.
For this specific project I have another reason not to commit the project files:
There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.
How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?
At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.
After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.
It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:
.settings/org.eclipse.jdt.ui.prefs - it contains the settings for the import ordering
.settings/org.eclipse.jdt.core.prefs - it contains the settings for the compiler version
In general I haven't noticed Ganymede modifying files without me modifying the project preferences.
I recommend to use maven so that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.
In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediately afterward." This means that we had to do some work:
Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
Create useful start up scripts for all of our relevant scenarios.
Create edited datasets that don't cause the checkout to take too much longer (it's a big project).
This philosophy was worth cash money (or at least labor hours which are almost more valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.
Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.
I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.
Try to port your project to a build system like maven. It has everything you need to get the same experience of the project on every machine you use.
There are plugins for just everything. Like the eclipse plugin. You just type "mvn eclipse:eclipse" and the plugin generates your entire ready to work eclipse project.
To give the answer to your question. Never check in files that are not being used by your project at any time in the development cycle. That means that metadata files like eclipse properties etc. should never be checked in in a SCM.
I like checking in the .project, .classpath, and similar files only if they will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)
If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do not check them into source control. It will only cause headaches in the long run.
I use IntelliJ, which has XML project files. I don't check those in, because they change frequently and are easy to recreate if I need to.
I don't check in JAR files. I keep those in a separate repository, a la Maven 2.
I don't check in WARs or JARs or javadocs or anything else that can be generated.
I do check in SQL and scripts and Java source and XML config.
I'd suggest having the actual project files ignored by the version control system due to the downsides you mentioned.
If there is enough consistent information in the project settings that there would be benefit from having it accessible, copy it to a location that Eclipse doesn't treat as special, and you'll have it available to work with on checkout (and copy back to where Eclipse will pay attention to it). There is a decent chance that keeping the actual project files separate from the controlled ones will result in loss of synch, so I'd only suggest this if there is clear benefit from having the settings available (or you're confident that you'll be able to keep them synchronised)
In our case, we used to check in the project files (.project and .classpath) to make it easy for all developers to create their project workspace. A common preferences file and team project set were located in source control as well, so creating your workspace was as simple as import preferences and import team project set. This worked very well, but does rely on everyone having a consistent environment, any customizations would have to be applied after the basic workspace is created.
We still do this for the most part, but Maven is now used so of course dependency management is handled via Maven instead. To avoid conflicting information, the .project and .classpath were removed from source control and are now generated via maven goals before we import the team project set. This would easily allow for different environments, as you would simply need scripts to generate the IDE specific portions based on the Maven configuration.
PS-For ease of maintenance though, I prefer having everyone use the same environment. Anything else inevitably becomes a full time maintenance job for someone.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization
Don't. Only check in the source code of your projects.
As a response to:
"There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard."
Eclipse offers a number of ways to keep local settings manageable: Java Classpath Variables (Java > Build Path > Classpath Variables) are one, 'Linked Resources' (General > Workspace > Linked Resources) are another http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Creating a README that states which settings to set before building/running the project works pretty well in my opinion.
Now how to make sure your continuous build system understands the changes that were made to the eclipse settings, thats another issue... (I have a separate build.xml for ant that I keep up to date by hand)