[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
BTW,
as we are talking about "Solutions" (superprojects or
project groups similar to team project
sets or working sets)... the challenges in getting a
"Solution" materialized out of (multiple)
CM Repositories seems to be exactly the task that the
Buckminster project is trying to
solve ("Workspace Materialization"), isn't
it?
So if we have a solution for workspace materialization now,
perhaps it's time to reconsider
the concept of adding "Solutions" as a second tier to
projects?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
> 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