RE: UTF-8?
Yes - character encodings are always a nightmare. I'd say the by far best solution (if at all possible) is to change your database configuration and use UTF-8 throughout. Latin-1 is a bad idea, even if you're only planning to support Norwegian in your application. I've lost count of the number of hours I've spent chasing down character encodings-related problems in different applications, but I've learned to always go for UTF-8 everywhere if I can. / Petter > -Original Message- > From: Bjørn T Johansen [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 9:04 AM > To: [EMAIL PROTECTED] > Subject: Re: UTF-8? > > On Sat, 19 Jan 2008 11:20:18 +0100 > Bjørn T Johansen <[EMAIL PROTECTED]> wrote: > > > I am trying to use PostgresSQL as our database but I have a problem > with character encoding. I am using ISO-8859-1 > > as my encoding but it seems like Continuum insist on using UTF-8, how > can I switch to ISO-8859-1? > > > > > > Regards, > > > > BTJ > > > > - > -- > > Someone wrote: > > "I understand that if you play a Windows CD backwards you hear > strange Satanic messages" > > To which someone replied: > > "It's even worse than that; play it forwards and it installs Windows" > > - > -- > > No one knows how to get around this? We are running with ISO-8859-1 as > locale and creates the pgsql db with encoding=latin1... > When I use norwegian letters, it complains that continuum can't convert > my Norwegain character and throws an exception... > If I create the db as UTF-8 or use the included Derby database, I no > longer get an error but I only get question marks back from > the db for the Norwegian letters. > > Can this really be so hard?? > > > BTJ
RE: How to handle inter-project dependencies
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: [EMAIL PROTECTED]
> 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
> 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
>
>
>
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
RE: Project build order
That's as far as I got, and I got lost at what 'project.getDependencies()'
means. If that doesn't include plugin dependencies, should that be
considered a bug? As far as I can understand, the ProjectSorter will order
projects first in order of dependencies, and then in alphabetical order. So
we're trying to work around this by giving our projects names 'in the build
order' ("1-common", "2-server" or something along those lines). That doesn't
seem like a very stable solution, so we'd be very grateful for any
suggestions for how to do it otherwise. :)
/ Petter
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 07, 2006 10:07 AM
> To: continuum-users@maven.apache.org
> Subject: Re: Project build order
>
> The build order is defined by
> http://svn.apache.org/repos/asf/maven/continuum/trunk/continuu
> m-core/src/main/java/org/apache/maven/continuum/utils/ProjectS
> orter.java
> We don't look for the moment at plugins dependencies.
>
> Emmanuel
>
> Petter Måhlén a écrit :
> > I haven't done it like that for two reasons:
> > - the common.jar file shouldn't be distributed, it's only
> used at build time
> > to generate code, which in turn should be distributed, and,
> > - more importantly, the plugin that does code generation
> has to have the
> > common.jar file in its classpath, meaning that it needs to
> be configured as
> > a plugin dependency. Which it is, but that doesn't seem to
> affect the build
> > order. Configuring it as a dependency in two places in the
> pom doesn't seem
> > right.
> >
> > I was looking at the source code for Continuum as well, but
> I haven't been
> > able to figure out quite how the ProjectDependencies list
> of a Project (in
> > org.apache.maven.continuum.model) gets populated - none of
> those classes
> > seems to be included in the Continuum source code, and I
> haven't yet found
> > out where they are.
> >
> > / Petter
> >
> >> -Original Message-
> >> From: Wayne Fay [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, November 06, 2006 6:41 PM
> >> To: continuum-users@maven.apache.org
> >> Subject: Re: Project build order
> >>
> >> Sounds to me like Client depends on Server depends on Common.
> >>
> >> Thus:
> >> common/pom.xml
> >> ...none...
> >>
> >> server/pom.xml
> >> ...common...
> >>
> >> client/pom.xml
> >> ...server, common... or
> >> ...server... and common will
> be pulled in
> >> via transitive dependencies
> >>
> >> Is there a reason you can't set things up like this, or
> why this won't
> >> work for you?
> >>
> >> Wayne
> >>
> >> On 11/6/06, Petter Måhlén <[EMAIL PROTECTED]> wrote:
> >>> Hi,
> >>>
> >>> I have a question concerning what I can do to force
> >> projects to be built in
> >>> a specific order. There have been some previous similar
> >> queries, but they
> >>> don't quite seem to apply to our situation. What we want is this:
> >>>
> >>> 1. 'mvn clean install' for project 'common': this leads to
> >> a jar file with
> >>> common message definitions for node-node communication
> >> being updated.
> >>> 2. 'mvn clean install' for project 'server': we have
> >> written a simple Maven
> >>> plugin that reads the message definitions, and generates
> >> source code that
> >>> parses/packages the messages.
> >>> 3. 'ant clean test' for project 'client': this again
> >> generates source code
> >>> for parsing/packaging messages, but this time for the client.
> >>>
> >>> Is it possible for us to specify this order somehow? As it
> >> is, the builds
> >>> will more or less randomly fail depending on which order
> >> they are executed
> >>> in. It may be relevant that the 'server->common' dependency
> >> is configured
> >>> like so:
> >>>
> >>>
> >>> ...
> >>>
> >>>
> >>>
> >>> se.jadestone.whine
> >>> maven-whine-generator
> >>> 3.0
> >>> ...
> >>>
> >>>
> >>>
> >> se.jadestone.esports
> >>>hc-common
> >>>0.0.1
> >>>
> >>>
> >>>
> >>> ...
> >>>
> >>> The 'common' jar must be available on the classpath of the
> >> plugin that
> >>> generates source code, and like this, it is only available
> >> at that point,
> >>> which is great since we don't want to include it in the
> >> shipped product.
> >>> Thanks for any help,
> >>>
> >>> Petter
> >>>
> >>> Cell: +46 704 40 30 25
> >>> Direct: +46 8 442 75 95
> >>> Fax: +46 8 24 05 08
> >>> www.jadestone.se
> >>> Björns Trädgårdsgränd 1, 116 21 Stockholm, Sweden
> >>>
> >>>
> >>
> >
> >
> >
> >
>
>
>
RE: Project build order
I haven't done it like that for two reasons: - the common.jar file shouldn't be distributed, it's only used at build time to generate code, which in turn should be distributed, and, - more importantly, the plugin that does code generation has to have the common.jar file in its classpath, meaning that it needs to be configured as a plugin dependency. Which it is, but that doesn't seem to affect the build order. Configuring it as a dependency in two places in the pom doesn't seem right. I was looking at the source code for Continuum as well, but I haven't been able to figure out quite how the ProjectDependencies list of a Project (in org.apache.maven.continuum.model) gets populated - none of those classes seems to be included in the Continuum source code, and I haven't yet found out where they are. / Petter > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Monday, November 06, 2006 6:41 PM > To: continuum-users@maven.apache.org > Subject: Re: Project build order > > Sounds to me like Client depends on Server depends on Common. > > Thus: > common/pom.xml > ...none... > > server/pom.xml > ...common... > > client/pom.xml > ...server, common... or > ...server... and common will be pulled in > via transitive dependencies > > Is there a reason you can't set things up like this, or why this won't > work for you? > > Wayne > > On 11/6/06, Petter Måhlén <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have a question concerning what I can do to force > projects to be built in > > a specific order. There have been some previous similar > queries, but they > > don't quite seem to apply to our situation. What we want is this: > > > > 1. 'mvn clean install' for project 'common': this leads to > a jar file with > > common message definitions for node-node communication > being updated. > > 2. 'mvn clean install' for project 'server': we have > written a simple Maven > > plugin that reads the message definitions, and generates > source code that > > parses/packages the messages. > > 3. 'ant clean test' for project 'client': this again > generates source code > > for parsing/packaging messages, but this time for the client. > > > > Is it possible for us to specify this order somehow? As it > is, the builds > > will more or less randomly fail depending on which order > they are executed > > in. It may be relevant that the 'server->common' dependency > is configured > > like so: > > > > > > ... > > > > > > > > se.jadestone.whine > > maven-whine-generator > > 3.0 > > ... > > > > > > > se.jadestone.esports > >hc-common > >0.0.1 > > > > > > > > ... > > > > The 'common' jar must be available on the classpath of the > plugin that > > generates source code, and like this, it is only available > at that point, > > which is great since we don't want to include it in the > shipped product. > > > > Thanks for any help, > > > > Petter > > > > Cell: +46 704 40 30 25 > > Direct: +46 8 442 75 95 > > Fax: +46 8 24 05 08 > > www.jadestone.se > > Björns Trädgårdsgränd 1, 116 21 Stockholm, Sweden > > > > > >
Project build order
Hi, I have a question concerning what I can do to force projects to be built in a specific order. There have been some previous similar queries, but they don't quite seem to apply to our situation. What we want is this: 1. 'mvn clean install' for project 'common': this leads to a jar file with common message definitions for node-node communication being updated. 2. 'mvn clean install' for project 'server': we have written a simple Maven plugin that reads the message definitions, and generates source code that parses/packages the messages. 3. 'ant clean test' for project 'client': this again generates source code for parsing/packaging messages, but this time for the client. Is it possible for us to specify this order somehow? As it is, the builds will more or less randomly fail depending on which order they are executed in. It may be relevant that the 'server->common' dependency is configured like so: ... se.jadestone.whine maven-whine-generator 3.0 ... se.jadestone.esports hc-common 0.0.1 ... The 'common' jar must be available on the classpath of the plugin that generates source code, and like this, it is only available at that point, which is great since we don't want to include it in the shipped product. Thanks for any help, Petter Cell: +46 704 40 30 25 Direct: +46 8 442 75 95 Fax: +46 8 24 05 08 www.jadestone.se Björns Trädgårdsgränd 1, 116 21 Stockholm, Sweden
