You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@continuum.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2008/04/02 12:43:58 UTC

[jira] Closed: (CONTINUUM-1277) The ability to link projects together using paths

     [ http://jira.codehaus.org/browse/CONTINUUM-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter closed CONTINUUM-1277.
-----------------------------------

       Resolution: Won't Fix
    Fix Version/s:     (was: Future)

you should use the single build for all modules instead of separate ones, available on the add page

> The ability to link projects together using paths
> -------------------------------------------------
>
>                 Key: CONTINUUM-1277
>                 URL: http://jira.codehaus.org/browse/CONTINUUM-1277
>             Project: Continuum
>          Issue Type: New Feature
>         Environment: Any
>            Reporter: Petter Måhlén
>
> Many of the projects at my company include both clients and servers, and we usually define things like communication protocols, shared classes, etc., in a shared project (usually called something like 'common'). Some tools (such as XJC) require that we can specify the exact path to files in the shared project, and Continuum doesn't seem to permit that. This type of feature seems to make sense for larger-scale projects and is at least necessary for us.
> Copy of my question to the user list from the 15th of May:
> ---
> 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.
> ---

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira