Hi Stephen,
> -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Freitag, 10. Oktober 2003 02:16 > To: Avalon Developers List > Subject: Re: Repository listing > > > > Yannick Menager wrote: > > > Exactly my thoughts.... > > > > Roughtly my ideia is to have a repository, which can contain 3 category > > of 'Modules' > > > > Components ( of which can be a normal Component, or an API Component, or > > a ComponentGroup ) > > Applications > > Projects ( That's for large scale projects which will produce components > > and applications ) > > Component and Project are notions I'm OK with. Application is something > which IMO is an artefact of a project. I'm even ready to say that > "Application" .. is the encroaching evil [1]. An application is > something that we must consciously consider as a non-reusable unit. > I.e. an application should view as a transient view on a composite > component model arriving out of a project. The artefacts associated > with an application (containers, installers, other structural > dependencies ...) are all things that are for all practical purposes > temporary artefacts. The long term value is in the components and > services that are delivered. The short term satisfaction is through an > application. > I do not fully agree with it - but as I assume, you are a bit philosophical minded - language is just a matter of agreement and declaration :-) > > My view would be we have > > * group: > > one instance of a group within a repository, multiple > components with a group, multiple projects with a group > > * component - an identifiable artifact subset within > a group > > * project - a project is something described within a > group but may aggregate components from other groups > by reference > > * application - an identifiable artifact within a > project > > How to express this in a way then enables autodiscovery ... don't know. > Needs more thinking. The best way I think is to develop an architectural "meta-model". This would express things very clearly - and would be a perfect basis for new enhancements for the container. I have done a lot of "meta-modelling" with omg and other - so if you like, we could start this. One other thing I would like to propose is to get more the user side of component development in focus. Is this the right forum to discuss those things or is there an other process? Cheers Andreas > > Cheers, Steve. > > > [1] encroaching evil - In the Third Age of Middle-earth, the allied > forces of good were locked in mortal combat with the encroaching evil > of Sauron's armies which marched out of Mordor determined to retrieve > the One Ring for their dark master. > > ... just for context ;-) > > SJM > > > > > > > > the internals of those are to be *everything* that might be of > > interest relating to a project, even to the point of including the > > possibility to associate/attach emails, posts, etc... > > > > Stephen McConnell wrote: > > > >> > >> > >> Berin Loritsch wrote: > >> > >>> Yannick Menager wrote: > >>> > >>>> Yes that would be easy to put in place, all that's really needed is > >>>> a standard XML format to describe projects, components, etc... I'm > >>>> starting to work on that first :) > >>>> > >>>> J Aaron Farr wrote: > >>> > >>> > >>> > >>> > >>> Wouldn't the Maven project.xml work? > >> > >> > >> > >> > >> IMVHO - no. > >> > >> Two reasons: > >> > >> 1. The Maven project.xml defines an artifact from the viewpoint of > >> building the artifact. It does not define a product. There is > >> significant overlap but at the same time there are quantum > >> differences. I have been playing with (but never completed) a > >> product.xml and counterpart service.xml. The notions I've been > >> focussing on are "product" == "physical tool to do something" whereas > >> "service" == "usage of a tool by a provider to deliver a value > >> proposition". The combination of the two has the ability to deliver > >> a "solution model". > >> > >> 2. In defining a new abstraction - don't depend on a schema that you > >> don't control. > >> > >> Steve. > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
