Re: [jdt-ui-dev] Packages in Eclipse

["Johan Compagner" <jcompagner@xxxxxxxx>]

> > 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.

But you are talking to the Biggest VAJ supporter ever :-)
none of these point ever bother me..

That i can't say this is a package and this not ect ect. That does bother me
a great deal.
SRC folders are nice (but i don't find them nessesary by the way i preffer
the way
VAJ works, that i just can import anything i want, how i import it is not
importend
classes are alway's in the right structure ect ect)


> 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>

But it is. Because a package is a UNIT. Not a structure.


> > 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>

But filtering is never a good idee. Because it never filters the right
things
it will always be not what you want.

> > 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?

yes for every src folder you have also described the package structure
this would be a very big welkom for eclipse.


> 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