continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Roussel <d...@diroussel.xsmail.com>
Subject Re: How to handle inter-project dependencies
Date Sun, 20 May 2007 16:18:21 GMT
Petter,

I can see your point about explict paths, but in the example you give  
the client is calling xjc and the server is referencing the generated  
files via a relative path.  If instead the server referenced the  
generated files from the client artifact, then you'd be ok, right?

David

On 19 May 2007, at 14:58, Petter Måhlén wrote:

> Hi,
>
> Thanks for the response - while I agree that building Maven  
> artifacts and
> placing them on the classpath is a great solution (we have actually
> developed a Maven plugin for an internal code generation tool to be  
> able to
> do just that and get rid of explicit path links), the problem in this
> particular case is that Sun's xjc tool, and the Maven plugin to  
> that tool,
> require explicitly specifying a path or a directory where the schema
> definition files are. For as long as not all tools support retrieving
> resources from the classpath, I think that some kind of inter-project
> linking is a useful feature.
>
> / Petter
>
>> -----Original Message-----
>> From: David Roussel [mailto:dave@diroussel.xsmail.com]
>> Sent: Saturday, May 19, 2007 12:45 PM
>> To: continuum-users@maven.apache.org
>> Subject: Re: How to handle inter-project dependencies
>>
>> Petter,
>>
>> I think that people commonly don't have this problem if they are
>> using maven, as maven modules produce artifacts that other modules
>> can depend on.  What you describe seems like a simple case
>> where both
>> server and client depend on common.  So, with maven, when you build
>> server the common.jar (or whatever) will be on the classpath at
>> compilation time.
>>
>> I can understand that if you have something working with Ant
>> it looks
>> like hardwork to migrate to maven, but for me the main power
>> of maven
>> is with multimodule projects.
>>
>> David
>>
>> On 18 May 2007, at 16:20, Petter Måhlén wrote:
>>
>>> 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
>>> all.
>>>
>>> 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 [mailto:petter.mahlen@jadestone.se]
>>>> Sent: Tuesday, May 15, 2007 3:32 PM
>>>> To: continuum-users@maven.apache.org
>>>> 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>com.sun.tools.xjc.maven2</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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>


Mime
View raw message