Keeping the Workspace Light

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Chris Hogue's Blog | May 31, 2007   5:00 PM | Comments (4)

Going against the defaults of a piece of software can be a frustrating experience. We've all spent our fair share of time messing around in the settings and preferences getting it just the way we like it. Then inevitably we end up re-installing the software, losing the settings, or just want it to work the exact same way across the 4 computers we use. In a lot of ways it makes sense to stick with the defaults whenever possible.

Well, the default Eclipse workspace model isn't one of them :)

When you initially create a project in Eclipse it will try to put the project artifacts directly into the workspace. The trouble is the projects most people work on are stored in an SCM system. And for me, I'd prefer to keep my local SCM directories free of my individual IDE settings and temporary working areas the IDE uses. There are also times I just want to start with a fresh workspace, perhaps including existing projects from another workspace.

Because of that I encourage people to place their projects outside of the workspace. It's not hard to do, you just have to tell it where to put the files during project creation:

As a corollary to this, a lot of people don't actually create the projects they work on. In fact, if you have 5 people working on a project, only one of them created it. The other 4 checked it out of SCM and have to get it into their IDE somehow. Again, this is simple to do while still keeping the workspace directory separate from the projects. Just use the File > Import... > Existing Projects into Workspace.

But don't let that name fool you--it doesn't mean you have to physically copy them into your workspace. Sticking with the theme of keeping the workspace separate from the projects, make sure to leave the "Copy projects into workspace" checkbox unchecked.

And in case you've not run across it yet, workspaces themselves are inherently tied to a machine and therefore not intended to be shared. They contain many settings, some of which are absolute paths to locations on the local disk. So share the projects, but keep workspaces individual.

Until next time...

Comments

• Chris - Thanks for the good article. We have been placing on ly the files under the /src directory in any given project we create in WLW. Should we also source control the .project, .classpath, and .factorypath files? Currently, developers have to recreate our projects in Workshop and point to the source in our SCM vs. importing existing projects - how can we prevent this? Lastly, how can we handle WSDLs and deployment descriptors that need to be edited, e.g., changing the endpoint for a service in a WSDL? WLW's Build Project auto-generates the WSDL and deployment descriptors with each build/deploy cycle, overwriting any changes we might have made. (Doesn't look like WLW supports the split development directory environment advertised in the WLS documentation either - correct?) Thanks!

  Posted by: hugh.rodgers@lmco.com on June 13, 2007 at 6:11 AM

• As far as what files to check into SCM, yes, you definitely want to check in the .project, .classpath, and .settings files. Those are the project definition files that will make it so other developers don't have to re-create the projects. They can just do File > Import > Existing Projects Into Workspace and it will recognize them as Eclipse projects. For a more complete list of files that should and shouldn't be checked into SCM, have a look here.

  Regarding the WSDLs and Deployment Descriptors, the deployment descriptors shouldn't be getting overwritten. There are some settings that are added when Workshop packages up the application, but those should be additive. For WSDLs, it generates the WSDLs based on the annotations in the web service. So if you want to change the URL of the service, you'd use the @WLHttpTransport annotation on the service and set the attributes appropriately there.

  Finally, Workshop actually uses the split development directory very heavily under-the-covers. It uses it to keep the source directories separate from any output in part to make it easy to do cleans. It also reduces the need to do a bunch of file-copying on build.

  So you're actually using it but may not be aware. If you're really curious you can search for the auto-generated .beabuild.txt file in the .metadata directory of your workspace. Be aware that it's regenerated on each deploy, so you don't want to modify it manually.

  Hope this helps.

  Posted by: hogue on June 13, 2007 at 8:50 AM

• Thanks for the info. On the web service annotations such as WLHttpTransport - what I really want to change is the default http://localhost:7001 I want to be able to use host aliases and different ports, such as labMachine:8001. Can this be done via annotations?

  Posted by: hugh.rodgers@lmco.com on June 13, 2007 at 2:00 PM

• Right, that can't be done through annotations. You can get the WSDL with the correct final (deployed) endpoint URL by hitting the URL of the deployed service and tacking on ?WSDL. This will replace the location attribute with the correct full URL.

  Alternatively, if you want to hand out WSDLs to clients you can also make the change to the WSDL and place it somewhere in the web content directory.

  Posted by: hogue on June 13, 2007 at 2:12 PM