On Sunday 27 April 2008 mgehring wrote:
I have a problem to run release:prepare! The build process stops with the
Message:
Reason: Can't run goal clean verify
clean verify is not one goal, it is two phases: the clean phase and
the verify phase. It seems like you eventually specified the
On Monday 28 April 2008 amit kumar wrote:
Hi Olivier,
I tried the same thing in the root pom. But at the sub module level it
was taking ${my.build.directory} as {basedir}/${my.build.directory}, so
the error that was coming was like could not create *
Hi,
my solution is the following configuration in my parent pom
As you can see, the checkoutDirectory and workingDirectory parameters
are configured in the pom.xml - they couldn´t be passed as argument via
CmdLine,
but I don´t remember exactly why, I guess that´s just a bug.
plugin
Hi!
As I undestand you can correct problems directly in tagged version and 3.
step is not neccesary.
Benoit Decherf-2 wrote:
oups... I make some mistakes...
please read:
1 - execute release:prepare
2 - check if everything is ok, if not correct the problems.
3 - re-execute
Hi,
in my pom.xml I have the following:
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
version2.4/version
/plugin
...
properties
tomcatPath${env.JBOSS_HOME}/server/default/deploy/jbossweb-tomcat55.sar/tomcatPath
Hi, All!
Is is somehow possible to tag the project in SVN with two different tags
while making release? One tag is applied by release plugin and it is
project name-version number, but I'd like to put an additional tag -
latest, to mark our latest version of the project in SVN.
Thank you in
Hi,
when I generate a Cobertura report on my projet, here is an extract of the
result I get :
http://www.nabble.com/file/p16955739/120-003.jpg
Some methods are not traversed by test (in this example line 48) but are not
marked in red.
Do you have an idea of the reason of this behaviour ?
Can I have two separate variables containing build number values in
different format?
Actually want to use build number for both the build directory name and the
time stamp in jar file names.
so a buildnumber with format MM-DD- be the build directory name
and MM-DD--HH-mm gets appended to
Anyone knows why there is no saxon 8.8 on maven repository?
thanks
emerson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I am inheriting the ${build.directory} property from the root project and
then in children projects i am trying to give the finalName as -
${buildNumber} but its taking the format same as I defined in the root pom.
Any ideas?
Amit
On Tue, Apr 29, 2008 at 2:50 PM, amit kumar [EMAIL
Thanks martin, problem got resolved (still to figure out why wasn't it
working earlier). I am using a property now, which seems to work, now the
issue lies with buildnumber-maven-plugin , i am not able to have two
separate buildNumbers with different formats.
Thanks adn regards,
Amit
On Tue, Apr
Hi, I'm working on a project which uses a zip dependency with a test scope,
and I noticed different behaviors between jar and zip dependencies.
During a unit test, I have to access a properties file packaged in a zip
dependency; but I get a FileNotFoundException. If I change this zip
dependency
Fantastic !
--
View this message in context:
http://www.nabble.com/-ANN--Maven-Archetype-Plugin-2.0-alpha-3-Released-tp16949530s177p16957427.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki article
[0] for all details.
A controversial aspect of this proposal is which file encoding should be
assumed in case the user did not
+1 for the option b.
We had our share of builds behaving differently from OS to OS and
from region to region. :(
cheers,
sherali
29/04/2008, в 21:23, Benjamin Bentmann писал(а):
Dear community,
the Maven team is currently discussing a proposal about the future
handling
of source file
Definitely b)
Reproducable builds are an absolute requirement for a build tool.
Benjamin Bentmann wrote:
Dear community,
the Maven team is currently discussing a proposal about the
future handling
of source file encoding by the various plugins, please see
our wiki article
[0] for all
definitely a)
I can't help myself I'm a backward compatibility guy.
Just a note, both solution allow one to have a reproducible builds if
one cares. Benjamin and Herve (and others) have done a great job on
making sure that when you set the encoding for the project it gets
applied consistently
Benjamin Bentmann wrote:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
Hi
I vote for b). The different file encodings on different environments
are a mess.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
+1
Starting a new maven project and not being aware of this thread /
encoding problem I (speaking as maven user) for sure will not set an
encoding and rely on the 'default' encoding. Doing so may
+1 for [b]
Many novide developper don't even know what character encoding is. I had to
explain many time why the same application, compiled under a Unix server did
not generate the same result for some txt files with french characters.
Backward compatibility is nice but this doesn't mean user
I definitely vote for A but I see those who vote for B as valid as well. A
is basically today's choice since the default today is the platform's
encoding. If people want to override the default and forget about it, it
tells me it should belong in a corporate POM, which implies A again.
Paul
On
Benjamin Bentmann wrote:
e the two possible directions to go:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
My vote is certainly b. However and IMHO, plugins that
+1 for a)
even if b) does promise reproducible builds. Having all files stick to a given
(default) encoding will mean a nightmare to all
platforms where such encoding is not the system one when it comes to modifying
or editing files.
Thus, in addition to a) (allowing files to stick to whatever
On Friday 25 April 2008 Arand, Thomas (NSN - DE/Muenich) wrote:
Is that really the only way to deal with that?
1. has the disadvantage that some other project indeed may need the
server dependencies (e.g. the artifact to package an ear). With this
solution one would have to repeat the
+1 for b) - reproducibility is more important that the bother to have to
define the encoding explicitly.
Benjamin Bentmann wrote:
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki
+1 for b. And let it be UTF-8.
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki article
[0] for all details.
A
On Tue, Apr 29, 2008 at 1:23 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
These are the two possible directions to go:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
+1 for b)
Reproductible builds is _the_ shit.
About backward compatibility, I second Nicolas about reading releases notes,
upgrade guides etc...
Le Tuesday 29 April 2008 13:23:44 Benjamin Bentmann, vous avez écrit :
Dear community,
the Maven team is currently discussing a proposal about
I created the project in Eclipse and it runs! I went thru every step, I have
not been about to get any of the projects to work with maven2.
On Mon, Apr 28, 2008 at 6:57 PM, Barrie Treloar [EMAIL PROTECTED] wrote:
On Tue, Apr 29, 2008 at 6:22 AM, [EMAIL PROTECTED] wrote:
So not I moved the
Hi.
Looking at the JIRA for maven-checkstyle-plugin, I notice that all
issues for the 2.2 release has been resolved - and has been for quite
a while.
Can anyone tell me when 2.2 will be released?
2.2-SNAPSHOT is not an option for me because company policies
restricts the use of SNAPSHOTs
Regards,
The differences are that I am using 3.3.2 and there is no RCP standalone
package for 3.3.2.
On Tue, Apr 29, 2008 at 8:05 AM, [EMAIL PROTECTED] wrote:
I created the project in Eclipse and it runs! I went thru every step, I
have not been about to get any of the projects to work with maven2.
You can checkout a project without a pom like this:
mvn scm:checkout -DconnectionUrl=[YOUR_SCM_URL]
All options are defined here:
http://maven.apache.org/scm/plugins/checkout-mojo.html
the bootstr
On Mon, Apr 28, 2008 at 11:11 PM, Daniel King [EMAIL PROTECTED] wrote:
How can you checkout a
Zips are not placed on the classpath. You could use the dependency
plugin to unpack the contents to a known location and use that to load
the file.
-Original Message-
From: knf [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 6:02 AM
To: users@maven.apache.org
Subject: zip
You can checkout a project without a pom like this:
mvn scm:checkout -DconnectionUrl=[YOUR_SCM_URL]
All options are defined here:
http://maven.apache.org/scm/plugins/checkout-mojo.html
The bootstrap goal should work with something like this:
mvn scm:bootstrap -DconnectionUrl=[YOUR_SCM_URL]
Arand, Thomas (NSN - DE/Muenich) wrote:
Is that really the only way to deal with that?
1. has the disadvantage that some other project indeed may need the
server dependencies (e.g. the artifact to package an ear). With this
solution one would have to repeat the dependency in that
other
Benjamin,
Can you outline in what cases and in what ways this change could break
existing builds, and what it would take for the user to fix? Could a
tool be created to correct it automatically?
--Brian
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday,
Hi,
+1 to [a]
There seems no meaning to break compatibility.
Benjamin Bentmann wrote:
Dear community,
the Maven team is currently discussing a proposal about the future
handling
of source file encoding by the various plugins, please see our wiki
article
[0] for all details.
A
Because the Saxon guys haven't uploaded it yet. Ask them to do so.
Wayne
On 4/29/08, emerson cargnin [EMAIL PROTECTED] wrote:
Anyone knows why there is no saxon 8.8 on maven repository?
thanks
emerson
-
To unsubscribe,
+1 to c.
On Tue, Apr 29, 2008 at 8:51 AM, Jochen Wiedmann [EMAIL PROTECTED]
wrote:
On Tue, Apr 29, 2008 at 1:23 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
---clip---
I'd opt for
c) Use a configurable value, by default the current platform encoding.
Should be
* Upwards
Hi all,
I'm new to the list but I already read some documentation and the list
archive (2008) and did not find an answer to my problem. Maybe I don't
know where to search and I'm sorry about that!
It's a multi-project question ;-)
We are working on an OSGi project. I saw the
Milos Klient wrote:
Just a note, both solution allow one to have a reproducible builds if
one cares.
Absolutely. Just to further clarify: This poll is not about reproducibility
or not. Setting the encoding explicitly in the POM will always give you a
reproducible build, no matter where this
Generally, people use the assembly plugin for things of this nature.
Wayne
On 4/29/08, Arnaud Vandyck [EMAIL PROTECTED] wrote:
Hi all,
I'm new to the list but I already read some documentation and the list
archive (2008) and did not find an answer to my problem. Maybe I don't know
where to
Marat Radchenko wrote:
And let it be UTF-8.
Well, that's another story ;-)
The problem is we have already two plugins out (Site and Javadoc) that
employ Latin-1 as the default value. Either we have them break to use UTF-8,
too, or leave those two as exceptions to the rest of the plugins. Both
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a nightmare
to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your arguments here. Proper text editors allow you to select
the file
Manos Batsis wrote:
This should have been Rainer Pruy, I'm sorry.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Le 29-avr.-08 à 16:25, Wayne Fay a écrit :
Generally, people use the assembly plugin for things of this nature.
I thought it's only to generate .zip, .tar.gz, etc...
I'll investigate, thanks.
On 4/29/08, Arnaud Vandyck [EMAIL PROTECTED] wrote:
Hi all,
I'm new to the list but I already
Jochen Wiedmann wrote:
I'd opt for
c) Use a configurable value, by default the current platform encoding.
To my understanding, that's nothing more than variant a). Of course, we are
talking about a configurable value. Locking down plugins to any kind of
encoding without having a chance
Thanks I didn't think of using it like that.
Daniel King
Vurv
The information contained in this message may be privileged and
confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message
Hi all,
+1 [a]
with a few considerations (please, correct me if i'm wrong):
- backward compatibility is not a must, but a cost if not assured; runtime
charset errors (other than build-breaking ones) may be hard to detect
- most companies have uniform OS platforms; teams with non-uniform
Hi,
What is the status/roadmap of maven 2.1?
Thank you,
Ittay
--
Ittay Dror [EMAIL PROTECTED]
Tikal http://www.tikalk.com
Tikal Project http://tikal.sourceforge.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Brian E. Fox wrote:
Can you outline in what cases and in what ways this change could break
existing builds
Surely. About the cases that might suffer from the change: We propose to use
Latin-1 as the default encoding in case the user did not specify it. So
first up, everybody who already
definitely option [a]
respecting platform default encoding is the convention with the highest
weight,
and option [b] simply breaks this convention by not respecting platform
default encoding.
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b],
I just started having an issue with the Archetype plugin this morning. It
seems to have trouble downloading the velocity pom from path:
repo/velocity/velocity/1.5/velocity-1.5.pom off of our Artifactory instance.
Have I done something wrong?
Raphaël Piéroni-5 wrote:
The Maven team is pleased
Paolo Compieta wrote:
- most companies have uniform OS platforms
I am used to scenarios where people work on Unix/Win terminals or their
Unix/Mac/Win notebooks on their own discretion, creating quite some
heterogenous development culture. Might be one reason why I quickly had
locked down all
Hey,
No offense, I bet you're an American and never read the joke which involves
trilingual, bilingual and American
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms
My vote is [b]. Consistent builds are the very foundation upon which we operate.
Wayne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sherali,
On 4/29/08, Sherali Karimov [EMAIL PROTECTED] wrote:
+1 for the option b.
We had our share of builds behaving differently from OS to OS and from
region to region. :(
Excuse me, but I think this is your fault.
This is exactly the case where you should use explicit encoding
Like
Hello Mick.
First, is this a JPA project or a EJB3 one?
Regards
Johann Reyes
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers has LC_ALL
set to a different value, won't he be confused why
JPA.
My DAO signiture is:
public class BaseDaoJpaImplT, ID extends Serializable extends *
JpaDaoSupport*
implements BaseDaoT, ID {
On Tue, Apr 29, 2008 at 9:36 AM, Johann Reyes [EMAIL PROTECTED] wrote:
Hello Mick.
First, is this a JPA project or a EJB3 one?
Regards
Johann Reyes
Hi Benjamin,
Benjamin Bentmann schrieb:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your arguments here. Proper text
Roger Ye wrote:
No offense, I bet you're an American and never read the joke which
involves trilingual, bilingual and American
I am from Germany, not sure how close that counts to being American ;-)
Anyway, you're right, I can't remember the joke you referred to.
please consider what if in
Benjamin Bentmann schrieb:
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers has
LC_ALL set to a different
Wayne Fay schrieb:
My vote is [b]. Consistent builds are the very foundation upon which we
operate.
(Sorry Wayne it is not personal, I just came across that thought while reading
your post.)
Putting up a default behaviour that deviates from current default, will not
bring consistent
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
I vote for b). We recently had an encoding problem when we built a
project that was developed on Windows on a Unix server. Fortunately,
it caused a syntax error so that it was detected early. I can
k. I created a sample project that does what you want to do:
http://fisheye.codehaus.org/browse/mojo/trunk/mojo/hibernate3/hibernate3-maven-plugin/src/it/jpa-configuration-hsql
Let me know if this helps you or not.
Regards
Johann Reyes
Roger Ye wrote:
But is'nt this more an argument for get used to explicitly state
encoding than for
a maven wide default is better than a platform wide default?
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same applies to locking down plugin
Benjamin Bentmann schrieb:
Roger Ye wrote:
But is'nt this more an argument for get used to explicitly state
encoding than for
a maven wide default is better than a platform wide default?
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Paolo Compieta wrote:
- most companies have uniform OS platforms
I am used to scenarios where people work on Unix/Win terminals or their
Unix/Mac/Win notebooks on their own discretion, creating quite some
heterogenous development
Rainer Pruy wrote:
Putting up a default behaviour that deviates from current default, will
not bring consistent builds for those projects.
I would like to argue the opposite: If we consider a project whose POM does
not explicitly specify file encodings for the plugins in use, each developer
So at first, with adding your plugin declaration, I get this error:
*[INFO] [hibernate3:hbm2ddl {execution: hbm2ddl}]
[myproject] INFO [main] Version.clinit(15) | Hibernate EntityManager
3.2.0.GA
[myproject] INFO [main] Version.clinit(15) | Hibernate Annotations
3.2.0.GA
[myproject] INFO [main]
Roger Ye wrote:
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your
The scm:bootstrap seems to be checking everything out twice. Any ideas
why?
Here are the steps:
1) Removing the checkoutDirectory
2) Creating a temp client spec or workspace
3) Checking out the code
4) Deleting the checkout directory,
5) Rechecking it out the code again
6) Compiling
7) Testing
Rainer Pruy wrote:
I'm still not convinced that we will get their by trading one problematic
default for another.
I am not saying that this is the ultimate solution. I only believe it's a
compromise and improvement until we can introduce a new POM version in Maven
2.1, comparable to the Maven
Now when I changed the ... to annotations.
*I get this in my stack:*
*[myproject] INFO [main] Version.clinit(15) | Hibernate EntityManager
3.3.1.GA
[myproject] DEBUG [main] Ejb3Configuration.configure(302) | Processing
PersistenceUnitInfo [
name: ApplicationEntityManager
It looks like its missing the entity-manager dependency, do you have it
specified in your pom?
Regards
Johann Reyes
Oops. Here is what I changed
*
!--implementationjpaconfiguration/implementation--
implementationannotationconfiguration/implementation*
On Tue, Apr 29, 2008 at 10:52 AM, Mick Knutson [EMAIL PROTECTED]
wrote:
Now when I changed the ... to annotations.
*I get this
Manos Batsis wrote:
I hate this! Someone finally agrees with me but in a misquoted email; I
never wrote that :-)
As I said, that was my fault of getting the reply header wrong, I apologize
for this confusion. I didn't want to upset you Manos.
Benjamin
Benjamin Bentmann schrieb:
Rainer Pruy wrote:
Putting up a default behaviour that deviates from current default,
will not bring consistent builds for those projects.
I would like to argue the opposite: If we consider a project whose POM
does not explicitly specify file encodings for the
Benjamin Bentmann schrieb:
Rainer Pruy wrote:
I'm still not convinced that we will get their by trading one problematic
default for another.
I am not saying that this is the ultimate solution. I only believe it's a
compromise and improvement until we can introduce a new POM version in
Thanks for answer matinh!
Worse luck! Thats not the problem. I have tried the build on the shell als
well and the result is surprising!
Maven could not find the Plugin. Even a simple task like compiler:compile
failed because of the same problem With eclipse compiler:compile works fine!
Maybe
Hmm, so are you using JPA or EJB? because if it is JPA you need to use
jpaconfiguration. Just check that you have the dependencies as seen here:
http://fisheye.codehaus.org/browse/mojo/trunk/mojo/hibernate3/hibernate3-maven-plugin/src/it/jpa-configuration-hsql/pom.xml?r=6864
Regards
Johann
Rainer Pruy wrote:
This might be true for an all java world,
nevertheless, in case the maven default deviates from your platform one,
how does an editor know where to get the proper encoding for a given file?
(It would be quite difficult to enrich *any* editor around with some logic
to default
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
Old projects moving to new Maven builds will need to add a single
property in their pom, and then everything compiles fine etc. I
consider this maintenance and
Benjamin Bentmann schrieb:
Rainer Pruy wrote:
This might be true for an all java world,
nevertheless, in case the maven default deviates from your platform one,
how does an editor know where to get the proper encoding for a given
file?
(It would be quite difficult to enrich *any* editor
Roger Ye wrote:
we can survive if we explicitly set the source file encoding in the
project
pom.xml
Yes, this is right, explicitly setting the encoding is the golden answer.
But will you do so right from the beginning if your platform default
encoding happens to build as you expect or will
Wayne Fay wrote:
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
It's right that's old projects are not affected as long as we assume they
have locked down their plugin versions. The change we discuss
Wayne Fay schrieb:
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
Old projects moving to new Maven builds will need to add a single
property in their pom, and then everything compiles fine etc. I
Hi,
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same applies to locking down plugin versions by the
way. No guessing, no implicit default values, just full control, let's call
it heaven
+1 for a)
- People that don't care about it don't need to worry
- It works similarly within groups that share the same encodings
- When it breaks, because cross-unicode-script contributors are involved,
then it needs to be specified in the pom.
The downside of b) is that it forces all those who
Hello Zemian,
Can you share parts of your pom?
Thanks.
On Wed, Apr 23, 2008 at 10:01 PM, Zemian Deng [EMAIL PROTECTED]
wrote:
Hi,
I have successfully setup and bind assembly plugin in pom to generate my
custom jar file at package phase. But then the default jar:jar still get
run
during
Hello ragjan, have you run mvn clean before trying again?
On Thu, Apr 24, 2008 at 5:21 AM, I am Who i am [EMAIL PROTECTED] wrote:
No use
its still same here it is what i have
plugin
groupIdorg.apache.maven.plugins/groupId
+1 for a)
with a warning like [WARN] using detected local platform encoding 'xxx'. To
ensure build reproducibility, consider adding project.build.sourceEncoding
property to your pom
This won't break existing builds from users that don't even know their
encoding, but will help them do the right
I am using the examples from Spring in Action II. So I am not sure how to
determin that.
Here are my dependancies in my core:
dependencies
dependency
groupIdjavax.activation/groupId
artifactIdactivation/artifactId
version1.0.2/version
for maven 2.0.x i would go +1 for option a
for maven 2.1 I would go +1 for option b with my caveat being a proper
element of the pom and not shoved into the properties.
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
-
To
Roger Ye wrote:
For projects involving developers from different country (i.e. the
developers use different default encodings from one to another), it's a
must
for everyone in the team / project to understand that his/her default
encoding is not the default for others
Yes, it would be great
On Tue, Apr 29, 2008 at 10:38 PM, [EMAIL PROTECTED] wrote:
The differences are that I am using 3.3.2 and there is no RCP standalone
package for 3.3.2.
Sorry, I'm starting to run out of ideas.
Are you able to get the project build via ant?
the pde plugin just calls the ant build files, so if
Rainer Pruy wrote:
If already being unpolite why not in a way that will cause major
improvement on the situation by forcing users to stating encoding in any
case
Yes, as we talk about it, this becomes my personal favorite. I guess a
default value as originally proposed is only of value if it
walid joseph Gedeon wrote:
Note: it would probably be a good idea to include the encoding used
(whether
default or set) in the plugin report information.
Which kind of plugin report information are you referring to? E.g. where
exactly should the encoding used by the Maven Compiler Plugin be
1 - 100 of 116 matches
Mail list logo
