[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
The definition of "project"
has gotten us into a lot of trouble over the years. I'd like to offer
some thoughts on what projects meant in the past, and what they might mean
in the future.
The first Eclipse prototype had a fairly
traditional structure of medium-grained "projects" aggregrated
into "solutions" in the style of VisualAge or Visual Studio.
For reasons I can't remember, this two-level structure was dropped
in favour of the simpler structure in Eclipse 1.0 of projects, folders,
and files. However, the vision of projects was much closer to the
granularity of solutions in the old model. The idea was that developers
would have a small number of potentially very large projects. Each project
could have multiple natures/builders for the various types of content in
the project. JDT had the notion of "source folders" for signifying
roots of Java package hierarchies within the project, and as a tool for
organizing large wads of code into separate groups.
Where I believe we went wrong is that
we began attaching too much semantic baggage at the project granularity.
For example JDT build paths were configured at project granularity, version
control was configured at the project level, Eclipse plug-ins were mapping
1-1 with projects, physical file system locations were configured at the
project level, etc. In short, whenever plug-ins wanted to attach semantics
to a hierarchy of resources, they typically attached these semantics at
the project level.
The effect of these additional layers
of semantics was that end users were forced into using projects at a much
more fine-grained level. If they had two groups of code that needed different
Java build paths, they had to be in two separate projects. If code came
from various repository sources each of those sources had to be separate
projects. If they were deploying to a different app server they had to
be in different projects, etc. We soon discovered end users had workspaces
with *hundreds* of projects where we only imagined a small handful, because
they were forced into subdividing their source tree into more projects
for one reason or another. Also, these competing project-level semantics
sometimes dictated conflicting decompositions of the source tree into projects
at different levels in the hierarchy. For example, a user may have
a large tree of code in a single project because the version control system
dictates it, but within that tree they need different Java build paths.
If I was starting over, I would attach
an absolute minimum level of semantic significance, if any, to projects.
After all, unlike folders and files, "project" is an artificial
term that is liable to be interpreted differently by any two users or plug-in
developers depending on the structure of their legacy code, what IDEs they
have used, etc. I imagine instead having a tree of only folders and
files, but any folder can have semantics attached to it, such as "file
system root", "version control root", "build path root",
etc. A user or plug-in would be able to attach those semantics at
any level in their code tree. One organization may have a large tree with
the version control root at the top because they are all stored in the
same repository, but introduce builders and other concepts and finer granularity.
Another may want to configure their Java build path at the top of the hierarchy,
but then pull in code from various file system locations with several file
system roots lower down.
The second most problematic definition
to nail down is "workspace", but I'll leave that for a separate
discussion...
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx
09/19/2008 01:34 PM
Please respond to
"Eclipse Platform Core component developers list."
<platform-core-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Platform Core component
developers list." <platform-core-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [platform-core-dev] What's a project |
|
Hi Eric,
from what you say, it seems that
you are talking about the Application Layer
that Michael mentioned (and that
doesn't really exist in Eclipse today).
Multiple clients can have multiple
"views" or "perspectives" on what they
need from the Project. I think
that this "view" is similar to what a project
Nature is today, but more powerful
since it would also allow resource
filtering, and adding application
layer defined functionality.
It seems that you'd really like
this view / nature to be extensible.
I'd think, though, that the most
basic underlying functionality of
a project (that is : defining
a resource set and persistable meta
data on it) should not be affected
by application specific interpretation.
Cheers,
--
Martin Oberhuber, Senior
Member of Technical Staff, Wind
River
Target Management Project Lead,
DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From: platform-core-dev-bounces@xxxxxxxxxxx
[mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Eric
Frey
Sent: Friday, September 19, 2008 7:15 PM
To: platform-core-dev@xxxxxxxxxxx
Subject: [platform-core-dev] What's a project
I think that one of the points
that came up in the Telecon today that we seem to be in agreement about
is that we need to have a common definition of "what's a project".
I'm not proposing a definition
here, as I think we have to make a "project" an extensible concept,
so that one definition of Project
can be applied to multiple
types of projects (Java, C++, Python, Web, RTL…). I'd propose that
we aim for Project becoming a base class, with a extension point, so that
users will be able to extend the functionality of a projects. I realize
that there are a host of inherent problems involved with making this a
reality, but I'd like to suggest that we at least try and come up with
something in this area. Similarly, I hope that a CDTProject might
also be extensible.
Any extensible abstraction of
Project also must address integration into the Project Explorer
view.
There are lots of other things
I'd like to see in Project, but they really are only useful to users such
as nVidia if we can get at them to extend them.
Cheers,
Eric
This email message is for the sole use of the intended
recipient(s) and may contain confidential information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are
not the intended recipient, please contact the sender by reply email and
destroy all copies of the original message.
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev