Andreas Oberhack wrote:
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 :-)
Yep. Also keep in mind that I'm sometimes in disagreement with myself. ;-)
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
Really! Have we met?
- so if you like, we could start this.
Sounds good.
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?
At this stage there is a lot of concept throwing around to be done and it would perhaps make more sence to shift the discussion over to the [EMAIL PROTECTED] list.
Cheers, Steve.
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]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
