RE: How to handle inter-project dependencies
Sorry to be unclear, but actually, both the xlient and the server are calling xjc separately, using an XSD file as input to generate code: server: - maven-jaxb-plugin calls xjc, looking for schema definition files in ../common/... - output is generated to a newly created directory under target/generated-sources/xjc - the new directory is added to the source path for the compile part of the maven lifecycle Both the last two steps happen implicitly and are managed by the JAXB plugin. client: - we make an explicit call to xjc, specifying where to find schema definition files, and where to output the source (in a directory called 'build/gen-src' or something like that) - we explicitly tell the javac ant task to compile code under the 'gen-src' directory I suppose it would be possible to have the 'common' project generate the code, compile classes and make those available as an artifact. That would simplify the build process, but it would make it a bit more awkward to work with the code, I think. Change 'common', make a build and publish that (how to test it/restrict other users from accessing it?), then update the client, for instance, and make sure that works. The way we are doing it presently is less cumbersome for the programmer. Or so I think, but maybe there is a way forward here? / Petter > -Original Message- > From: David Roussel [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 20, 2007 6:18 PM > To: continuum-users@maven.apache.org > Subject: Re: How to handle inter-project dependencies > > 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:[EMAIL PROTECTED] > >> 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 > >>> Crui
Re: How to handle inter-project dependencies
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:
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:
...
...
com.sun.tools.xjc.maven2
maven-jaxb-plugin
generate
se.jadestone.hc.client.database
../common/src/main/schemas
true
true
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 X
RE: How to handle inter-project dependencies
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:[EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> >> 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:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >> value="${common.dir}/src/main/schemas/database.xsd"/>
> >>
> >>
> >>
> >> 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
> >> d
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:[EMAIL PROTECTED]
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:
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:
...
...
com.sun.tools.xjc.maven2
maven-jaxb-plugin
generate
se.jadestone.hc.client.database
../common/src/main/schemas
true
true
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
