1 2 Previous Next 24 Replies Latest reply on Jan 28, 2005 6:22 PM by ryan.campbell Go to original post
      • 15. Re: New Build in JBoss-Head

        I have checked in naming/jbossbuild.xml. I implemented rmic as Adrian described above with an "rmic" attribute on the source node in the component definition (in naming/jbossbuild.xml):

         <source id="main"
         rmic="**/NamingServer.class"
         >
         <include input="common-project"/>...
        


        And I have a source node in tasks.xml's build targetdef which applies to sources with rmic defined:
         <source when="@{rmic}">
         <rmic base="@{output}"
         includes="@{rmic}"
         >...
        


        However, when I run this, ant complians I have duplicate target definitions:
        $ ant -f jbossbuild.xml
        Buildfile: jbossbuild.xml
        
        BUILD FAILED
        C:\projects\jboss-head\naming\jbossbuild.xml:77: Duplicate target: `build.main'
        


        I expected the two targets to be concatenated instead of duplicated. I have checked in my changes to tasks.xml, so the problem should be reproducible by adding the rmic attribute as described above.

        I think the issue is that SourceDefinition.generateTargets() is adding SourceDefinitionTargets for each dynamic type regardless if another target for that type is already defined. Any pointers on this appreciated...

        • 16. Re: New Build in JBoss-Head

          I've fixed this. You are correct, SourceDefinition.generateTargets should break
          out of the loop once it realizes that one of the Source elements applies rather
          than trying to generate a target for each one that applies.

          I fixed it in other places as well. Most of them were doing it wrong.

          • 17. Re: New Build in JBoss-Head

            Also, as a heads up.

            We don't use tabs in source.

            1) Most developers use 3 *spaces* for tabs which doesn't work if you use
            different editors that defaults to 4 or 8
            2) Tabs don't display correctly when source is viewed by online tools. HTML
            converts the tab to one space.

            • 18. Re: New Build in JBoss-Head
              mazz

              TABS?! To the gallows with you!

              [I believe there is code conventions document on sourceforge that describe the basic requirements]

              • 19. Re: New Build in JBoss-Head

                I've implemented the Class-Path processing.
                Now the

                <pathelements/>

                will include the dependencies of the jars they include.

                e.g. kernel compiles over common-project, concurrent
                and includes test-project for testcase support.

                 <source id="main">
                 <include input="common-project"/>
                 <include input="concurrent"/>
                 </source>
                
                 <source id="tests" test="org/jboss/test/**/*TestCase.java">
                 <include input="main"/>
                 <include input="test-project"/>
                 </source>
                


                This leads to all these jars and their depdencies getting included in the classpath
                for running the tests:

                [ejort@htimes2 kernel]$ ant -f jbossbuild.xml show -Dshow=runtest
                Buildfile: jbossbuild.xml
                
                show:
                <!-- Run tests -->
                <target name="runtest" depends="runtest.tests">
                </target>
                
                <!-- Run tests for the source src/tests -->
                <target name="runtest.tests">
                <mkdir dir="/home/ejort/jboss-head/workspace/kernel/output/reports/tests"/>
                <delete file="/home/ejort/jboss-head/workspace/kernel/output/reports/tests/test.log"/>
                <junit printsummary="true" fork="true">
                 <sysproperty key="org.jboss.test.logfile" value="/home/ejort/jboss-head/workspace/kernel/output/reports/tests/test.log"/>
                 <formatter type="plain"/>
                 <classpath>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/gnu-regexp/lib/gnu-regexp.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/common/output/lib/namespace.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/dom4j-dom4j/lib/dom4j.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/apache-xerces/lib/xercesImpl.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/apache-commons/lib/commons-httpclient.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/apache-log4j/lib/log4j.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/wutka-dtdparser/lib/dtdparser121.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/test/output/lib/jboss-test.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/kernel/output/classes/main"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/oswego-concurrent/lib/concurrent.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/kernel/output/classes/tests"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/apache-jaxme/lib/jaxmexs.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/common/output/lib/jboss-common.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/apache-slide/client/lib/webdavlib.jar"/>
                 <pathelement location="/home/ejort/jboss-head/workspace/thirdparty/junit-junit/lib/junit.jar"/>
                 </classpath>
                 <batchtest todir="/home/ejort/jboss-head/workspace/kernel/output/reports/tests">
                 <fileset dir="/home/ejort/jboss-head/workspace/kernel/src/tests" includes="org/jboss/test/**/*TestCase.java"/>
                 </batchtest>
                </junit>
                </target>
                


                • 20. Re: New Build in JBoss-Head

                  Another heads up.

                  You don't need to include both the server jar and the client jar in the classpath.
                  e.g.
                  common-project only needs jboss-common.jar

                  jboss-common-client.jar is a cutdown version of jboss-common.jar
                  including only those classes required on the client side.

                  (Bad example, because in this case it is - all of them :-)

                  • 21. Re: New Build in JBoss-Head

                    Adrian,

                    The Class-Path for a jar is now included in the build path, not just for testing. I think this may be a problem, because I am not forced to specify a direct dependency if it is a dependency for another artifact.

                    Example is jmx. I can compile JMX using just these declared dependencies:

                     <source id="main">
                     <include input="common-project"/>
                     <include input="bcel"/>
                     <include input="junit"/>
                     </source>
                    


                    and then the Class-Path from jboss-common.jar is expanded into my build path:

                     <classpath>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-xerces\lib\xercesImpl.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\junit-junit\lib\junit.jar"/>
                     <pathelement location="C:\projects\jboss-head\jmx\output\classes\main"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-jaxme\lib\jaxmexs.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-bcel\lib\bcel.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\wutka-dtdparser\lib\dtdparser121.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-commons\lib\commons-httpclient.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\oswego-concurrent\lib\concurrent.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\gnu-regexp\lib\gnu-regexp.jar"/>
                     <pathelement location="C:\projects\jboss-head\common\output\lib\jboss-common.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\dom4j-dom4j\lib\dom4j.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-slide\client\lib\webdavlib.jar"/>
                     <pathelement location="C:\projects\jboss-head\common\output\lib\namespace.jar"/>
                     <pathelement location="C:\projects\jboss-head\thirdparty\apache-log4j\lib\log4j.jar"/>
                     </classpath>
                    
                    


                    This is undesirable because I jmx has direct dependencies on jars which are not documented in the input. This is fine for testing, but not in building where we want the build to fail if direct dependencies are not documented explicitly.

                    • 22. Re: New Build in JBoss-Head

                      For example, javax.management.MatchQueryExp imports gnu.regexp, so I ought to need to declare that as an input for the jmx component.

                      Perhaps we should add an additional construct similar to which only expands to the directly included inputs.

                      <buildpath/> ?


                      • 23. Re: New Build in JBoss-Head

                        Do you want to fix this? Or do you need some help understanding the source.
                        The fix would be in MacroUtil.

                        • 24. Re: New Build in JBoss-Head

                          Ok, I'll take a look at this. I think I have a good idea of what needs to be changed.

                          1 2 Previous Next