jboss-dev-forums

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<rya...@jb...>]

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.  

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877865#3877865

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877865

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<ad...@jb...>]

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>
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878069#3878069

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878069

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<sco...@jb...>]

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. 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878081#3878081

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878081

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<ad...@jb...>]

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>
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878087#3878087

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878087

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<sco...@jb...>]

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.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878092#3878092

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878092

[Jboss-dev-forums] [Design of JBoss Build System] - Re: More on component-info.xml usage

[<ad...@jb...>]

"sco...@jb..." wrote : 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.

anonymous wrote : 
  | 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

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878095#3878095

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878095