continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petter Måhlén <>
Subject RE: How to handle inter-project dependencies
Date Fri, 18 May 2007 15:20:08 GMT
Hi again,

No answer to this one in a few days, so I would have to suppose that it is
not possible to solve this using standard Continuum features? In the mean
time, our solution is a symlink in Continuum's working directory to a
checked-out version of the 'common' project. When the builds fail due to a
change in the common part, we simply have to update that and we can get by,
more or less.

>From our perspective, this type of project linking is a necessary feature of
a continuous integration server. I've been very much in favour of Continuum
over Cruisecontrol due to its simplicity of configuration. But Cruisecontrol
lets me solve this particular problem, so if there really is no solution
using Continuum, I guess that Cruisecontrol has to be the tool we use after

I have added this as a feature request to JIRA. I really hope it can be
implemented, because it is a necessity for us and I don't at all enjoy the
prospect of going back to the complexity of configuring Cruisecontrol
again.. :(

/ Petter

> -----Original Message-----
> From: Petter Måhlén [] 
> Sent: Tuesday, May 15, 2007 3:32 PM
> To:
> Subject: How to handle inter-project dependencies
> Hi,
> We have a setup that works well during development but 
> doesn't agree with
> Continuum's philosophy of how to handle things - or so it 
> seems to me. I
> think there is a point in doing it another way than we are, 
> but I am not
> sure how. Hopefully, somebody here can enlighten me. :)
> We have three projects:
> 1. 'common', which basically contains an XML schema 
> definition file for code
> generation with XJC (other things as well, but that's 
> probably not relevant
> for the issue at hand).
> 2. 'client', which is built using Ant (for historical 
> reasons, would have
> preferred Maven but no time to fix that yet). One step of the 
> build looks
> like so:
> 	<target name="generate-xsd-source">
> 		<mkdir dir="${xjc.gen.dir}" />
> 		<exec executable="${xjc.exe}">
> 			<arg value="-p" />
> 			<arg value="se.jadestone.hc.client.database"/>
> 			<arg value="-d" />
> 			<arg value="${xjc.gen.dir}"/>
> 			<arg
> value="${common.dir}/src/main/schemas/database.xsd"/>
> 		</exec>
> 	</target>
> In our local environments, '${common.dir}' points to a 
> directory where the
> source code of the 'common' project resides (../common by default).
> 3. 'server', which is built using Maven, and which contains 
> the following
> dependency:
>   ...
>   <build>
>      ...
>      <plugins>
> 	   	<plugin>
> 			<groupId></groupId>
> 			<artifactId>maven-jaxb-plugin</artifactId>
> 			<executions>
> 				<execution>
> 					<goals>
> 						<goal>generate</goal>
> 					</goals>
> 				</execution>
> 			</executions>
> 			<configuration>
> <generatePackage>se.jadestone.hc.client.database</generatePackage>
> <schemaDirectory>../common/src/main/schemas</schemaDirectory>
> 				<strict>true</strict>
> 				<verbose>true</verbose>       
> 			</configuration>
> 		</plugin>
>      </plugin>
>   </build>
> Since we cannot know (I think) which directory name Continuum 
> will choose
> when checking out and building the 'common' project, both of 
> these builds
> fail. As far as I have been able to figure out, both the XJC 
> tool and the
> maven-jaxb-plugin require that we specify an explicit path to 
> the file to
> generate code from, so it doesn't seem to be an option to use 
> the jar file
> that we actually build from other things in the 'common' 
> project. I would
> like to get away from using explicit paths the way we are, 
> but I am not sure
> how.
> Does anybody have a solution to this problem? We're using 
> 1.0.3, by the way.
> Thanks in advance,
> Petter

View raw message