Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [jdt-dev] Problem with top level package names and sourceforge

Well heres some stuff I've discovered after wasting another few hours on
Eclipse:

Eclipse R1: You can solve the problem with a nasty trick:
Create a Simple project in d:\projects\swapdv\swapdv, check out the CVS
repository into that project
Create a Java project in d:\projects\swapdv and then sync the project
with local contents - and voila - you have the java packages and Eclipse
doesn't complain about them.
Use the Java project to compile and run (I CANNOT debug at all in R1 - a
dialog pops up and vanishes before I can read it - any ideas?)
Use the Simple project to manage CVS stuff

Eclipse 2 (Jun2): You can't use the same hack as above because someone
has stopped projects containing projects. Thanks to that "improvement"
there is no work around I can see to the CVS sourceforge problem.

Help?!

Jonathan

-----Original Message-----
From: Vincent D Murphy [mailto:vdm@xxxxxx] 
Sent: Tuesday, June 04, 2002 12:05 PM
To: jdt-dev@xxxxxxxxxxx
Subject: Re: [jdt-dev] Problem with top level package names and
sourceforge


Jonathan Trevor wrote:
> Can anyone offer me any advice?

unfortunately i cannot offer advice.

however, i can 'chime in' and say this is a showstopper for me on many 
projects.  on cvs projects for which i do use it, i fork the tree, and 
create directory structure which mirrors the package structure.  then i 
use the fantastic jdt tooling to work for a few hours, and my 
productivity soars.  however then it comes to time for a commit, and i 
manually sync with my CVS working copy before i commit my changes; 
productivity is in the sewer.

eclipse is cool enough that this is worth my while for projects i work 
on for >5 hours/day.  however if i just want to download ant and read 
some source, i can't do it in eclipse.

however, i feel this should not be necessary.  eclipse could be more 
accomodating in this regard, simply because other tools are.  e.g. with 
javac, i can have a messy pile of files in arbitrary packages in a 
arbitrary directory structure which is totally different from the 
package structure, and it Just Works so long as those directories are on

the 'sourcepath'.  javac looks at the package statement in the class 
source, not at the folder structure, and i think this is the way it 
should be.

for the record; i think it is better style for the directory structure 
to match the package structure, but i for one have inherited source 
trees where this was not the case.  that is why i think eclipse needs to

support this.

eclipse is a great system but the false coupling between packages and 
directories is holding it back IMHO.

thanks,
-vincent

_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/jdt-dev


Back to the top