--- "Deadman, Hal" <Hal.Deadman@Tallan.com> wrote:
> If you want to break the code base up into multiple
> projects then the
> shared code would go in one project and the product
> specific code for
> each product would go into its own project with a
> dependency on the
> shared code project. The projects in Eclipse would
> map to a directory in
> subversion. The shared code project might be more
> than one project (one
> per jar produced) or a single project that produced
> multiple jar
> artifacts for the other products to use.
I don't understand. We have one tree for source code
and one tree for test source code. All products are
built from subsets of the source code tree. There is
no "product specific code".
Do you mean make one mammoth Eclipse project that
contains all of the source code (since all of it is
shared) and use Eclipse project dependencies to share
it to product specific projects?
> What is the advantage you get out of having a single
> source tree for all
> the products when it seems like people work on them
> and think of them as
> different projects?
It makes sharing source code easier. There are no
artificial boundaries to which files are available to
which products. If I decide Product X could re-use a
class from Product Y, I just add it to Product X's ant
script. There's no need to move it from one source
tree to another.
I think requiring all developers to create a mammoth
Eclipse project that contains all of the company's
source code just to work on one product isn't a
workable solution for us. I have an Eclipse project
that contains all of our code and it drags Eclipse to
its knees while building, searching or browsing.
The other down side is that you aren't verifying the
ant script if a product's Eclipse project depends on
another Eclipse project that contains everything.
With our current configuration ant problems are caught
up-front because each Eclipse project only sees what
ant fetches.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on Tue Apr 5 09:18:32 2005