More on component-info.xml usage

[starksm64]

I'm still struggling with how best to resolve dependency import notion in this issue:
http://jira.jboss.com/jira/browse/JBBUILD-72.

The problem I'm seeing is that there already is a notion of dependency, but it does not seem to be at the correct level. Its showing up in the main component build rather than the component-info.xml. Take for example, the jboss-head/naming/component-info.xml:

<project name="naming-component-info">

 <component id="naming"
 module="jboss-naming"
 version="5.0-SNAPSHOT"
 >
 <artifact id="jnpserver.jar"/>
 <artifact id="jnp-client.jar"/>
 <artifact id="jnp-tests.jar"/>
 <export>
 <include input="jnpserver.jar"/>
 </export>
 </component>


</project>

and the jboss-head/naming/jbossbuild.xml:

<?xml version="1.0"?>

<project name="project"
 default="build"
 basedir="."
>
 <import file="../tools/etc/jbossbuild/tasks.xml"/>
 <import file="component-info.xml"/>

 <componentdef component="naming" description="JBoss Naming">

 <source id="main"
 rmic="**/NamingServer.class"
 >
 <include component="common"/>
 <include component="apache-log4j"/>
 <include component="junit-junit"/>
 </source>

 <artifactdef artifact="jnpserver.jar">
 <include input="main">
 <!-- include server classes & interfaces -->
 <include pattern="org/jnp/server/**"/>
 <include pattern="org/jnp/interfaces/**"/>
 </include>
 </artifactdef>

 <artifactdef artifact="jnp-client.jar">
 <include input="main">
 <!-- include client classes & server stubs -->
 <include pattern="org/jnp/interfaces/**"/>
 <include pattern="org/jnp/server/*Stub.class"/>
 </include>
 </artifactdef>

 <artifactdef artifact="jnp-tests.jar">
 <include input="main">
 <!-- only include test classes -->
 <include pattern="org/jnp/client/**"/>
 <include pattern="org/jnp/test/**"/>
 </include>
 </artifactdef>
 </componentdef>

 <!-- Generate the targets -->
 <generate generate="naming"/>

</project>

So there is an expression of the thirdparty dependencies in the source id="main" element via the include component=common, apache-log4j, and junit-junit. This should be coming from the imported component-info.xml so that when the jnpserver.jar is promoted to the repository, consumers of the jnpserver.jar have the same thirdparty dependencies defined.

In this case, only the common and apache-log4j should be in expressed as dependencies in the component-info.xml as the junit-junit is local to the naming module unit testing. So something like the following component-info.xml:

<project name="naming-component-info">
 <component id="naming"
 module="jboss-naming"
 version="5.0-SNAPSHOT"
 >
 <includes id="thirdparty">
 <include component="common"/>
 <include component="apache-log4j"/>
 </includes>
 <artifact id="jnpserver.jar"/>
 <artifact id="jnp-client.jar"/>
 <artifact id="jnp-tests.jar"/>
 <export>
 <include input="jnpserver.jar"/>
 </export>
 </component>
</project>

and componentdef/source is how this should be tying together:

 <componentdef component="naming" description="JBoss Naming">
 <source id="main"
 rmic="**/NamingServer.class"
 >
 <include includesref="thirdparty"/>
 <include component="junit-junit"/>
 </source>

right?

[ryan.campbell]

A small problem with this approach is that you will need to uniquely name the thirdparty include id, like this:

<includes id="thirdparty-naming">
 <include component="common"/>
 <include component="apache-log4j"/>
 </includes>

Anything with an id attribute is a reference. Since we will be parsing other component-info's, you want the id to be unique so that references are not overriden by other "thirdparty" includes.

Also, there is a small syntax problem in your last code example. To reference an includes from an include, you use the input attribute:

<componentdef component="naming" description="JBoss Naming">
 <source id="main"
 rmic="**/NamingServer.class"
 >
 <include input="thirdparty"/>
 <include component="junit-junit"/>
 </source>

Nitpicks aside, I think the design will work.

[adrian.brock]

There appears to be some confusion here.

junit is only used by the unit testing, but we still want to know that the junit module
is required to run the unit tests if the project is distributed in binary form
and federated into a greater test build.

In fact, this is one drawback of defining the tests on the source element.
Since you lose the notion of what are the tests (and what are any special test configuration)
in the binary format

<source id="main"
 rmic="**/NamingServer.class"
 test="org/jnp/test/*Test.class"
 >
 <include includesref="thirdparty"/>
 <include component="junit-junit"/>
 <junit-elements>
 <special config here/>
 </junit-elements>
 </source>

[starksm64]

So there seems to be a need to combine the artifacts export/import statements, so the naming component-info.xml exports might look like:

<export id="naming-server">
 <include input="jnpserver.jar"/>
 <include component="apache-log4j"/>
 <include component="common"/>
</export>

<export id="naming-tests">
 <include input="jnp-tests.jar"/>
 <include component="junit-junit"/>
 <include component="common"/>
</export>

In general the artifacts from a component may need different dependent jars at runtime.

[adrian.brock]

Ignoring the obvious mistake, yes.

<export id="naming-tests">
 <include input="jnpserver.jar"/> <!-- Can't run the tests unless you have the implementation :-) -->
 <include input="jnp-tests.jar"/>
 <include component="junit-junit"/>
 <!--include component="common"/ This is used by the implementation not the tests? -->
</export>

[starksm64]

So that is a good question. Actually the naming-tests should include the jnp-client.jar rather than jnp-server.jar, with the assumption that the consumer of the naming-tests export artifcact will configure the server given the naming-server artifcat. This illustrates a problem with semantic artifcat definition like a tests input artifcat. It depends on how the test is going to be run. If the test driver is a component like the jbossas testsuite, the jnpserver.jar should not be in the naming-tests. Even if the driver is a standalone unit test target that needs to configure a standalone naming server the, the unit test setup target should express that it needs both the naming-server and naming-tests component artifacts and dependencies.

For the common component dependency, I was assuming this was being used by the tests as in the case of the org.jboss.logging.Logger. There should also be a dependency on some base test harness which likely includes common.

[adrian.brock]

So that is a good question. Actually the naming-tests should include the jnp-client.jar rather than jnp-server.jar, with the assumption that the consumer of the naming-tests export artifcact will configure the server given the naming-server artifcat. This illustrates a problem with semantic artifcat definition like a tests input artifcat. It depends on how the test is going to be run. If the test driver is a component like the jbossas testsuite, the jnpserver.jar should not be in the naming-tests. Even if the driver is a standalone unit test target that needs to configure a standalone naming server the, the unit test setup target should express that it needs both the naming-server and naming-tests component artifacts and dependencies.

That was my comment above about junit-config.
However, I don't see any reason why jnpserver cannot be unit tested from standalone tests. Other complications like transport, security, ha enhancements would be
tested elsewhere as part of integration tests.

For the common component dependency, I was assuming this was being used by the tests as in the case of the org.jboss.logging.Logger. There should also be a dependency on some base test harness which likely includes common.

This already exists in the "test" project.
http://jira.jboss.com/jira/browse/JBAS-1768