[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
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