| State of the Art Multi Project setup [message #137134] |
Mon, 26 January 2004 11:52  |
Eclipse User |
|
|
|
Originally posted by: mbrozowski.nc.rr.com
Though I've been using eclipse a while I have yet to set up a large
development project. Is there anything I can read on the best way to set up
a significant codebase in terms of the eclipse projects I need. The project
I have has a lot of different parts that use different build tools other
than just java compiling (like Castor, and SableCC as well as a little C++
JNI code, and an ANT task or two) What's the best way to break up the pieces
into projects?
The code I have is an existing code base that I want to 'refactor' into
eclipse projects so I can take advantage of Eclipse's tool sets. Anyone
know of any project organization 'Design Patterns'?
Thanks in advance,
Matt Brozowski
|
|
|
| Re: State of the Art Multi Project setup [message #137270 is a reply to message #137134] |
Tue, 27 January 2004 00:32  |
| Eclipse User |
|
|
|
Personally, I dislike using an IDE specific build setup. I much prefer a
master ant control build script that calls into individual sub project build
scripts. The master simply is a way to run the full or partial build process
of one or more sub projects. I define any number of targets, based on what I
wish to do in the master. Then, each sub project build script has the usual
dev build, nightly full clean build (with vss/cvs get, etc), integration
build, unit test, javadoc, packaging, deploying if needed, etc.
The benefit, so long as the build scripts are set up using relative paths as
they should be, is you can move the entire project to any platform (at least
the java portion) and build it the same. We are using the Eclipse IDE
built-in process and I have had to tweak a numer of local files to get the
various projects to work with someone elses setup. It's a pain in the arse.
If you center around the build process, whether using make, ant, maven, etc,
at least you are free to use any dev tools necessary without regard to how
each may do its build. More so, it is much easier for team developers around
the world to work with the same project. With the build process out of the
way, you write code and simply invoke a target on the master build script.
Without quick-key access to varous builds, it's time consuming to have to
click on the specific build project, then click the Build menu item each
time. I do like the inline compiling, that is great, but if you have to
package things up, such as ejbs, it can get a bit bogged down.
At least this is my experience. Many like it, many don't. For those that
come from jbuilder, netbeans, etc they tend to prefer the IDE way of doing
things. Me, I like to not be dependent on things like the IDE, the platform,
etc.
"Mathew Brozowski" <mbrozowski@nc.rr.com> wrote in message
news:bv3ghj$cnf$1@eclipse.org...
> Though I've been using eclipse a while I have yet to set up a large
> development project. Is there anything I can read on the best way to set
up
> a significant codebase in terms of the eclipse projects I need. The
project
> I have has a lot of different parts that use different build tools other
> than just java compiling (like Castor, and SableCC as well as a little C++
> JNI code, and an ANT task or two) What's the best way to break up the
pieces
> into projects?
>
> The code I have is an existing code base that I want to 'refactor' into
> eclipse projects so I can take advantage of Eclipse's tool sets. Anyone
> know of any project organization 'Design Patterns'?
>
> Thanks in advance,
> Matt Brozowski
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02968 seconds
Home