DougBreaux 0100002GMN Visits (2118)
(I'm assuming this is the same in stock Eclipse, I don't have it installed right now to confirm.)
If you have any source code that is generated by tooling (say, JAX-WS proxy code), you might have compiler warnings for things that are not considered best-practice. (Maybe they were fine in an earlier version of Java that the tooling still supports but are redundant in a later version.)
If you're like me and you prefer to have clean packages & classes in your IDE, here's a small tip that I somehow missed until recently.
If you place your "generated" source code in a separate source folder, which I like for ease of build process as well as organizational utility, you can also tell RAD to ignore compiler warnings for that source folder.
To do this, right-click on the source folder and go to Properties. Under "Java Compiler", check the "Ignore optional compile problems" setting, and you're done.
DougBreaux 0100002GMN Visits (3319)
As a follow-up to Part 1, here are some additional considerations for generating JAX-WS code.
The wsdlLocation property for wsimport (whether from the command-line or from Ant) is placed in the generated JAX-WS @WebServiceClient class. It's placed both in that class annotation and in the static initializer block.
If you do not specify this option, the generated code will reference the absolute "file:" path to the .wsdl file on the local machine, which obviously won't work when deployed anywhere else. Alternative ways to deal with this are:
Option 3 seems to me the cleanest and simplest with our current projects' directory conventions, so this is what I plan to use. For example:
Client vs. Server
wsimport will generate:
Of these, item 2 is not necessary for a JAX-WS service. In fact, the existence of a client class could be confusing.
An alternative to using wsimport for the service code is to generate it with RAD tooling, which if you specify that you're creating a service, will not create the client class. This will also create a "stub" service implementation class, which wsimport does not do.
The generated service implementation class will be annotated with @WebService with name and targetNamespace attributes that match those of the generated interface described in item 1. Additional attributes for the serviceName and portName will be added as well (matching the <wsdl:service> and <wsdl:binding> elements, respectively).
Strangely (to my thinking) this generated class does not actually implement the Java interface.
However, relying on RAD tooling rather than scripting may be considered to reduce the repeatability of future builds, so it might be preferable to use the wsimport approach, delete the generated client proxy, and manually create the @WebService class with the proper annotation attributes and proper methods.
In either case, the @WebService implementation class will have actual calls to business code manually added to it, so once it's generated it should not be overwritten by any future process. Thus, perhaps the better approach is to initially create the service with RAD tooling, then subsequently use wsimport if WSDL changes require code to be regenerated.
Generated Code and Source Control
An earlier convention on our project was to generate the JAX-WS client code as part of the normal build process, every time the application is built. This is a reasonable, "ideal" approach since none of this code is "source" in the conventional sense. That is, it doesn't need to be tracked for human edits or backed up for recovery purposes.
However, since theoretically behaviors could change with newer code generations, it does seem safer to version-control this code. This would also allow easy recovery of previous versions of generated code if that became necessary.
Doing so would also
Finally, even with version-controlled generated code, having scripted methods to generate the code is still useful. This ensures that code generation options are documented and repeatable. Thus, we will be creating Ant targets even if they're not used as part of the default target and automated build process.
DougBreaux 0100002GMN Visits (4958)
I imagine most folks who use Eclipse or its variants already know about this, but just in case...
User Libraries are reusable groupings of jar files that compose a particular library to be used by an application. This is a much easier way to manage the jars needed by your projects than simply adding them one-at-a-time to the Build Path and/or the WEB-INF/lib directory for execution on a local server.
Creating and Managing User Libraries
Window > Preferences > Java > Build Path > User Libraries
Add as many User Libraries as your applications require. Name them so that you can distinguish versions from each other when you work with applications that use different versions of the same library.
Use the "New" button and type a meaningful name, then the "Add JARs" button to locate specific jar files to include.
You can attach a javadoc URL to a library, which will give you more useful help within Eclipse when you're using that library. Expand the added jar file (the small triangle), select the Javadoc location line, and click the "Edit" button. You can point at either local javadoc files or a remote URL.
Similarly, you can attach a source code file or folder to a library, which will enable you to trace into its source if necessary.
Adding User Libraries to the Build Path
Project > Properties > Java Build Path
Adding User Libraries to the Execution Path (JEE Deployment)
Project > Properties > Deployment Assembly