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

[Philippe P Mulet <philippe_mulet@xxxxxxxxxx>]

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