[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
|
[news.eclipse.technology] Re: Eclipse just seems wrong
|
"Scott Stanchfield" <scott@xxxxxxxxxxxx> wrote in message
news:MPG.19ccfa906d15c9e8989686@xxxxxxxxxxxxxxxxxxx
> Hi Gregg -- no GridBagLayout debate in this please ;)
Tempting, but I've got my problems solved with layout managers...
> Eclipse does compile files *correctly* as follows:
> 1) "Auto build" -- If you want Eclipse to automatically build, you need
> to follow the way it lays out projects. They set this up to use the
> fairly common practice of matching the source file directories to the
> package names. While this isn't necessary when using javac -d, it really
> is the way most folks have structured their source layouts.
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!
> Those folks aren't "lemmings", as it's a common structure that that
> actually works. If it didn't work (or was significantly more trouble to
> make work), then "lemmings" might be appropriate. In fact, this
> structure allows you to reuse class names (if appropriate/necessary).
> (While I personally try to avoid reusing class names, there are some
> cases where it may be more meaningful to use the same name in two
> different packages.)
I use package hierarchies on many small projects. But, on my largest
projects, at 800+ source files, have differing structure requirements for a
wide range of reasons. 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.
> I don't know how your project is structured, but one should be able to
> write a simple script or java proggie that moves classes into the common
> package structure by scanning for a package statement and moving the
> file. I'd suggest walking through the "Getting Started" guide to get a
> feel for eclipse and see if it might be useful to you before putting in
> any effort for this, though.
This is a trival thing to do mechanically, yes...
> 2) "Ant build" -- you can turn off auto build and use an ant script to
> compile, inside of which you can place any commands you like.
> Granted, ant is a bit more work than just entering a command line.
We already build the project outside of the IDE with ANT, and ANTdoes not
complain about the structure of the class files. It just compiles them and
moves on.
> Eclipse is a highly-structured IDE. It is not simply an editor with
> user-defined commands on menus (as kawa is).
I've never said otherwise. I am only stating the simple fact that there are
people who will need to use their IDE to do simple things quickly. Any IDE
that can't do simple things easily, I, and many others that I've heard gripe
about this, will have a hard time using effectively.
Kawa is much more than an editor. It just depends on how you do your work.
Clearly people are adapting-to/adopting eclipse's mode of use. I'm not
suggesting that this is entirely a bad thing. I'm just ranting about
something that I think is an obvious bug in eclipse (the compiler ignoring
the package statement and using the directory instead for the package name).
> This structuring allows some very interesting auto build possibilities,
> as build-tool writers can make certain assumptions about how things are
> laid out. By making assumptions, the end users don't have to do as much
> configuring in command-lines or property sheets; they simply lay out the
> code in a common manner.
You are lecturing to someone who is intimately familiar with all kinds of
software design and development tools. I've designed languages, parsing
tools, and a wide gammit of software applications as well as operating
systems.
I am looking for solutions to eclipses bugs that will make it more usable,
not for lectures about how to develop software.
> This is also one of the features that allows Eclipse to do much more
> than kawa ever could, including when it comes to searching and indexing.
> You mention javadocs creating an index. Eclipse has even better
> navigational support -- try
>
> control-shift-t (or the "Open Type" button on the toolbar)
This is the kind of stuff, buried into IDEs, that should be on the desktop.
Why should I have to have an IDE configuration, have it installed, and know
how to drive the IDE just to find documentation?
> There you can just enter a class name w/o the package name, making it
> easy to find any class. From there, you can navigate between source
> using hyperlinks, search for refs/impls/decls, etc.
The more funny thing is that eclipse is broken here too. It has yanked the
package name out of the source file to build the index, and wrongly believes
that this is where it should go look for the soruce file when I select it.
> Bottom line -- if you don't like Eclipse, don't use it. Hopefully no one
> is forcing you. Plenty of folks find it very productive, but not
> everyone.
I'd like to try eclipse out, but unfortunately, my two production software
packages that I spend most of the time working in, are too much for eclipse
to handle. Its design assumes things that are unrealistic.
> BTW: I still think BarfBagLayout sucks ;)
Good, I just use GridbagLayout with my Packer (packer.dev.java.net) class
and it works just fine. Don't have to mess with layouts anymore. Works
first time, everytime...