[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
This has been an awesome discussion. I'm learning a lot about
the history of resources and the experiences others, i.e. non CDT users, have
had and what their needs are.
The main trouble we run into with the CDT and I can see
similar things on the team side, is that we often leverage tools outside of
Eclipse to do stuff. Those tools have no idea what semantics Eclipse has applied
to the file system, they only see the file system. One of the major objectives I
have for the resourse work is make it easier to integrate these tools, and to
make it easier to map resource concepts to the concepts these tools need to work
with.
I keep coming back to the layering architecture Michael talked
about. I'm not sure there are three layers but definitely two. At the base,
I see the "file system". I put it quoted because it doesn't need to be a
traditional file system, but it has to manage storing and retrieving of content
and hierarchy. EFS is a great start at this and I'm sure we can grow that to
cover more requirements.
I think we are all agreeing that projects are troublesome and
I'd almost like to get rid of the concept altogether. What I think we need are
views on the "file system" that we can associate semantic meaning, much like
natures tend to provide. CDT resources have certain build and view semantics,
JDT resources have their own, but often you want to store artifacts from both in
the same "file system" locations, e.g for source control reasons, but to have
different views on that file system for different reasons.
As I mentioned on the call, I'm a big fan of the ClearCase
Remote Client for Eclipse plugin from the Rational guys. It provides a
navigation view of the resources from the source control system as they sit on
the file system and you can interact with them in terms natural to the source
control system. From there you can import resources into your workspace and then
work with those in the views that interpret the semantics applied to those
resources. Some projects, like the CDT then need to go from the resource
semantic views back to the file system to run compilers and debuggers for
example. If we make the file system a first class citizen and make it easy to
map back and forth from IResource to IFileStore (for example), integrations
would be easier to build.
And of
course, we need a backwards compatability layer to ensure projects created with
3.x can migrate smoothly into this new world. While having the new world similar
to the old one makes this layer easier to build, we shouldn't be bound by it.
But at the same time, we shouldn't do anything that prohibits that layer from
being built either.
Cheers,
Doug
Ok more history (at the risk of
rewriting it):
As I recall,
Project References were supposed to allow us to build arbitrary "container
projects of projects". The notion was that you didn't need just two
levels of Solution->Project but could have N levels (because of course as
computer scientists, N is always better than 2 :> ). I think there
was also the notion that it could allow more flexible mapping to the structure
of different VCMs. Solutions or any kind of configuration is 90% VCM and
10% workspace, and I think this is one reason why we backed away from them in
the resource model.
But project
references only refer to things you already have, while as they needed to also
encode how to resolve the references within a specific VCM. We looked at
modifying Project References to encode this in a VCM specific manner, but
instead settled on Project Set Files. I can't recall exactly why we
didn't go the Project Reference route, it might've been simply for expediency.
If you look at the entries in the PSF, these are essentially what
Project References might've become. Now, sadly, Project References are
kind of useless.
One thing I think
we got confused around was that resources mapped to on-disk structure, and
projects in particular mapped to directories (with accompanying special . meta
files) but these kinds of containers weren't something you'd necessarily want
a directory or file for. They were simply configuration lineups. Whether
or not they were versionable themselves also tends to play into whether you
need on-disk representation (something to version), and this is VCM dependent.
So if your resource model is really about representing the file system,
you have this disconnect around things like configurations and working sets
which might not have any such representation.
I think it would be valuable to revisit having configurations
as first class objects. Project Set Files are not really first class;
they're via import/export and don't show up in the explorer. Now that we
have a large number of VCM providers and the wisdom from that, I am more
confident of a correct solution.
Working Sets are also interesting but not necessarily the same
thing. Clearly they attempt to group resources. An advantage
though is that the grouping can be orthagonal to the project and configuration
structure. There might be some good intersection here though (e.g. a way
of talking about groups of resources, of which configuration is one
instance).
Finally, I would like
to point out that although we've grown used to it, the user experience right
now around projects is terrible. Its brutal for new users that the first
thing they must do before writing one line of java code is to create a
structure for the sole purpose of pleasing the tooling. This is
particularly bad for RCP apps. Imagine a photo organizing/authoring app
(hey, like the e4 demo! :>) whose first step is "make an album". Its
artificial and shows our architecture leaking through. For that reason I
liked what John was describing in terms of being able to manage these roots
independently. I agree that forcing people to manage N of these is
difficult, but there may be ways of streamlining the user experience.
What I liked though was the notion that identifying the roots is the
task ("tell me where you want to store your photos") vs. creation of a root
("create an album before you can get started").
Regards,
Kevin
"Michael Valenta"
<eclipsemfv@xxxxxxxxx> Sent by: platform-core-dev-bounces@xxxxxxxxxxx
09/24/2008 09:04 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 |
|
Martin,
It's not just a question of being able to populate your
workspace. One of the advantages of the current architecture is that, because
of the one-to-one relationship between projects and repository providers, it
is possible to have a fairly tight integration between views that are project
based and repository provider operations. I, as a user, know that I can
right-click on a project and perform a Team operation. If you have a
"solution" that consists of content from multiple repositories, it becomes
less clear to the user how top perform team operations on the resources in the
"solution". This would most likely lead to the need for repository provider
specific views that show the resources in a solution that are mapped to that
repository provider (e.g the Synchronize view).
I am not saying that I
am against "solutions". I think it is clear that we need something like that.
I just wanted to point out that it does complicate repository provider
integration. Ideally, I would like to see a architecture that supports the
level of team integration we have today when possible but still gives the user
the flexibility they need to work in
Eclipse.
Michael
On Tue, Sep 23, 2008 at
5:37 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>
wrote:
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
http://www.eclipse.org/dsdp/tm
From: platform-core-dev-bounces@xxxxxxxxxxx [mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Kevin McGuire
Sent:
Tuesday, September 23, 2008 4:47 PM
To: Eclipse Platform Core component developers
list.
Subject: RE:
[platform-core-dev] What's a project
> 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
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.
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...
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
_______________________________________________
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