From: <ad...@jb...> - 2005-05-17 18:47:44
|
The assumption so far has been to reproduce the buildmagic model of project definitions. i.e. there is a list of components that have dependencies on other components which are built together. e.g. jbossas declares the transaction component which has dependencies on the j2ee component for the interfaces and common for the logging abstraction With the new build, these can either be expressed by importing the component or importing an artifact that the component exports. While this is fairly well understood (at least in the buildmagic way of doing this) this becomes more complicated when components are shared across top level builds. It also has the disadvantage that I have been complaining about for a long time that you get implementations depending on implementations with no real definition of what is really being expressed. If you look at an alternate approach like OSGI used by eclipse, you have the notion of defining integration points (interfaces) and implementations. These notions are of course versioned. For example you could have: | j2ee project: | <defines>JMS1.1</defines> | | mdb project: | <requires>JMS1.1</requires> | | jbossmq project | <implements>JMS1.1</implements> | | jboss/messaging project | <implements>JMS1.1</implements> | The requirement for consistent build would be that all "requires" have a "defines" and that each "defines" has an "implements". Of course, these can be mixed and matched, e.g. | jbossmq project | <implements>JMS1.1</implements> | <defines>jbossmq-il</defines> | | httpil project: | <implements>jbossmq-il</implements> | Such a feature can also be used to trim what is placed in a release or deployed/started at runtime. e.g. nobody "requires" JMS1.1, we can ignore the implementor and its dependencies. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878078#3878078 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878078 |