[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
Hi Kevin,
I
fully agree and here's what I deduce from the discussion in a technical
sense:
-
The
current fact that a project is tied to some root folder is artificial. In
terms of file contents, a project is a list of files (linked resources),
containers (root locations) and probably filters on those containers. Current
Eclipse projects are a special case of this, in that there is one special
container (aka root location), which happens to hold the
metadata.
It looks like with these two enhancements, an RCP could easily create a
kind of project that can remain invisible. One question to solve is whether the
list of root locations are allowed to overlap ("reference" relation) or not
("contains" relation). Perhaps both kinds are needed. As a third enhancement, I
could imagine this:
-
As a third layer
("Application Layer" as defined by Michael), multiple Natures can be added to
the project in order to interpret the data that's in the project. Each nature
can specify "Resource Views" which provide a filtering on the project
contents. Notifications, Operations and Scheduling Rules obey such Resource
Views as a filter.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Hi Martin,
Btw, great discussion thread!
I admit that I've
not been following the Buckminster project, thanks in advance for connecting
the groups.
> So, looking at this
task ("where do you want to store your photos"), it
> seems like the question "where do you want to store the
meta data
> about your photos" is not
answered.
>...
> How would the Photo app store meta
> data such as a rating per photo, or tags added to
photos? What would
> it do if the photos
are actually stored on a read-only device?
That's true but I don't think
you need a "project" to do so. Also, the meta data in question is about
the pictures, not about the container of all the pictures (what we'd consider
the project). I might need project level settings for things like
defaults, but these might also be realized as user level preferences. So
I still believe I don't necessarily need a project, and certainly at
the user level I shouldn't require one. Maybe though at the API level we
might still want one to describe the set of pictures the app can see, and then
it could manage project level metadata storage in a variety of ways, only one
of which is to drop a file at some artificial root.
So as I see it:
1) The user shouldn't have to make a "Project"
2) Project metadata should be stored in a variety of
ways, only one of which is as a file at the project root location
3) In many applications areas, the notion of
project root location is questionable anyway. I might have resources
spread all over the place via linked resources. What root?
Regards,
Kevin
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx> Sent by:
platform-core-dev-bounces@xxxxxxxxxxx
09/24/2008 11:08 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 |
|
Hi Kevin and Michael,
many thanks for your points. In terms of the question how
"Solutions"
could map to different
Repository providers, I'm almost sure that the
Buckminster people could
give us some helping insight. I'll try to make
them aware of this discussion via their newsgroup.
> 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").
So, looking at this task ("where do you want to store your
photos"), it
seems like the question "where
do you want to store the meta data
about
your photos" is not answered.
To me, simply put:
project = file list + metadata
where "file list" can be enumeration and/or
containers, and metadata
is both the
storage of metadata (.project, .settings) as well as its
interpretation (natures).
If I imagine a file system
that's capable of storing arbitrary meta data
about the items it stores (not sure if WinFS was once meant to
go
that direction), the notion of a project
may be completely unnecessary
since each
and every file would know how to get interpreted and what
to do with it.
But that's not the case, and so we need a project
as the container in
which we store the
metadata. How would the Photo app store meta
data such as a rating per photo, or tags added to photos? What
would
it do if the photos are actually
stored on a read-only device?
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: Wednesday, September 24, 2008 4:28 PM
To:
Eclipse Platform Core component developers list.
Subject: Re:
[platform-core-dev] What's a project
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
_______________________________________________
platform-core-dev
mailing
list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev