menda-developers

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

[Alex R. <al...@gu...>]

Hi all,

I'd like to suggest to move Eclipse-related files from the root of menda
project in CVS to somewhere else (or rename them). We've had a long
discussion with Fernando regarding this, without reaching any conclusions.

My argument against having them under menda/ is when local changes are
made in Eclipse environment (being project or classpath settings) one
has to jump through the hoops to check those in to maintain consistency
(and you'll keep on seeing them under Team Sync perspective).

Example: you add additional jars to Java Build Path/Libraries, you have
to check them in and to check modified .classpath in. If you have
Source/API docs attached to said jars you would have to modify
.classpath manually (removing local references), check it in, put your
settings back.

PITA, if you'll ask me.

Suggested solution: in order to maintain developer-friendly experience
we can rename .project to eclipse.project and .classpath to
eclipse.classpath (and whichever .* eclipse related files we have) and
move it to documentation folder, adding instructions on how to set-up
Eclipse using those files.

Any opinions on the subject are very welcome :)

Regards,
  Alex

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

[pope <apo...@ez...>]

Hi!

You have read the blogs regarding the including of .classpath and 
.project into CVS :-).

[Have a nice day] / [10x]
---
Pope
---
<<There are only solutions...>>



Alex Rodioukov wrote:

>Hi all,
>
>I'd like to suggest to move Eclipse-related files from the root of menda
>project in CVS to somewhere else (or rename them). We've had a long
>discussion with Fernando regarding this, without reaching any conclusions.
>
>My argument against having them under menda/ is when local changes are
>made in Eclipse environment (being project or classpath settings) one
>has to jump through the hoops to check those in to maintain consistency
>(and you'll keep on seeing them under Team Sync perspective).
>
>Example: you add additional jars to Java Build Path/Libraries, you have
>to check them in and to check modified .classpath in. If you have
>Source/API docs attached to said jars you would have to modify
>.classpath manually (removing local references), check it in, put your
>settings back.
>
>PITA, if you'll ask me.
>
>Suggested solution: in order to maintain developer-friendly experience
>we can rename .project to eclipse.project and .classpath to
>eclipse.classpath (and whichever .* eclipse related files we have) and
>move it to documentation folder, adding instructions on how to set-up
>Eclipse using those files.
>
>Any opinions on the subject are very welcome :)
>
>Regards,
>  Alex
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Menda-developers mailing list
>Men...@li...
>https://lists.sourceforge.net/lists/listinfo/menda-developers
>
>
>  
>

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

[Fernando M. <fm...@de...>]

http://weblog.isallineed.net/javagui/archives/000096.html

Are you refering to this?

Well, opinions seem to be quite different...(note Spring developer Colin 
Sampaleanu's answer).
I personally prefer the Spring approach: keep .project and classpath in CVS 
without any specific plugin (nature) in .project or Source/Api in the 
.classpath.
That way it will work for everybody checking out the project.
If you do want to try to use some plugin, that is your bussiness, just don't 
commit it back to CVS, since it could break other people's build.
Having a eclipse.project and eclipse.classpath, doesn't seem to resolve the 
general problem, because if for example someone commits changes to 
eclipse.classpath and you allready have your customized .classpath, you'll 
have to merge (MANUALLY) the new changes from eclipse.classpath to your 
.classpath.
The fact that maven can generate the files is not so revelant, because not 
everybody will want to use maven just to have it generate files for eclipse.
Out of curiosity, is Maven able to generate files merging them with allready 
existing files (which could have your customized plugins/Sources/Api) ?

Fernando

On Tuesday 06 July 2004 09:25, pope wrote:
> Hi!
>
> You have read the blogs regarding the including of .classpath and
> .project into CVS :-).
>
> [Have a nice day] / [10x]
> ---
> Pope
> ---
> <<There are only solutions...>>
>
> Alex Rodioukov wrote:
> >Hi all,
> >
> >I'd like to suggest to move Eclipse-related files from the root of menda
> >project in CVS to somewhere else (or rename them). We've had a long
> >discussion with Fernando regarding this, without reaching any conclusions.
> >
> >My argument against having them under menda/ is when local changes are
> >made in Eclipse environment (being project or classpath settings) one
> >has to jump through the hoops to check those in to maintain consistency
> >(and you'll keep on seeing them under Team Sync perspective).
> >
> >Example: you add additional jars to Java Build Path/Libraries, you have
> >to check them in and to check modified .classpath in. If you have
> >Source/API docs attached to said jars you would have to modify
> >.classpath manually (removing local references), check it in, put your
> >settings back.
> >
> >PITA, if you'll ask me.
> >
> >Suggested solution: in order to maintain developer-friendly experience
> >we can rename .project to eclipse.project and .classpath to
> >eclipse.classpath (and whichever .* eclipse related files we have) and
> >move it to documentation folder, adding instructions on how to set-up
> >Eclipse using those files.
> >
> >Any opinions on the subject are very welcome :)
> >
> >Regards,
> >  Alex
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >digital self defense, top technical experts, no vendor pitches,
> >unmatched networking opportunities. Visit www.blackhat.com
> >_______________________________________________
> >Menda-developers mailing list
> >Men...@li...
> >https://lists.sourceforge.net/lists/listinfo/menda-developers
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Menda-developers mailing list
> Men...@li...
> https://lists.sourceforge.net/lists/listinfo/menda-developers

-- 
Trouble with Windows: reboot, Trouble with Linux: be root

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

[Alex R. <al...@gu...>]

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

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

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

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

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

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

[Alex R. <al...@gu...>]

Fernando Martins wrote:
> http://weblog.isallineed.net/javagui/archives/000096.html
> 
> Are you refering to this?

There's also a nice rant here:
http://weblog.isallineed.net/javagui/archives/000098.html

Regards,
  Alex