2 Replies Latest reply on May 24, 2005 5:42 PM by ryan.campbell

    Requirements - Top level build - components + potential othe

      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.

        • 1. Re: Requirements - Top level build - components + potential

          The main issue as to whether this applies to the build
          is whether such a notion can be understood at the ant/repository level.

          e.g. can I go from

          <project>
           <component name="mdb"/>
          </project>
          

          and understand that the current jms1.1 implementation is jbossmq by default
          or if you want to override it
          <project>
           <component name="mdb"/>
           <component name="jbossmessaging"/>
          </project>
          


          This also has issues where the implementation is external, e.g. the jms1.1
          implementation is actually provided by an external jms.

          • 2. Re: Requirements - Top level build - components + potential

             

            "adrian@jboss.org" wrote:
            The main issue as to whether this applies to the build is whether such a notion can be understood at the ant/repository level.


            Perhaps extension points could use the same repository structure as components, but have a different descriptor:

            /jms/1.1/extension-info.xml:
            <project>
             <extension-point name="jms" version="1.1">
             <implementation default="true" name="jbossmq" version="4.0.2"/>
             <implementation name="jbossmq" version="4.0.1"/>
             <implementation name="jbossmessaging" version="4.0.2"/>
             </extension-point>
            </project>