Home » Eclipse Projects » Technology Project and PMC » Eclipse just seems wrong
| Eclipse just seems wrong [message #57546] |
Wed, 10 September 2003 01:07  |
Eclipse User |
|
|
|
I have used simple IDEs, such as Symatecs Cafe starting in 1996/1997 and
then Kawa for the past 6 or so years. I have several large projects that are
arranged into convenient directory structures that do not follow package
structure. These
projects are in a source control system and under a directory structure that
I do not wish to write class files into.
I have been looking for a new IDE, and have tried eclipse several times
(amongst others), and all of these IDEs are horribly burdensome to use. Not
only do they demand particular source structures, and paths, such as the
output directory be of particular design, but they also fail to provide many
simple and convenient operations such as "compile this file", and obvious
Source Code Control integration.
KAWA is so simple to use in large and small projects. It stays out of the
way, and lets me get my work done quickly and conveniently.
Why is it that eclipse and so many other IDEs try so hard to make sure that
the developer can not have simplicity in their development environment? I'd
like to use a supported IDE, but todate, everyone seems to think that doing
everything for the developer without still allow simple edit and compile
cycles is best.
I tried to take one of my 800 source file projects, and build it in eclipse.
I used my KAWA configuration to specify all of the needed jars to build
against. But,
it appears that since my .java files do not mirror the package structure,
that the compiler (I guess eclipse uses its own compiler [which will
guarantee compile time portability issues to other IDEs, sigh]) can not find
the classes with the expected package names (is it ignoring my package
statements...), and thus I get 5000 error messages about classes not
found...sigh...
What is the deal with simplicity? I've always used "javac -d ???" to
compile my class files into an appropriate directory where I like to keep
all my build output so that I can copy it to other machines when I need to
bring up a new build environment. Apparently everyone has gone around
compiling without -d and thus thinks you must put your source files into
package directory structures.
This interferes with source code management and history of changes. It
creates training issues about how you tell developers where classes got
moved to, and makes them rebuild their IDE environment etc...
Maybe I'm just ranting, but I sure am confused why everyone is talking about
tools which are so problematic to use. And, don't get me started about
netbeans...
gregg
|
|
|
| Re: Eclipse just seems wrong [message #57571 is a reply to message #57546] |
Wed, 10 September 2003 02:43  |
| Eclipse User |
|
|
|
Gregg Wonderly wrote:
> I have used simple IDEs, such as Symatecs Cafe starting in 1996/1997 and
> then Kawa for the past 6 or so years. I have several large projects that are
[SNIP]
> Maybe I'm just ranting, but I sure am confused why everyone is talking about
> tools which are so problematic to use. And, don't get me started about
Problem is, that what you need of eclipse, is much less than it
provides. Eclipse is a full (well, almost) featured Integrated
Development Environment. It's not just like a fancy editor, which we're
many that think KAWA is. I like eclipse, I have no problems with its
structure - nor do my coworkers. However that doesn't mean that eclipse
fits everybody! If you don't like the "features" of eclipse, and want
something simpler, then you obviously have to use a "simpler" product,
instead of stripping it, or adding "weird" options that < 5% of the
users need.
FWIW, 95% (yes, guessing) of all java developers have their source files
in a package hierarchy! Those that don't have some technical, often
preprocessing, reason for not having it in a package hierarchy.
/Brian Matzon
|
|
|
| Re: Eclipse just seems wrong [message #57594 is a reply to message #57546] |
Wed, 10 September 2003 06:27 |
| Eclipse User |
|
|
|
Originally posted by: purplehayz.earthlink.net
On 9/10/03 12:07 AM, in article bjmbgt$m7p$2@eclipse.org, "Gregg Wonderly"
<gergg@cox.net> wrote:
> I tried to take one of my 800 source file projects, and build it in eclipse.
> I used my KAWA configuration to specify all of the needed jars to build
> against. But,
> it appears that since my .java files do not mirror the package structure,
> that the compiler (I guess eclipse uses its own compiler [which will
> guarantee compile time portability issues to other IDEs, sigh]) can not find
> the classes with the expected package names (is it ignoring my package
> statements...), and thus I get 5000 error messages about classes not
> found...sigh...
The Java spec says that the directory structure and package structures are
mirrors of each other - if you're using package statements that don't match
the file structure then you're asking for problems when porting to other
Java compilers, not just IDEs.
> What is the deal with simplicity? I've always used "javac -d ???" to
> compile my class files into an appropriate directory where I like to keep
> all my build output so that I can copy it to other machines when I need to
> bring up a new build environment. Apparently everyone has gone around
> compiling without -d and thus thinks you must put your source files into
> package directory structures.
When you create a project in Eclipse, you can select an output directory -
its on the last wizard screen and also available under the build section of
the Properties pages for the project (once its created). The item is the
last item on the Source tab of that page. I use it both to separate
binaries from source and to make it easier to make jar files when I need to.
Hope that helps. Have fun! - Bob
--
Bob Hays, Computer Geek
http://www.alephnaught.com
"The difference between a craftsman and an artist is, after all, in the
mind, not the hands."
-- Bob Lewis
|
|
| |
| Re: Eclipse just seems wrong [message #57643 is a reply to message #57546] |
Wed, 10 September 2003 09:29 |
| Eclipse User |
|
|
|
KAWA is dead and will never be improved. I'm a former KAWA user.
Took awhile to get used to the way Eclipse works. But now I love it.
It's a way better tool than KAWA ever was. Give it a chance.
On Wed, 10 Sep 2003 00:07:31 -0500, "Gregg Wonderly" <gergg@cox.net>
wrote:
>I have used simple IDEs, such as Symatecs Cafe starting in 1996/1997 and
>then Kawa for the past 6 or so years. I have several large projects that are
>arranged into convenient directory structures that do not follow package
>structure. These
>projects are in a source control system and under a directory structure that
>I do not wish to write class files into.
>
>I have been looking for a new IDE, and have tried eclipse several times
>(amongst others), and all of these IDEs are horribly burdensome to use. Not
>only do they demand particular source structures, and paths, such as the
>output directory be of particular design, but they also fail to provide many
>simple and convenient operations such as "compile this file", and obvious
>Source Code Control integration.
>
>KAWA is so simple to use in large and small projects. It stays out of the
>way, and lets me get my work done quickly and conveniently.
>
>Why is it that eclipse and so many other IDEs try so hard to make sure that
>the developer can not have simplicity in their development environment? I'd
>like to use a supported IDE, but todate, everyone seems to think that doing
>everything for the developer without still allow simple edit and compile
>cycles is best.
>
>I tried to take one of my 800 source file projects, and build it in eclipse.
>I used my KAWA configuration to specify all of the needed jars to build
>against. But,
>it appears that since my .java files do not mirror the package structure,
>that the compiler (I guess eclipse uses its own compiler [which will
>guarantee compile time portability issues to other IDEs, sigh]) can not find
>the classes with the expected package names (is it ignoring my package
>statements...), and thus I get 5000 error messages about classes not
>found...sigh...
>
>What is the deal with simplicity? I've always used "javac -d ???" to
>compile my class files into an appropriate directory where I like to keep
>all my build output so that I can copy it to other machines when I need to
>bring up a new build environment. Apparently everyone has gone around
>compiling without -d and thus thinks you must put your source files into
>package directory structures.
>
>This interferes with source code management and history of changes. It
>creates training issues about how you tell developers where classes got
>moved to, and makes them rebuild their IDE environment etc...
>
>Maybe I'm just ranting, but I sure am confused why everyone is talking about
>tools which are so problematic to use. And, don't get me started about
>netbeans...
>
>gregg
>
|
|
|
| Re: Eclipse just seems wrong [message #57673 is a reply to message #57594] |
Thu, 11 September 2003 11:25 |
| Eclipse User |
|
|
|
Originally posted by: nospam.nospam.org
As far as know Eclipse is not only for Java . Why other project types need
have directory structure and project structures are mirrors of each other?
"Bob Hays, Computer Geek" <purplehayz@earthlink.net> wrote in message
news:BB8466DF.FC48%purplehayz@earthlink.net...
> On 9/10/03 12:07 AM, in article bjmbgt$m7p$2@eclipse.org, "Gregg Wonderly"
> <gergg@cox.net> wrote:
>
> > I tried to take one of my 800 source file projects, and build it in
eclipse.
> > I used my KAWA configuration to specify all of the needed jars to build
> > against. But,
> > it appears that since my .java files do not mirror the package
structure,
> > that the compiler (I guess eclipse uses its own compiler [which will
> > guarantee compile time portability issues to other IDEs, sigh]) can not
find
> > the classes with the expected package names (is it ignoring my package
> > statements...), and thus I get 5000 error messages about classes not
> > found...sigh...
>
> The Java spec says that the directory structure and package structures are
> mirrors of each other - if you're using package statements that don't
match
> the file structure then you're asking for problems when porting to other
> Java compilers, not just IDEs.
>
> > What is the deal with simplicity? I've always used "javac -d ???" to
> > compile my class files into an appropriate directory where I like to
keep
> > all my build output so that I can copy it to other machines when I need
to
> > bring up a new build environment. Apparently everyone has gone around
> > compiling without -d and thus thinks you must put your source files into
> > package directory structures.
>
> When you create a project in Eclipse, you can select an output directory -
> its on the last wizard screen and also available under the build section
of
> the Properties pages for the project (once its created). The item is the
> last item on the Source tab of that page. I use it both to separate
> binaries from source and to make it easier to make jar files when I need t
o.
>
> Hope that helps. Have fun! - Bob
>
> --
> Bob Hays, Computer Geek
> http://www.alephnaught.com
>
> "The difference between a craftsman and an artist is, after all, in the
> mind, not the hands."
> -- Bob Lewis
>
|
|
|
| Re: Eclipse just seems wrong [message #57689 is a reply to message #57618] |
Fri, 12 September 2003 05:52 |
| Eclipse User |
|
|
|
Originally posted by: purplehayz.earthlink.net
Actually, eclipse has an abstraction layer (name escapes me right now - I'm
getting old I guess:-) for source code control integration, and there are
plugins for supporting ClearCase, CCC/Harvest among others already
available. I believe someone is working on a subversion plugin now.
And yes, switching is always a chore. I used to use Emacs and JDEE....
Have fun! - Bob
On 9/10/03 6:55 AM, in article bjn3dq$cf4$1@eclipse.org, "Robert Klemme"
<bob.news@gmx.net> wrote:
>
> Bob, I totally agree with all of your statements and just would like to
> add these:
>
> It's almost always difficult to switch an existing project from one
> development environment to another. I find eclipse quite flexible though
> and IMHO it does not impose unreasonable restrictions.
>
> Eclipse has source code control integration, only that it's currently
> limited to CVS - but I'm sure others (Subversion?) will come.
>
> Regards
>
> robert
>
--
Bob Hays, Computer Geek
http://www.alephnaught.com
"Problems cannot be solved at the same level of awareness that created
them."
-- Albert Einstein
|
|
|
| Re: Eclipse just seems wrong [message #57713 is a reply to message #57594] |
Fri, 12 September 2003 15:46 |
| Eclipse User |
|
|
|
"Bob Hays, Computer Geek" <purplehayz@earthlink.net> wrote in message
news:BB8466DF.FC48%purplehayz@earthlink.net...
> The Java spec says that the directory structure and package structures are
> mirrors of each other - if you're using package statements that don't
match
> the file structure then you're asking for problems when porting to other
> Java compilers, not just IDEs.
There is no such statement in any copy of the spec I've ever read.
Section 7.2 says the following:
===========
Each host determines how packages, compilation units, and subpackages are
created and stored, and which compilation units are observable ($7.3) in a
particular compilation.
The observability of compilation units in turn determines which packages are
observable, and which packages are in scope.
The packages may be stored in a local file system in simple implementations
of the Java platform. Other implementations may use a distributed file
system or some form of database to store source and/or binary code.
===========
The following section, 7.2.1 has an example where there are source files and
class files in a parallel structure, but it also shows simple directories
with peoples initials. Clearly, the class files need to follow the package
hierarchy, but the source files can be arranged how the user likes. I.e. my
file structure is not part of the java platform!
Eclipse is broken if it does not read the package statement at the top of my
source file and use that to control what part of the namespace it is visible
in!
As it writes output files, it needs to write those out to a package
hierarchy organized directory structure, or in some other way, as the spec
suggests for putting compilation units into databases.
With its current behavior, I can not accept it as meeting the spec.
The ANT developers used to make this same nonsensical requirement. They
finally figured out what the spec really says and fixed ANT.
They argued that it helped optimize builds. The problem is that as soon as
you are building against a source code control directory structure, file
dates and times most be ignored, and everything recompiled every time.
Otherwise, when I am trying to find out how far back a bug existed,
everytime I get an older version of a source file, I don't get a recompile
because the source is older in time than the .class file. So, you're better
off just recompiling everytime, because you can't count on people having the
correct settings or the correct time on their computers compared to the
possibly shared file systems they might be building against.
Gregg
|
|
|
| Re: Eclipse just seems wrong [message #57738 is a reply to message #57571] |
Fri, 12 September 2003 16:16 |
| Eclipse User |
|
|
|
"Brian Matzon" <brian@matzon.dk> wrote in message
news:bjmh5k$qfr$1@eclipse.org...
> Problem is, that what you need of eclipse, is much less than it
> provides. Eclipse is a full (well, almost) featured Integrated
> Development Environment.
So why can't it just compile my files correctly? It seems like getting that
part right would be easy for the developers. But, I fear that the eclipse
developers just don't understand how fundamental staying out of the way of
simple operations is to good GUI design.
> It's not just like a fancy editor, which we're
> many that think KAWA is. I like eclipse, I have no problems with its
> structure - nor do my coworkers. However that doesn't mean that eclipse
> fits everybody! If you don't like the "features" of eclipse, and want
> something simpler, then you obviously have to use a "simpler" product,
> instead of stripping it, or adding "weird" options that < 5% of the
> users need.
The primary issue is that it won't compile my source files. This is
fundamental to me understanding whether I can get any benefits out of the
other features. KAWA has a vary simple extensibility mechanism using simple
command lines. One of the primary simplifications is that if a file is
readonly and I have defined a command called 'checkout', then when I attempt
to make edits to such a readonly file, kawa asks me if I want to check the
file out. If I have no check out command, KAWA asks me if I want to remove
the readonly status. Thus, when I am working offline without network
connectivity to my Perforce server, I can rename 'checkout' to 'p4checkout',
and KAWA asks me if I want to remove the readonly status. That's a simple
way to handle that issue. I can put these commands into the context menu
for files, or the project tree. Thus, I can checkout, submit, addsource etc
quite easily without crafting 20lines of XML.
> FWIW, 95% (yes, guessing) of all java developers have their source files
> in a package hierarchy! Those that don't have some technical, often
> preprocessing, reason for not having it in a package hierarchy.
Apparently there are a lot of people who have been listening to those that
think this is some kind of requirement. If the package structure is so
friendly and necessary, then why does the default javadoc output include a
list of classes by name so that you don't have to remember the package too?
Surely we're not all a bunch of lemmings following each other toward the
cliff?
|
|
|
| Re: Eclipse just seems wrong [message #57764 is a reply to message #57738] |
Sat, 13 September 2003 10:58 |
| Eclipse User |
|
|
|
Hi Gregg -- no GridBagLayout debate in this please ;)
In article <bjt9g8$gof$2@eclipse.org>, gergg@cox.net says...
>
> So why can't it just compile my files correctly? It seems like getting that
> part right would be easy for the developers. But, I fear that the eclipse
> developers just don't understand how fundamental staying out of the way of
> simple operations is to good GUI design.
> [...]
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.
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 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.
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.
Eclipse is a highly-structured IDE. It is not simply an editor with
user-defined commands on menus (as kawa is).
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.
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)
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.
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.
Later,
-- Scott
BTW: I still think BarfBagLayout sucks ;)
============================================================ ==
Scott Stanchfield scott@javadude.com http://javadude.com
I haven't gotten *any* spam since joining http://knowspam.net!
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
Visit for Java Enlightenment! http://www.jguru.com
============================================================ ==
|
|
|
| Re: Eclipse just seems wrong [message #57787 is a reply to message #57738] |
Mon, 15 September 2003 08:50 |
| Eclipse User |
|
|
|
Perhaps RTFM as all the lemmings can get Eclipse to work correctly.
On Fri, 12 Sep 2003 15:16:11 -0500, "Gregg Wonderly" <gergg@cox.net>
wrote:
>
>"Brian Matzon" <brian@matzon.dk> wrote in message
>news:bjmh5k$qfr$1@eclipse.org...
>> Problem is, that what you need of eclipse, is much less than it
>> provides. Eclipse is a full (well, almost) featured Integrated
>> Development Environment.
>
>So why can't it just compile my files correctly? It seems like getting that
>part right would be easy for the developers. But, I fear that the eclipse
>developers just don't understand how fundamental staying out of the way of
>simple operations is to good GUI design.
>
>> It's not just like a fancy editor, which we're
>> many that think KAWA is. I like eclipse, I have no problems with its
>> structure - nor do my coworkers. However that doesn't mean that eclipse
>> fits everybody! If you don't like the "features" of eclipse, and want
>> something simpler, then you obviously have to use a "simpler" product,
>> instead of stripping it, or adding "weird" options that < 5% of the
>> users need.
>
>The primary issue is that it won't compile my source files. This is
>fundamental to me understanding whether I can get any benefits out of the
>other features. KAWA has a vary simple extensibility mechanism using simple
>command lines. One of the primary simplifications is that if a file is
>readonly and I have defined a command called 'checkout', then when I attempt
>to make edits to such a readonly file, kawa asks me if I want to check the
>file out. If I have no check out command, KAWA asks me if I want to remove
>the readonly status. Thus, when I am working offline without network
>connectivity to my Perforce server, I can rename 'checkout' to 'p4checkout',
>and KAWA asks me if I want to remove the readonly status. That's a simple
>way to handle that issue. I can put these commands into the context menu
>for files, or the project tree. Thus, I can checkout, submit, addsource etc
>quite easily without crafting 20lines of XML.
>
>> FWIW, 95% (yes, guessing) of all java developers have their source files
>> in a package hierarchy! Those that don't have some technical, often
>> preprocessing, reason for not having it in a package hierarchy.
>
>Apparently there are a lot of people who have been listening to those that
>think this is some kind of requirement. If the package structure is so
>friendly and necessary, then why does the default javadoc output include a
>list of classes by name so that you don't have to remember the package too?
>
>Surely we're not all a bunch of lemmings following each other toward the
>cliff?
>
|
|
|
| Re: Eclipse just seems wrong [message #57812 is a reply to message #57764] |
Mon, 15 September 2003 15:28 |
| Eclipse User |
|
|
|
"Scott Stanchfield" <scott@javadude.com> wrote in message
news:MPG.19ccfa906d15c9e8989686@news.eclipse.org...
> 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...
|
|
| |
| Re: Eclipse just seems wrong [message #58000 is a reply to message #57812] |
Wed, 17 September 2003 10:27 |
| Eclipse User |
|
|
|
In article <bk53qr$j7n$1@eclipse.org>, gergg@cox.net says...
>
> "Scott Stanchfield" <scott@javadude.com> 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.
One of the main reasons I like the package-dir mapping structure is that
it's easy to see related classes that reside in the same package,
regardless of the tools being used. You can look at them in an IDE,
browse through using a command shell, do simple dir lists, etc.
Eclipse uses this to its advantage to make it easy to find all packages
(source dirs containing java source), allow you to add easily add
classes to a package (even if it's empty -- it had a dir structure),
browse etc. The main java package explorer view represents the structure
exactly as laid out on disk, but it collapses package names to a single
tree-entry (like com.javadude.foo.fee instead of
com
|- javadude
|- foo
|- fee
which is a display option)
I think everyone here understands what the spec says. Keep in mind that
the Eclipse compiler is *not* a standalone compiler. There are plenty of
those available. (There are some efforts underway to make it a
standalone, in which case I totally agree that the standalone version
should behave per the spec).
The eclipse compiler was written to incrementally compile code that fits
Eclipse structure, and add several new features that other compilers
don't provide (primarily additional warnings/errors to find common java
problems and style issues).
If you want/need something else, there are many other choices.
> 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 did this with several projects at workto create parallel source & test
directory structures for junit.
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 :)
> 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.
You can build *inside* Eclipse with ant as well, with your sae build
script and project structure.
1) Turn off auto build (Window->Prefs->Workbench->Perform build
automatically on resource modification)
2) Right-click on the ant build script and pick "run ant". This will
allow you to choose targets and run the build.
3) Click on the little drop-down arrow next to "running man with
toolbox" icon on the toolbar (external tools), you can choose "External
tools..." and configure it in detail.
4) You can also set a key binding for "run last launched external tool"
to re-run the last ant build.
Later,
-- Scott
============================================================ ==
Scott Stanchfield scott@javadude.com http://javadude.com
I haven't gotten *any* spam since joining http://knowspam.net!
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
Visit for Java Enlightenment! http://www.jguru.com
============================================================ ==
|
|
|
| Re: Eclipse just seems wrong [message #58176 is a reply to message #58000] |
Mon, 22 September 2003 18:00 |
| Eclipse User |
|
|
|
"Scott Stanchfield" <scott@javadude.com> wrote in message
news:MPG.19d23920aef989ad989687@news.eclipse.org...
> In article <bk53qr$j7n$1@eclipse.org>, gergg@cox.net says...
> >
> > "Scott Stanchfield" <scott@javadude.com> 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...
|
|
|
| Re: Eclipse just seems wrong [message #62240 is a reply to message #57713] |
Thu, 18 March 2004 16:57 |
| Eclipse User |
|
|
|
Originally posted by: sharples.nz.ibm.com
Gregg Wonderly wrote:
> There is no such statement in any copy of the spec I've ever read.
I'm sorry, I have to disagree with this assertion. A similar question
posted someone elsewhere prompted me to re-read this part of the JLS, and
as I read it, Eclipse *is* conforming to the spec.
The examples given in section 7.2.1 quite clearly show the directory
structure corresponding to the package hierarchy.
Capter 7 starts off by stating:
"A package can be stored in a file system (§7.2.1) or in a database
(§7.2.2). Packages that are stored in a file system have certain
constraints on the organization of their compilation units to allow a
simple implementation to find classes easily."
In other words, an implementation which stores its source units in a
filesystem does *not* have complete freedom to store them as it sees fit.
Only if the source is stored in a database does the implementation have
the freedom to organize the source as it likes - but it must provide an
export mechanism which will conform to the filesytem rules.
Furthermore, section 7.6 says:
"When packages are stored in a file system (§7.2.1), the host system may
choose to enforce the restriction that it is a compile-time error if a
type is not found in a file under a name composed of the type name plus an
extension (such as .java or .jav) if either of the following is true:
- The type is referred to by code in other compilation units of the
package in which the type is declared.
- The type is declared public (and therefore is potentially accessible
from code in other packages).
This restriction implies that there must be at most one such type per
compilation unit. This restriction makes it easy for a compiler for the
Java programming language or an implementation of the Java virtual machine
to find a named class within a package; for example, the source code for a
public type wet.sprocket.Toad would be found in a file Toad.java in the
directory wet/sprocket, and the corresponding object code would be found
in the file Toad.class in the same directory."
In other words, every top-level type *must* be found in a directory which
reflects the package of that type.
If your javac implementation allows you to use the -d option to compile
source files which do not live in a directory corresponding to the
package, then it is simply choosing not to enforce this restriction. But
the spec is quite clear that compiler implementations *are* perfectly at
liberty to enforce this restriction, so Eclipse *does* conform to the
requirements of the JLS.
--
Colin M Sharples/New Zealand/IBM
IT Architect, IBM Business Consulting Services
|
|
|
| Re: Eclipse just seems wrong [message #595135 is a reply to message #57546] |
Wed, 10 September 2003 02:43 |
| Eclipse User |
|
|
|
Gregg Wonderly wrote:
> I have used simple IDEs, such as Symatecs Cafe starting in 1996/1997 and
> then Kawa for the past 6 or so years. I have several large projects that are
[SNIP]
> Maybe I'm just ranting, but I sure am confused why everyone is talking about
> tools which are so problematic to use. And, don't get me started about
Problem is, that what you need of eclipse, is much less than it
provides. Eclipse is a full (well, almost) featured Integrated
Development Environment. It's not just like a fancy editor, which we're
many that think KAWA is. I like eclipse, I have no problems with its
structure - nor do my coworkers. However that doesn't mean that eclipse
fits everybody! If you don't like the "features" of eclipse, and want
something simpler, then you obviously have to use a "simpler" product,
instead of stripping it, or adding "weird" options that < 5% of the
users need.
FWIW, 95% (yes, guessing) of all java developers have their source files
in a package hierarchy! Those that don't have some technical, often
preprocessing, reason for not having it in a package hierarchy.
/Brian Matzon
|
|
|
| Re: Eclipse just seems wrong [message #595143 is a reply to message #57546] |
Wed, 10 September 2003 06:27 |
| Eclipse User |
|
|
|
Originally posted by: purplehayz.earthlink.net
On 9/10/03 12:07 AM, in article bjmbgt$m7p$2@eclipse.org, "Gregg Wonderly"
<gergg@cox.net> wrote:
> I tried to take one of my 800 source file projects, and build it in eclipse.
> I used my KAWA configuration to specify all of the needed jars to build
> against. But,
> it appears that since my .java files do not mirror the package structure,
> that the compiler (I guess eclipse uses its own compiler [which will
> guarantee compile time portability issues to other IDEs, sigh]) can not find
> the classes with the expected package names (is it ignoring my package
> statements...), and thus I get 5000 error messages about classes not
> found...sigh...
The Java spec says that the directory structure and package structures are
mirrors of each other - if you're using package statements that don't match
the file structure then you're asking for problems when porting to other
Java compilers, not just IDEs.
> What is the deal with simplicity? I've always used "javac -d ???" to
> compile my class files into an appropriate directory where I like to keep
> all my build output so that I can copy it to other machines when I need to
> bring up a new build environment. Apparently everyone has gone around
> compiling without -d and thus thinks you must put your source files into
> package directory structures.
When you create a project in Eclipse, you can select an output directory -
its on the last wizard screen and also available under the build section of
the Properties pages for the project (once its created). The item is the
last item on the Source tab of that page. I use it both to separate
binaries from source and to make it easier to make jar files when I need to.
Hope that helps. Have fun! - Bob
--
Bob Hays, Computer Geek
http://www.alephnaught.com
"The difference between a craftsman and an artist is, after all, in the
mind, not the hands."
-- Bob Lewis
|
|
|
| Re: Eclipse just seems wrong [message #595151 is a reply to message #57594] |
Wed, 10 September 2003 07:55 |
| Eclipse User |
|
|
|
Bob, I totally agree with all of your statements and just would like to
add these:
It's almost always difficult to switch an existing project from one
development environment to another. I find eclipse quite flexible though
and IMHO it does not impose unreasonable restrictions.
Eclipse has source code control integration, only that it's currently
limited to CVS - but I'm sure others (Subversion?) will come.
Regards
robert
|
|
|
| Re: Eclipse just seems wrong [message #595158 is a reply to message #57546] |
Wed, 10 September 2003 09:29 |
| Eclipse User |
|
|
|
KAWA is dead and will never be improved. I'm a former KAWA user.
Took awhile to get used to the way Eclipse works. But now I love it.
It's a way better tool than KAWA ever was. Give it a chance.
On Wed, 10 Sep 2003 00:07:31 -0500, "Gregg Wonderly" <gergg@cox.net>
wrote:
>I have used simple IDEs, such as Symatecs Cafe starting in 1996/1997 and
>then Kawa for the past 6 or so years. I have several large projects that are
>arranged into convenient directory structures that do not follow package
>structure. These
>projects are in a source control system and under a directory structure that
>I do not wish to write class files into.
>
>I have been looking for a new IDE, and have tried eclipse several times
>(amongst others), and all of these IDEs are horribly burdensome to use. Not
>only do they demand particular source structures, and paths, such as the
>output directory be of particular design, but they also fail to provide many
>simple and convenient operations such as "compile this file", and obvious
>Source Code Control integration.
>
>KAWA is so simple to use in large and small projects. It stays out of the
>way, and lets me get my work done quickly and conveniently.
>
>Why is it that eclipse and so many other IDEs try so hard to make sure that
>the developer can not have simplicity in their development environment? I'd
>like to use a supported IDE, but todate, everyone seems to think that doing
>everything for the developer without still allow simple edit and compile
>cycles is best.
>
>I tried to take one of my 800 source file projects, and build it in eclipse.
>I used my KAWA configuration to specify all of the needed jars to build
>against. But,
>it appears that since my .java files do not mirror the package structure,
>that the compiler (I guess eclipse uses its own compiler [which will
>guarantee compile time portability issues to other IDEs, sigh]) can not find
>the classes with the expected package names (is it ignoring my package
>statements...), and thus I get 5000 error messages about classes not
>found...sigh...
>
>What is the deal with simplicity? I've always used "javac -d ???" to
>compile my class files into an appropriate directory where I like to keep
>all my build output so that I can copy it to other machines when I need to
>bring up a new build environment. Apparently everyone has gone around
>compiling without -d and thus thinks you must put your source files into
>package directory structures.
>
>This interferes with source code management and history of changes. It
>creates training issues about how you tell developers where classes got
>moved to, and makes them rebuild their IDE environment etc...
>
>Maybe I'm just ranting, but I sure am confused why everyone is talking about
>tools which are so problematic to use. And, don't get me started about
>netbeans...
>
>gregg
>
|
|
|
| Re: Eclipse just seems wrong [message #595164 is a reply to message #57594] |
Thu, 11 September 2003 11:25 |
| Eclipse User |
|
|
|
As far as know Eclipse is not only for Java . Why other project types need
have directory structure and project structures are mirrors of each other?
"Bob Hays, Computer Geek" <purplehayz@earthlink.net> wrote in message
news:BB8466DF.FC48%purplehayz@earthlink.net...
> On 9/10/03 12:07 AM, in article bjmbgt$m7p$2@eclipse.org, "Gregg Wonderly"
> <gergg@cox.net> wrote:
>
> > I tried to take one of my 800 source file projects, and build it in
eclipse.
> > I used my KAWA configuration to specify all of the needed jars to build
> > against. But,
> > it appears that since my .java files do not mirror the package
structure,
> > that the compiler (I guess eclipse uses its own compiler [which will
> > guarantee compile time portability issues to other IDEs, sigh]) can not
find
> > the classes with the expected package names (is it ignoring my package
> > statements...), and thus I get 5000 error messages about classes not
> > found...sigh...
>
> The Java spec says that the directory structure and package structures are
> mirrors of each other - if you're using package statements that don't
match
> the file structure then you're asking for problems when porting to other
> Java compilers, not just IDEs.
>
> > What is the deal with simplicity? I've always used "javac -d ???" to
> > compile my class files into an appropriate directory where I like to
keep
> > all my build output so that I can copy it to other machines when I need
to
> > bring up a new build environment. Apparently everyone has gone around
> > compiling without -d and thus thinks you must put your source files into
> > package directory structures.
>
> When you create a project in Eclipse, you can select an output directory -
> its on the last wizard screen and also available under the build section
of
> the Properties pages for the project (once its created). The item is the
> last item on the Source tab of that page. I use it both to separate
> binaries from source and to make it easier to make jar files when I need t
o.
>
> Hope that helps. Have fun! - Bob
>
> --
> Bob Hays, Computer Geek
> http://www.alephnaught.com
>
> "The difference between a craftsman and an artist is, after all, in the
> mind, not the hands."
> -- Bob Lewis
>
|
|
|
| Re: Eclipse just seems wrong [message #595174 is a reply to message #57618] |
Fri, 12 September 2003 05:52 |
| Eclipse User |
|
|
|
Originally posted by: purplehayz.earthlink.net
Actually, eclipse has an abstraction layer (name escapes me right now - I'm
getting old I guess:-) for source code control integration, and there are
plugins for supporting ClearCase, CCC/Harvest among others already
available. I believe someone is working on a subversion plugin now.
And yes, switching is always a chore. I used to use Emacs and JDEE....
Have fun! - Bob
On 9/10/03 6:55 AM, in article bjn3dq$cf4$1@eclipse.org, "Robert Klemme"
<bob.news@gmx.net> wrote:
>
> Bob, I totally agree with all of your statements and just would like to
> add these:
>
> It's almost always difficult to switch an existing project from one
> development environment to another. I find eclipse quite flexible though
> and IMHO it does not impose unreasonable restrictions.
>
> Eclipse has source code control integration, only that it's currently
> limited to CVS - but I'm sure others (Subversion?) will come.
>
> Regards
>
> robert
>
--
Bob Hays, Computer Geek
http://www.alephnaught.com
"Problems cannot be solved at the same level of awareness that created
them."
-- Albert Einstein
|
|
|
| Re: Eclipse just seems wrong [message #595185 is a reply to message #57594] |
Fri, 12 September 2003 15:46 |
| Eclipse User |
|
|
|
"Bob Hays, Computer Geek" <purplehayz@earthlink.net> wrote in message
news:BB8466DF.FC48%purplehayz@earthlink.net...
> The Java spec says that the directory structure and package structures are
> mirrors of each other - if you're using package statements that don't
match
> the file structure then you're asking for problems when porting to other
> Java compilers, not just IDEs.
There is no such statement in any copy of the spec I've ever read.
Section 7.2 says the following:
===========
Each host determines how packages, compilation units, and subpackages are
created and stored, and which compilation units are observable ($7.3) in a
particular compilation.
The observability of compilation units in turn determines which packages are
observable, and which packages are in scope.
The packages may be stored in a local file system in simple implementations
of the Java platform. Other implementations may use a distributed file
system or some form of database to store source and/or binary code.
===========
The following section, 7.2.1 has an example where there are source files and
class files in a parallel structure, but it also shows simple directories
with peoples initials. Clearly, the class files need to follow the package
hierarchy, but the source files can be arranged how the user likes. I.e. my
file structure is not part of the java platform!
Eclipse is broken if it does not read the package statement at the top of my
source file and use that to control what part of the namespace it is visible
in!
As it writes output files, it needs to write those out to a package
hierarchy organized directory structure, or in some other way, as the spec
suggests for putting compilation units into databases.
With its current behavior, I can not accept it as meeting the spec.
The ANT developers used to make this same nonsensical requirement. They
finally figured out what the spec really says and fixed ANT.
They argued that it helped optimize builds. The problem is that as soon as
you are building against a source code control directory structure, file
dates and times most be ignored, and everything recompiled every time.
Otherwise, when I am trying to find out how far back a bug existed,
everytime I get an older version of a source file, I don't get a recompile
because the source is older in time than the .class file. So, you're better
off just recompiling everytime, because you can't count on people having the
correct settings or the correct time on their computers compared to the
possibly shared file systems they might be building against.
Gregg
|
|
|
| Re: Eclipse just seems wrong [message #595196 is a reply to message #57571] |
Fri, 12 September 2003 16:16 |
| Eclipse User |
|
|
|
"Brian Matzon" <brian@matzon.dk> wrote in message
news:bjmh5k$qfr$1@eclipse.org...
> Problem is, that what you need of eclipse, is much less than it
> provides. Eclipse is a full (well, almost) featured Integrated
> Development Environment.
So why can't it just compile my files correctly? It seems like getting that
part right would be easy for the developers. But, I fear that the eclipse
developers just don't understand how fundamental staying out of the way of
simple operations is to good GUI design.
> It's not just like a fancy editor, which we're
> many that think KAWA is. I like eclipse, I have no problems with its
> structure - nor do my coworkers. However that doesn't mean that eclipse
> fits everybody! If you don't like the "features" of eclipse, and want
> something simpler, then you obviously have to use a "simpler" product,
> instead of stripping it, or adding "weird" options that < 5% of the
> users need.
The primary issue is that it won't compile my source files. This is
fundamental to me understanding whether I can get any benefits out of the
other features. KAWA has a vary simple extensibility mechanism using simple
command lines. One of the primary simplifications is that if a file is
readonly and I have defined a command called 'checkout', then when I attempt
to make edits to such a readonly file, kawa asks me if I want to check the
file out. If I have no check out command, KAWA asks me if I want to remove
the readonly status. Thus, when I am working offline without network
connectivity to my Perforce server, I can rename 'checkout' to 'p4checkout',
and KAWA asks me if I want to remove the readonly status. That's a simple
way to handle that issue. I can put these commands into the context menu
for files, or the project tree. Thus, I can checkout, submit, addsource etc
quite easily without crafting 20lines of XML.
> FWIW, 95% (yes, guessing) of all java developers have their source files
> in a package hierarchy! Those that don't have some technical, often
> preprocessing, reason for not having it in a package hierarchy.
Apparently there are a lot of people who have been listening to those that
think this is some kind of requirement. If the package structure is so
friendly and necessary, then why does the default javadoc output include a
list of classes by name so that you don't have to remember the package too?
Surely we're not all a bunch of lemmings following each other toward the
cliff?
|
|
|
| Re: Eclipse just seems wrong [message #595211 is a reply to message #57738] |
Sat, 13 September 2003 10:58 |
| Eclipse User |
|
|
|
Hi Gregg -- no GridBagLayout debate in this please ;)
In article <bjt9g8$gof$2@eclipse.org>, gergg@cox.net says...
>
> So why can't it just compile my files correctly? It seems like getting that
> part right would be easy for the developers. But, I fear that the eclipse
> developers just don't understand how fundamental staying out of the way of
> simple operations is to good GUI design.
> [...]
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.
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 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.
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.
Eclipse is a highly-structured IDE. It is not simply an editor with
user-defined commands on menus (as kawa is).
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.
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)
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.
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.
Later,
-- Scott
BTW: I still think BarfBagLayout sucks ;)
============================================================ ==
Scott Stanchfield scott@javadude.com http://javadude.com
I haven't gotten *any* spam since joining http://knowspam.net!
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
Visit for Java Enlightenment! http://www.jguru.com
============================================================ ==
|
|
|
| Re: Eclipse just seems wrong [message #595215 is a reply to message #57738] |
Mon, 15 September 2003 08:50 |
| Eclipse User |
|
|
|
Perhaps RTFM as all the lemmings can get Eclipse to work correctly.
On Fri, 12 Sep 2003 15:16:11 -0500, "Gregg Wonderly" <gergg@cox.net>
wrote:
>
>"Brian Matzon" <brian@matzon.dk> wrote in message
>news:bjmh5k$qfr$1@eclipse.org...
>> Problem is, that what you need of eclipse, is much less than it
>> provides. Eclipse is a full (well, almost) featured Integrated
>> Development Environment.
>
>So why can't it just compile my files correctly? It seems like getting that
>part right would be easy for the developers. But, I fear that the eclipse
>developers just don't understand how fundamental staying out of the way of
>simple operations is to good GUI design.
>
>> It's not just like a fancy editor, which we're
>> many that think KAWA is. I like eclipse, I have no problems with its
>> structure - nor do my coworkers. However that doesn't mean that eclipse
>> fits everybody! If you don't like the "features" of eclipse, and want
>> something simpler, then you obviously have to use a "simpler" product,
>> instead of stripping it, or adding "weird" options that < 5% of the
>> users need.
>
>The primary issue is that it won't compile my source files. This is
>fundamental to me understanding whether I can get any benefits out of the
>other features. KAWA has a vary simple extensibility mechanism using simple
>command lines. One of the primary simplifications is that if a file is
>readonly and I have defined a command called 'checkout', then when I attempt
>to make edits to such a readonly file, kawa asks me if I want to check the
>file out. If I have no check out command, KAWA asks me if I want to remove
>the readonly status. Thus, when I am working offline without network
>connectivity to my Perforce server, I can rename 'checkout' to 'p4checkout',
>and KAWA asks me if I want to remove the readonly status. That's a simple
>way to handle that issue. I can put these commands into the context menu
>for files, or the project tree. Thus, I can checkout, submit, addsource etc
>quite easily without crafting 20lines of XML.
>
>> FWIW, 95% (yes, guessing) of all java developers have their source files
>> in a package hierarchy! Those that don't have some technical, often
>> preprocessing, reason for not having it in a package hierarchy.
>
>Apparently there are a lot of people who have been listening to those that
>think this is some kind of requirement. If the package structure is so
>friendly and necessary, then why does the default javadoc output include a
>list of classes by name so that you don't have to remember the package too?
>
>Surely we're not all a bunch of lemmings following each other toward the
>cliff?
>
|
|
|
| Re: Eclipse just seems wrong [message #595222 is a reply to message #57764] |
Mon, 15 September 2003 15:28 |
| Eclipse User |
|
|
|
"Scott Stanchfield" <scott@javadude.com> wrote in message
news:MPG.19ccfa906d15c9e8989686@news.eclipse.org...
> 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...
|
|
|
| Re: Eclipse just seems wrong [message #595254 is a reply to message #57738] |
Tue, 16 September 2003 03:41 |
| Eclipse User |
|
|
|
Originally posted by: hcs33.egon.gyaloglo.hu
Hi,
<snip>
"Gregg Wonderly" <gergg@cox.net> wrote in message
news:bjt9g8$gof$2@eclipse.org...
>
> "Brian Matzon" <brian@matzon.dk> wrote in message
> news:bjmh5k$qfr$1@eclipse.org...
> > Problem is, that what you need of eclipse, is much less than it
> > provides. Eclipse is a full (well, almost) featured Integrated
> > Development Environment.
>
> So why can't it just compile my files correctly? It seems like getting
that
> part right would be easy for the developers. But, I fear that the eclipse
> developers just don't understand how fundamental staying out of the way of
> simple operations is to good GUI design.
>
</snip>
There is a 'wontfix' bug report for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=16209
It's about Eclipse's incremental compiler. I think the developer's initially
did not want to create an extra mapping between source files and classes for
an extra goal which matters only every 10000th of developers.
However, it is an open-source project, so you have always the opportunity to
change things in it. As far as I remember there was not so many people
argues this behaviour in the newsgroups and there is not a single vote on
this bug report so I think *most* people are satisfied with this behaviour.
As a "brigde solution" you can use Ant to copy your sources in a folder
structure Eclipse likes and vica versa (I know it is not perfect but at
least you can try Eclipse with your larger projects and you can use the
original version control as well). Since Ant scripts can added as an
"external tool builder" you can do this automatically with every build.
Regards,
Csaba
|
|
|
| Re: Eclipse just seems wrong [message #595296 is a reply to message #57812] |
Wed, 17 September 2003 10:27 |
| Eclipse User |
|
|
|
In article <bk53qr$j7n$1@eclipse.org>, gergg@cox.net says...
>
> "Scott Stanchfield" <scott@javadude.com> 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.
One of the main reasons I like the package-dir mapping structure is that
it's easy to see related classes that reside in the same package,
regardless of the tools being used. You can look at them in an IDE,
browse through using a command shell, do simple dir lists, etc.
Eclipse uses this to its advantage to make it easy to find all packages
(source dirs containing java source), allow you to add easily add
classes to a package (even if it's empty -- it had a dir structure),
browse etc. The main java package explorer view represents the structure
exactly as laid out on disk, but it collapses package names to a single
tree-entry (like com.javadude.foo.fee instead of
com
|- javadude
|- foo
|- fee
which is a display option)
I think everyone here understands what the spec says. Keep in mind that
the Eclipse compiler is *not* a standalone compiler. There are plenty of
those available. (There are some efforts underway to make it a
standalone, in which case I totally agree that the standalone version
should behave per the spec).
The eclipse compiler was written to incrementally compile code that fits
Eclipse structure, and add several new features that other compilers
don't provide (primarily additional warnings/errors to find common java
problems and style issues).
If you want/need something else, there are many other choices.
> 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 did this with several projects at workto create parallel source & test
directory structures for junit.
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 :)
> 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.
You can build *inside* Eclipse with ant as well, with your sae build
script and project structure.
1) Turn off auto build (Window->Prefs->Workbench->Perform build
automatically on resource modification)
2) Right-click on the ant build script and pick "run ant". This will
allow you to choose targets and run the build.
3) Click on the little drop-down arrow next to "running man with
toolbox" icon on the toolbar (external tools), you can choose "External
tools..." and configure it in detail.
4) You can also set a key binding for "run last launched external tool"
to re-run the last ant build.
Later,
-- Scott
============================================================ ==
Scott Stanchfield scott@javadude.com http://javadude.com
I haven't gotten *any* spam since joining http://knowspam.net!
Lead author of "Effective VisualAge for Java, Version 3"
http://javadude.com/evaj
Visit for Java Enlightenment! http://www.jguru.com
============================================================ ==
|
|
|
| Re: Eclipse just seems wrong [message #595370 is a reply to message #58000] |
Mon, 22 September 2003 18:00 |
| Eclipse User |
|
|
|
"Scott Stanchfield" <scott@javadude.com> wrote in message
news:MPG.19d23920aef989ad989687@news.eclipse.org...
> In article <bk53qr$j7n$1@eclipse.org>, gergg@cox.net says...
> >
> > "Scott Stanchfield" <scott@javadude.com> 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...
|
|
|
| Re: Eclipse just seems wrong [message #596920 is a reply to message #57713] |
Thu, 18 March 2004 16:57 |
| Eclipse User |
|
|
|
Originally posted by: sharples.nz.ibm.com
Gregg Wonderly wrote:
> There is no such statement in any copy of the spec I've ever read.
I'm sorry, I have to disagree with this assertion. A similar question
posted someone elsewhere prompted me to re-read this part of the JLS, and
as I read it, Eclipse *is* conforming to the spec.
The examples given in section 7.2.1 quite clearly show the directory
structure corresponding to the package hierarchy.
Capter 7 starts off by stating:
"A package can be stored in a file system (§7.2.1) or in a database
(§7.2.2). Packages that are stored in a file system have certain
constraints on the organization of their compilation units to allow a
simple implementation to find classes easily."
In other words, an implementation which stores its source units in a
filesystem does *not* have complete freedom to store them as it sees fit.
Only if the source is stored in a database does the implementation have
the freedom to organize the source as it likes - but it must provide an
export mechanism which will conform to the filesytem rules.
Furthermore, section 7.6 says:
"When packages are stored in a file system (§7.2.1), the host system may
choose to enforce the restriction that it is a compile-time error if a
type is not found in a file under a name composed of the type name plus an
extension (such as .java or .jav) if either of the following is true:
- The type is referred to by code in other compilation units of the
package in which the type is declared.
- The type is declared public (and therefore is potentially accessible
from code in other packages).
This restriction implies that there must be at most one such type per
compilation unit. This restriction makes it easy for a compiler for the
Java programming language or an implementation of the Java virtual machine
to find a named class within a package; for example, the source code for a
public type wet.sprocket.Toad would be found in a file Toad.java in the
directory wet/sprocket, and the corresponding object code would be found
in the file Toad.class in the same directory."
In other words, every top-level type *must* be found in a directory which
reflects the package of that type.
If your javac implementation allows you to use the -d option to compile
source files which do not live in a directory corresponding to the
package, then it is simply choosing not to enforce this restriction. But
the spec is quite clear that compiler implementations *are* perfectly at
liberty to enforce this restriction, so Eclipse *does* conform to the
requirements of the JLS.
--
Colin M Sharples/New Zealand/IBM
IT Architect, IBM Business Consulting Services
|
|
|
Goto Forum:
Current Time: Fri Oct 31 11:50:02 EDT 2025
Powered by FUDForum. Page generated in 0.09123 seconds |
Home