cvs co jbossas
cvs co tools
These should be consolidated into a single alias in CVSROOT/modules.
Unfortunately, jbossas has been hijacked for other purposes by people
that treat cvs modules as "dumping grounds".
It would be a good idea to create a separate top-level module that doesn't
include all that "integration" rubbish.
You used to be able to type "ant rebuild" to do both of these in one step?
Thank you. I'm in agreement with the idea of a single module alias and a seperate top level module. Before I get to that though, I would like to get the discussion rolling on some of the issues which I have found and the best way of addressing them.
At the top level, we define which dependencies we need project wide. A real world example of this looks like:
<component name="apache-httpclient" version="2.0" > <artifact id="commons-httpclient.jar" release="lib, server/all/lib, server/default/lib"/> </component>
This declaration declares a component called apache-httpclient. This component consists of a single jar file, commons-httpclient with a version 2.0 and also describes what happens to this jar file in the release cycle. When targets are generated for this definition they will be named:
Currently, no problems our presented with the present system, but looking ahead could possibly encounter a situation such as the following:
<component name="foo" version="2.0" > <artifact id="foo.jar" /> <artifact id="local.properties" /> </component> <component name="foobar" version="2.0" > <artifact id="foobar.jar" /> <artifact id="local.properties" /> </component>
This situation will create a problem as the target local.properties will be generated twice resulting in an ANT error.
We can see that target generation based off of the artifact id could possibly lead to errors and adds the requirement that artifacts housed in the repository must have unique filenames.. The immediate solution would be to modify the target generation to create targets based off of some unique identifaction schema . Perhaps the schema target.component-name.artifact-id (e.g. synchronize.foobar.local.properties. This would assume of, course, that each artifact within a component would be unique.
The second synchronization issue which I ran across is a checkout vs. compilation issue. When I instruct the build to do a sychronization (checkout) I would like the testsuite module to be checked out but do not want it to be compiled as part of the default build (mirroring the buildmagic functionality).
It would seem we would need some type of attribute which would dictate if something is built by default (if this is really a requirement).
<component id="testsuite" module="jbosstest" version="5.0-SNAPSHOT" compile="false" > </component>
Can you split different issues into separate posts
The idea of naming artifacts was that they would go into the release (where you
obviously can't have competing names).
Those aliases were added by Ryan to simplfy the dependencies.
Read the previous discussions.
Looks ok to me if there is still a simple way to detect that something that
should only be built locally.