[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
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
