[news.eclipse.technology.kepler] Re: Thoughts on a Common Project Model

[Philip Dodds <philip.dodds@xxxxxxxxx>]

I think providing some high-level groupings of information makes sense, 
 though since a big part of this is collaboration and enabling tooling 
I'm wondering if the model segmentation should also make sense to the 
tooling levels - such that an identifiable peice of meta-data can be 
leveraged by a tool.  This means that the model would need to be able to 
identify the types of information available for the tooling to intersect 
with.

Its very interesting to see the mindmap information as clearly there is 
some understood structure - though I'm not sure about a hierarchy of 
models since a lot of the diagram is more classifications of 
information,  the models themselves are very deep.  Joakim makes a good 
point which is once the model is deep that makes interaction more 
difficult and also the aspect of merging can become an issue.

I have some working with a simple faceted model - that I'll get up on 
the wiki next week - it'll be interesting to see how this folds into it.

Cheers

P

Joakim Erdfelt wrote:
> Sounds like you are referring to a hierarchy of models.
> Not a hierarchy within a single model.
>
> I agree that a hierarchy of models would allow for some useful sharing 
> of concepts (Organization, License, Prerequisites, etc...) but I wonder 
> if a good solution could be found.
>
> A parent/child relationship could be established, but would that just 
> make the model more difficult to utilize?  A parent/child relationship 
> would make sense when presented on disk, but be more difficult to walk 
> when accessed via remote resource or database.  Might even require an 
> in-memory merge of the information prior to utilizing.  Merging would 
> also complicate the read/write of the model information.   Not to 
> mention the parent/child relationship isn't typically found in a many of 
> the models that we eventually hope to write adaptors for.
>
> I can think of a few ways to look at this problem.
> * giant ball of mud model.
> * componentized model.
> * parent/child model.
> * namespaced/linked model.
>
> More thought will need to be put into this.
>
> - Joakim
>
>
> Jesse McConnell wrote:
> > When I look at the types and volume of this kinda information I wonder 
> > if a hierarchy of this common model information is in order?
> >
> > If not then the volume of duplication of information will be large, 
> > leading to errors and out of date information.
> >
> > but then being self contained means you don't have to worry about 
> > accessing parent models and merging the information.  and then you 
> > have access controls to modifying that parent information
> >
> > maybe a template produced by an organization like eclipse or the asf 
> > would be sufficient..
> >
> > strong thoughts either way?
> >
> > jesse
> >
> >
> > Joakim Erdfelt wrote:
> > > Joakim Erdfelt wrote:
> > >  > I've started to take a stab at identifying the bits and pieces of 
> > > all of
> > > > the other models that are out there.
> > > >
> > > > See: http://joakim.erdfelt.com/kepler/common_models_matrix.html
> > > > Other Formats: http://joakim.erdfelt.com/kepler/
> > > >
> > > > I've looked at LSM, Maven 1, Maven 2, Eclipse Plug-in Manifest, Java 
> > > > Manifest, OSGi, DOAP, sf.net, freshmeat.net, google code, yum, apt, 
> > > > osdir.com, and the FSF/GNU software map.
> > > >
> > > > This is just a first pass, I'll be working out some grouping of 
> > > > concepts shortly.
> > > >
> > > > Hopefully this can get some serious discussion started.
> > >
> > > Here's my first stab at organizing concepts / groups etc ...
> > >
> > > http://joakim.erdfelt.com/kepler/common_project_model_freemind.html
> > >
> > > I used the freemind utility at http://freemind.sf.net/ to 
> > > create/visualize this model.
> > > Things in Bold Green I feel are "Core" concepts.
> > > The rest should probably be defined as kepler extensions/facets (of 
> > > some sort)
> > >
> > > p.s: I don't have access to edit the wiki (yet)
> > >
> > > - Joakim