[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] What's a project
|
And maybe in the photo case the metadata can be derived on the
fly just by looking at the resource itself, e.g it's content
type.
Or maybe you don't need any metadata and the tools work
directly with the "file system" objects, e.g the file store.
We should be able to support both and let clients decide based
on their requirements.
Doug.
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