[news.eclipse.technology] Re: Eclipse just seems wrong

["Gregg Wonderly" <gergg@xxxxxxx>]

"Scott Stanchfield" <scott@xxxxxxxxxxxx> wrote in message
news:MPG.19d23920aef989ad989687@xxxxxxxxxxxxxxxxxxx
> In article <bk53qr$j7n$1@xxxxxxxxxxx>, gergg@xxxxxxx says...
> >
> > "Scott Stanchfield" <scott@xxxxxxxxxxxx> wrote in message
> > > Eclipse does compile files *correctly* as follows:
> > > [...]
> >
> > I get the fact that you (and others) think that this is the way that
> > everyone lays out their source trees.  That's not the point.  The point
is
> > that the compiler is flatout ignoring my package statement in my source
> > file.  That is counter to the java specification, period!
>
> Again, Eclipse structures it the "common way" for several reasons.

Yes, you've stated these reasons repeatedly.  I still am only asking why the
compiler can't just do the right thing?

I havetrees of edited source files from branches of our source tree that
make wide and varying changes.  As part of my integration testing, I
sometimes take my production build environment, in the IDE, remove the
production subtree(s), and add in the altered branch(es).  I can then build,
and reuse the runtime parameters (many of which are extensive for Jini and
RMI applications) to test my changes in a particular environment without
having to worry about changes in the environment if I had cloned the project
to do my development).

Sometimes during development, I take pieces of many different packages and
add them into particular project folders (in the IDE) with particular names
of my choosing to create a single build environment where I can double click
on stack back trace lines to get to the source of lots of different
packages.  I don't need a large package name based tree structure to
navigate through.  I don't need a wide 'navigation pane' because of these
huge names or very deep directories. I want to be able to get to the files I
need, when I need them, and when I don't need them anymore, I want to just
be able to click on the tree node and hit the delete key.  That means delete
this projec tree from my configuration, not delete all the files from the
disk as one more eclipse newby found the nice and cool eclipse IDE would do
to him!

I think that while this is an interesting argument, it seems pointless to go
on about why the files should be in the same directories as the package
names.  For the same number of reasons that you argue that they should, I
can argue that they shouldn't.  There seems to be a deficiency in the
compiler design that has caused this anonmoly to remain in place.

When I create a new project and try and insert files into that project,
there are errors in the list indicating that the package names do not match
the file structure.  So, clearly, this is information that the compiler has
available to it.  The 'package' statement is part of the specification.  If
the compiler ignores that statement, it is not compliant, period.  The spec
provides freedom for how the runtime environment can find .class files.  It
does not provide freedom for the compiler to ignore the package statement,
period!

> > One of the primary reasons I don't want to
> > restructure them, just for eclipse, is related to source code
management.
> > It's just not an option to rearrange the tree.
>
> Which SCM are you using? Many have a way to move/rename files. Worst
> case, you'd have "older" history in a different structure. In practice,
> this isn't really that big of a deal, as most folks don't tend to spend
> much time actually looking at old code. The only trick is to make sure
> it's done at a good time...

I use Perforce, and yes, I can relocate files.  I can retrain developers,
update build scripts and do a whole bunch of work.  The important thing is
that noone pays the bill for me to do that.  It is superfulous work that is
unneeded.  IDEs must make the least number of requirements on the users to
provide the most flexibility and eliminate dependencies on particular
behaviors.  Many of the things that eclipse requires you to do are like OO
coupling.  The tools demand that it have knowledge of certain things that
couple it to my development environment, and vice versa.  It doesn't need to
have that much knowledge.  What it needs is to provide interfaces where I
can provide it the knowledge that it needs.  One of these pieces of
knowledge is the package.  The spec says that comes from the package
statement...

> Again, I'd suggest trying out Eclipse with simpler projects (you
> mentioned you have some that follow the common structure) to see if you
> think the functionality is worth the change. If not, it's all moot
> anyway :)

I KAWA it takes me less than 1 minute to create a new project and start
going.  In Eclipse, I have 10 minutes of dialogs to look through and try and
make sense of because it is trying to couple itself to everything that it
can.  It needs to be much less intrusive, and much more introspective.  All
the information is in the source files, period.

Kawa has a very simple add files to project mechanism.  You can add 1 or
more files in a directory, or add a whole tree under a particular directory.
It makes note of the packages (this is the first thing in the source file,
if present, and you can stop looking at the first keyword that is not
'package'), and builds folders for each directory containing 1 or more .java
files.  Simple, and effective.  I imagine that when I save the file, it
reparses it to find the package statement, and also to build the complete
object tree for the navigation pane at some point.  But, I don't know when,
and I don't care.  It just works as it should.

> You can build *inside* Eclipse with ant as well, with your sae build
> script and project structure.

I want to make changes to a single class file, hit F7, see the build finish,
and then press F4 or F5 to run the application.  I don't want to rebuild the
whole thing with ant each time.  Our ANT builds build the entire project
because with SCC you can not count on dates/times to be coherent.  Thus,
just selecting the ant build from the menus is not an option...

This will be my last post on this subject.  Clearly, people are ready to
justify inflexibility and overloaded demands from an IDE as progress...  And
we wonder why the cost of software is soaring and why jobs are being moved
overseas...