Re: [Menda-developers] On tracking Eclipse-related goodies in CVS

[Eric P. <eri...@ea...>]

BTW. just reading the blogs on this. Not so long ago I suggested to use  
the USER_LIBRARY approach to keep the list of jars small, but that was  
rejected because it would require developers using eclipse to define a  
user library. From reading the blogs it seems like it wasn't a bad idea at  
all ;-)

So an alternative is:
check-in .project and .classpath, but refer to a USER LIBRARY variable  
instead of referencing the jars directly and explain in a readme file what  
the minimal set of jars is that should go into the USER LIBARY.

-- eric.

On Wed, 07 Jul 2004 22:41:11 +0200, Eric Pieters <eri...@ea...>  
wrote:

> Hi,
>
> I'm OK with b)
> Leave .classpath, .project, .tomcatplugin, .??? out of CVS and add an  
> eclipse.readme which explains what the minimal eclipse settings are to  
> get our project up and running.
>
> When there are people using other IDE's, they can contribute by  
> providing us with an <ide>.readme which is applicable for them.
>
> With regards to the related subject, I even have the impression that  
> there are too many libs in the lib subdir anyway.
> As an example, do we need the jdbc libs in CVS? or do we just say in the  
> doc: "install your favorite jdbc lib in blablabla..."
>
> -- Eric.
>
> On Tue, 06 Jul 2004 17:25:08 -0600, Alex Rodioukov <al...@gu...>  
> wrote:
>
>> For me the question is more whether or not we want to track project's
>> meta-information in CVS. As far as I know most of us are using Eclipse
>> for development at the moment, but what if some other developers would
>> prefer to use some other IDE (IDEA, NetBeans). What if with future
>> releases of Eclipse the format of Eclipse's own configuration files
>> would change?
>>
>> Still, I'm perfectly fine with:
>>
>> a) Having Eclipse's files checked-in and tracked in CVS as long as any
>> local changes I make wouldn't show up in Team Sync perspective (so you
>> can, say, commit all the changes without going file-by-file excluding
>> .classpath and .project)
>>
>> b) Not having Eclipse's files checked-in and making local changes
>> whenever the libraries are changed (I'm building using ant anyways)
>>
>> On related subject: our current .classpath contains way too much
>> libraries for the project to be buildable from inside Eclipse. Why is
>> stuff like JDBC adapters etc is in there? I'm attaching a minimalistic
>> .classpath that works OK from Eclipse (you have to have TOMCAT_HOME
>> defined) and it's almost twice as short as the current one.
>>
>> Sorry for starting a flame war <ducks> :)
>>
>> Regards,
>>   Alex
>
>
>



-- 
----------------------------------------------------------------
Eric Pieters
http://www.epieters.org