RE: [platform-core-dev] What's a project

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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

As I recall, the issue was that 'solutions'
brought with them the VCM notion of "load this one thing and you get
everything it contains". This can be handled very differently by different
VCM systems, for example CVS has modules, ClearCase has ... something else,
I can't remember.  Plus some treat these as simple configuration line
ups, while others might treat them as real elements to be themselves version
managed with accompanying file system location etc.  In my experience,
the relationship to an arbitrary VCM is one of the trickier parts of this
problem.  For example, ClearCase had a thing called Project that differed
significantly from ours, but had another element that matched more closely
but not exactly. 

> Where I believe we went wrong is
that we began attaching too much semantic baggage at the project granularity.

I agree.  For example, the .project
file itself is an indicator of this issue:
A) It should be .configuration at any
level
B) It defines a list of builders (and
natures)

The 2nd item I believe is often the
source of the artificial need for Projects, in particular in the RCP space:
if you want a builder on something, you need a Project at the directory
root, with the following problems:

1) It polutes the UI and user worflow
with either an "Add Nature" menu item or a special project creation
wizard.  

2) It requires you to write meta information
to that directory tree (the .project).  Ideally we should be able
to (optionally) manage such meta information in ways that don't require
mixing user artifacts and tooling meta information. The problem is really
around identification of which directory trees a particular builder runs
against, which could be detected in a number of ways, of which a .project
file is but one solution (e.g. an RCP app can assume all the directories
it can see it can build against, there could be property testing against
the directory contents, a file stored elsewhere listing target directories,
etc.).

Kevin

Philippe P Mulet <philippe_mulet@xxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

09/23/2008 04:42 AM

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

I agree with what you said John. Too much power on projects, we need to
find ways to allow more fine grain configurability.
In JDT for instance, we have many requests for custom settings on a per
source folder basis. This is something we are considering investing into
during the 3.5 cycle (https://bugs.eclipse.org/bugs/show_bug.cgi?id=220928).
If any are interested to come and help us, please let us know at jdt-core-dev@xxxxxxxxxxx.

John Arthorne <John_Arthorne@xxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

09/23/2008 02:03 AM

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

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
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev



Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 euros
SIREN/SIRET : 552 118 465 02430
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev