[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] Packages in Eclipse
|
see <EG>for replies</EG>
=====
Hi, (i will reply only here.. hope it has enough people listening.)
<EG>
I wish you replied to the news group... Lotus Notes just crashed on me
when I had my reply ready to be sent. Apologies if this one is
shorter and probably less friendly
</EG>
> This is an interesting issue...
i though so. :-)
> In JDT the packages of a project are derived from the project's build
> class path.
> The build class path defines the package fragment roots and all folders
> inside
> a package fragment root become packages.
Very bad practice.
I define a unit, and i call it a unit, because in all those years of
developing in
VAJ. I don't see packages as a directory structure anymore. A package
is ONE unit and should be treated like that. How it is stored is not
relevant.
<EG>
strong words <g>. It helps to look at the full building story and not
only how packages are specified to understand the rational better.
Even as a big VA/Java fans we have found that VA/Java has some
limitations that had to be addressed:
1) there is no support for a build path, in particular there
is no way to define a build order. This means
you can't define a single package across multiple
projects. You can't do package extensions
(adding a class to an existing package in another project).
BTW, this is a common practice by non VA/Java developers.
2) since there is no build order defined, you can't build
an individual project. You always have to build
the entire workspace.
3) the dependencies between projects are not explicit, there is
no representation of which projects/packages are required
to build a project.
4) support for working with JARs is limited you have to
explode and import them.
5) there is no support to organize the packages inside
project into higher level units.
To address these issues JDT introduces the notion of a build class
path per project. The build path defines package fragment roots
(source folders - project or its subfolders; JARs - internal or
external) and their order. This is overly short refer to the
API spec for IClassPathEntry for the full details.
Therefore, having a build class path per project is "goodness"
it addresses issues 1-5 and once you have a build path you also
have a definition of what a package is, i.e., the folders contained
inside a root. The notion of a class path is familiar to Java
developers. In VA/Java you also have a notion of class path
but for the run-time only.
Just having a way to define what a package is isn't sufficient
since it doesn't address how to deal with the build order, JARs etc.
Bottom line your proposal would require two concepts: a build class path
+ package specifications. I'm oposed of introducing two concepts
when one is sufficient. The empty inner packages are a presentation
and not model issue.
</EG>
> As you point out this approach has the problem with empty "inner"
packages.
> The packages view filters them out by default, but the class creation
> wizard doesn't, so you can still create new types in empty inner folders.
But because they filter them out. I can't click on it and say new Class.
We (Eric of Instantiations and i) had exactly the same problem with there
Plugin.
The strange thing now is when i say: create new package, and i make a
package
that is one less of another then that packages just won't appear. Very
annoying
<EG>
then we should not filter them out by default but provide
the user with an optional filter to hide empty inner packages.
If JDT and CodePro do this then we are still consistent.
</EG>
> A feature we have discussed but that isn't currently considered for 2.0
is
a way
> to define that a folder inside a package fragment root isn't a Java
> package
> and shouldn't be considered by the Java core infrastructure. This would
> address the empty inner packages problem. The user could tag
> them as non-packages to get them out of the way.
I think the real solution is just that you specify what the packages are
(so
not the other way around)
Just store in a meta file: This and this are packages. And read from that
file.
<EG>
I addition to a build class path?
The execlusion mechansim sketched below would be a refinement of the
build class path and is more pay as you go. By default it works and
if you want to tune further then you can do so by excluding folders.
</EG>
> FYI, we are also experimenting with "flat packages list" browsing and
have
> a prototype. The plan is to make it available for discussion on this list
> soon.
CodePro already has this. You can switch from on to the other with one
click.
But i am always i the flat mode (VAJ). Because of what i said above that I
don't
see them as a directory structure.
<EG>
yep, this sounds similar to what we have implemented and use.
Will CodePro be contributed as open source to eclipse? Otherwise I
will have to close my eyes <g>
</EG>
johan
"Johan Compagner"
<jcompagner@j-com. To: <jdt-ui-dev@xxxxxxxxxxx>
nl> cc:
Sent by: Subject: Re: [jdt-ui-dev] Packages in Eclipse
jdt-ui-dev-admin@e
clipse.org
11/17/2001 10:42
AM
Please respond to
jdt-ui-dev
Hi, (i will reply only here.. hope it has enough people listening.)
> This is an interesting issue...
i though so. :-)
> In JDT the packages of a project are derived from the project's build
> class path.
> The build class path defines the package fragment roots and all folders
> inside
> a package fragment root become packages.
Very bad practice.
I define a unit, and i call it a unit, because in all those years of
developing in
VAJ. I don't see packages as a directory structure anymore. A package
is ONE unit and should be treated like that. How it is stored is not
relevant.
> As you point out this approach has the problem with empty "inner"
packages.
> The packages view filters them out by default, but the class creation
> wizard doesn't, so you can still create new types in empty inner folders.
But because they filter them out. I can't click on it and say new Class.
We (Eric of Instantiations and i) had exactly the same problem with there
Plugin.
The strange thing now is when i say: create new package, and i make a
package
that is one less of another then that packages just won't appear. Very
annoying
> A feature we have discussed but that isn't currently considered for 2.0
is
a way
> to define that a folder inside a package fragment root isn't a Java
> package
> and shouldn't be considered by the Java core infrastructure. This would
> address the empty inner packages problem. The user could tag
> them as non-packages to get them out of the way.
I think the real solution is just that you specify what the packages are
(so
not the other way around)
Just store in a meta file: This and this are packages. And read from that
file.
> FYI, we are also experimenting with "flat packages list" browsing and
have
> a prototype. The plan is to make it available for discussion on this list
> soon.
CodePro already has this. You can switch from on to the other with one
click.
But i am always i the flat mode (VAJ). Because of what i said above that I
don't
see them as a directory structure.
johan
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
