I am not advocating one big Eclipse project. I don't see how moving a
file from one source tree to another is that difficult. You would
typically be moving code developed for a product that has been deemed
generally useful so you move it to a project for a common or shared
library.
If the code is in a non-shared project then it is not available for use
by other projects. If someone does want to re-use the code then the code
can be moved to a shared project. The bar for making changes to shared
code is higher than for project specific code and it would seem helpful
to know which code was shared or common by the project it was in. I
realize the information is in the ant script but the developers know
what project directory code is in; having to look in the ant script to
see who is using it is an extra step.
There are plenty of open source projects out there and you can look at
their directory structures for ideas. I haven't run across any projects
that are using your technique for mapping a repository to projects. I
have worked with clearcase, sourcesafe, CVS and subversion and have
never felt then need to have a monolithic company-wide source tree in
the repository in order to encourage re-use. Re-use of classes that
aren't intended to be re-used or designed for re-use is not really a
good thing. I also don't see how code being together in repository
encourages re-use if people are working on projects with a different
structure.
To your point regarding validating the ant script, I agree that people
should build with an ant script prior to checking their code in.
> -----Original Message-----
> From: Meme Bag [mailto:memebag@yahoo.com]
> Sent: Monday, April 04, 2005 7:19 PM
> To: users@subclipse.tigris.org
> Subject: RE: Re: Problem with "Use specified module name:"
>
>
> --- "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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
Received on Tue Apr 5 09:55:28 2005