Eclipse IDE - How I do my part..
I recently read - WS Setup and not to beat about it, or sound harsh et al, I just had that sweet lil’ feeling, which you get when you know that you know. So, why have this post at all then ? Well, I’m a real skeptical guy, even paranoid at that.. I had that feel good feeling for a moment, followed by an immediate moronic realization that thunder may strike and rob me of my lil’ knowledge in the context of the post. So, for the records following is a description that may remind me on how I use the IDE when I get a fresh workspace, just in case.. the thunder strikes :-|
IDE used: -
Rational Software Architect (RSA) and Rational Application Development (RAD) Platform – built on Eclipse 3.0
Plugins: -
- Team – As a repository tool for consistent change management
- JDT Core - Just touched it once to re-install the code assist support
- org.eclipse.ant.core
- org.eclipse.pde.core
- org.eclipse.tomcat
- Most other preinstalled plugins in the .metadata/plugins folder in RSA (/plugins folder in Eclipse)
File-types usually touched: -
.java, .xml, .properties, .jsp, .js, .sh, .bat, etc and some project-specific formats
Process followed when a fresh workspace is given: -
- To start with, shift the dock from the bottom position to leftmost.
- After this, dock all the development-related views like (pakage explorer, navigator, outline, hierarchy et al) onto this.
- Doing this (above explained docking) gives the entire width of screen for code-writing purposes. Also, this enables toggling any other view by single mouse-click.
- Keep server, problems, and console views docked at the bottom, since they’re needed most of the time.
- After this, open the required perspective – java, j2ee, or debug.
- Un-check the ‘build automatically’ option in the Project-menu because you don’t want the ws to build every-time you change a single line.
- If required, go to Preferences – Java – Code Style and change the formatting to what you usually practice, or to the standard that is followed at the organization / client working for.
- The next activity is creating the required CVS repositories and checking-out the code.
- Follow this by a build check to see if all the required projects are checked-out and resolved all dependencies. A clean build would ensure that.
- Next, do the database setup. Run the associated scripts for schema generation and data population.
- After this comes the server configuration part. Depending on whether the server is Tomcat, Websphere Application Server or JBoss, follow different set of steps.
- In case there is an automation plugin available, last four steps could be made redundant.
- After this, prepare the main Ear or War for deployment, if required, by right-clicking and selecting ‘Prepare for deployment’. This would generate deployment code for all the projects specified within the application.xml / web.xml.
- Following this, do a clean-buildall again and finally publish the .ear onto the server.
- Run the sanity-test bucket to see that the code hasn’t broken any existing stuff.
- Follow this by unit-test creation according to a test-case matrix provided by a business-analyst or yourself, and then running those.
- After this, if lucky, you would do the code sync-merge-checkin, or would’ve to switch to the debug-mode :-)
- After code check-in, ideally, sync the workspace again with Head-stream and do the above steps till sanity-check to ensure everything is working perfectly.
- If any new plugins are installed, start RSA with –clean option to clear the registry et al.
There are many other things to be done and points to follow in order to ensure that the development process is smooth, but the above description shall give a good enough idea to save me.. in case the thunder strikes.
[Disclaimer: If I goofed-up any of the steps, blame me not.. it would simply imply that thunder struck early !
Recent Comments