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
|
