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.
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
projectHow to express this in a way then enables autodiscovery ... don't know. Needs more thinking.
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]
