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

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi all,

 

first of all many thanks to John for his exhaustive an enlightening E-Mail about the

background of Eclipse projects. It helps me quite a bit to understand why projects

are the way they are today.

 

In terms of providing more support for defining arbitrary team provider roots, file

system roots, source location roots and the like, I'm a little afraid that supporting

this would lead to a lot of code duplication. All these "xyz roots" would need to

have some UI in some Property pages, and I cannot quite see how these could

make use of a common code base.

 

Also, manipulating those "xyz roots" seems difficult from a user's perspective,

at least now -- I've recently set up a mixed JDT / CDT project for native libraries,

and it felt unintuitive. But perhaps that's just a limitation of the current UI, and

some smart heads could come up with simplified usability in a model as John

describes it.

 

My other comment is that I do think there is a "natural" granularity for what is

to be considered a project: for me, it's the smallest amount of self-contained

code + associated metadata, that can be re-used by a team in different context.

From that approach, it seems natural that a plugin is a project or a C++ library

is a project -- pack that project into a ZIP (which contains sources + all required

meta-info), send it to a colleague and he can immediately make use of it. With

this definition, it is also natural to have the source control root at the root of the

project, since you wouldn't want to split up self-contained units of re-usable

software among multiple repository providers. It's also natural that the "project"

is the container responsible for persisting or levelling the metadata.

 

I think that this more fine-granular understanding of what a project is, is closer

to the view that developers mostly have. The natural corrolary of this is, that

there is a demand for improved Working Sets, Team Project Sets, Project

Groups or other "super-project" artifacts (we could use the term "Solution"

for this). This two-tier approach seems most widely adopted also by other

IDE's.

 

Now this argument doesn't say that there is no need for enhanced configuration

capabilities on folder level (which I do think makes sense). But it does say that

moving from the fine-granular projects we have today to more coarse-granular

units doesn't always make sense, and that I think there is a need for a second

tier of "superprojects" or "project groups" (aka logical nesting).

 

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 John Arthorne
Sent: Tuesday, September 23, 2008 2:04 AM
To: Eclipse Platform Core component developers list.
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