date:20080429


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 specify this in the POM. This poll should
help us to come to a well-founded decision.

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
  platform-dependent.

Approach a) matches the current behavior of most plugins and is as such
backwards-compatible. Approach b) on the other hand can potentially break
builds when users update to a newer version of an affected plugin if:
- the build relies on an encoding other than ASCII/Latin-1 and
- this encoding is not explicitly stated in the plugin configuration

The reason why b) was suggested is its positive effect on build
reproducibility: Unlike approach a), a build will out-of-the-box deliver the
same output for all team members regardless of their OS or locale. It is now
to balance if this improvement is worth the potential breaks as illustrated
above.

So, please let us know:

[a] Use platform default encoding, keep backward-compat
[b] Use fixed default encoding, be platform-independent

Regards,


Benjamin Bentmann


[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Sherali Karimov


+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 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 specify this in the POM. This poll  
should

help us to come to a well-founded decision.

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
  platform-dependent.

Approach a) matches the current behavior of most plugins and is as  
such
backwards-compatible. Approach b) on the other hand can potentially  
break

builds when users update to a newer version of an affected plugin if:
- the build relies on an encoding other than ASCII/Latin-1 and
- this encoding is not explicitly stated in the plugin configuration

The reason why b) was suggested is its positive effect on build
reproducibility: Unlike approach a), a build will out-of-the-box  
deliver the
same output for all team members regardless of their OS or locale.  
It is now
to balance if this improvement is worth the potential breaks as  
illustrated

above.

So, please let us know:

[a] Use platform default encoding, keep backward-compat
[b] Use fixed default encoding, be platform-independent

Regards,


Benjamin Bentmann


[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source 
+File+Encoding



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [POLL] Default Value for File Encoding

2008-04-29 Thread Jörg Schaible


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 details.
 
 A controversial aspect of this proposal is which file
 encoding should be
 assumed in case the user did not specify this in the POM.
 This poll should
 help us to come to a well-founded decision.
 
 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
 notplatform-dependent. 
 
 Approach a) matches the current behavior of most plugins and
 is as such
 backwards-compatible. Approach b) on the other hand can
 potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration
 
 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will
 out-of-the-box deliver the
 same output for all team members regardless of their OS or
 locale. It is now
 to balance if this improvement is worth the potential breaks
 as illustrated
 above.
 
 So, please let us know:
 
 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent
 
 Regards,
 
 
 Benjamin Bentmann
 
 
 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Sou
 rce+File+Encoding 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Milos Kleint

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 across plugins.
However option b. can potentially break existing builds that relied on
existing behaviour.

Milos

On Tue, Apr 29, 2008 at 1:37 PM, Jörg Schaible
[EMAIL PROTECTED] wrote:

  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 details.
  
   A controversial aspect of this proposal is which file
   encoding should be
   assumed in case the user did not specify this in the POM.
   This poll should
   help us to come to a well-founded decision.
  
   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
   notplatform-dependent.
  
   Approach a) matches the current behavior of most plugins and
   is as such
   backwards-compatible. Approach b) on the other hand can
   potentially break
   builds when users update to a newer version of an affected plugin if:
   - the build relies on an encoding other than ASCII/Latin-1 and
   - this encoding is not explicitly stated in the plugin configuration
  
   The reason why b) was suggested is its positive effect on build
   reproducibility: Unlike approach a), a build will
   out-of-the-box deliver the
   same output for all team members regardless of their OS or
   locale. It is now
   to balance if this improvement is worth the potential breaks
   as illustrated
   above.
  
   So, please let us know:
  
   [a] Use platform default encoding, keep backward-compat
   [b] Use fixed default encoding, be platform-independent
  
   Regards,
  
  
   Benjamin Bentmann
  
  
   [0]
   http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Sou
   rce+File+Encoding
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Christian Kölle

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.

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Felix Knecht




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 result in 
troubles when sharing the project among different OS / Countries / ...


Regards
Felix


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread nicolas de loof

+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 don't have to read
the release note to see deprecations, warning and upgrade notice !

Nico


2008/4/29 Benjamin Bentmann [EMAIL PROTECTED]:

 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 specify this in the POM. This poll should
 help us to come to a well-founded decision.

 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
  platform-dependent.

 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration

 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
 same output for all team members regardless of their OS or locale. It is
 now
 to balance if this improvement is worth the potential breaks as
 illustrated
 above.

 So, please let us know:

 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent

 Regards,


 Benjamin Bentmann


 [0]

 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Paul Benedict

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 Tue, Apr 29, 2008 at 6:55 AM, Felix Knecht [EMAIL PROTECTED] wrote:


  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 result in troubles when sharing
 the project among different OS / Countries / ...

 Regards
 Felix



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Plugin warning (was: Re: [POLL] Default Value for File Encoding)

2008-04-29 Thread Manos Batsis


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 get the change 
should implement some API for Maven to be aware of their conformance and 
output a warning during the build in the case of a non-conforming plugin.


As an example to make up for my havent_had_coffee_yet english, this 
could be easily done by adding something like this in 2.1's AbstractMojo:


public boolean isSourceEncodingAware(){
return false;
}


Maven could check all plugins at an early build stage and output a 
warning for the non-conforming ones. Plugin builders should be 
responsible of both overriding this and ensuring their code reads files 
properly.


Cheers,

Manos



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

+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 encoding the local 
system lives in)
we should deprecate any file operation that fails stating an explicit encoding 
and this way encourage users to explicitly state the
encoding in use.

Actually, I'm in favour of

c)  a) + discourage any use of files that do not state encoding explicitly 
(probably pom 4.0.1 could require stating an explicit
encoding?)


This way backward compatibility is achieved for old projects.
Any new ones may use any encoding appropriate for local use (and this may 
change form version to version).
But on the other hand correct interpretation is ensured as there will be no 
doubt what encoding to use for interpreting files.

(Probably a encoding element at pom level will suffice for the start)

Rainer


Benjamin Bentmann schrieb:
 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 specify this in the POM. This poll should
 help us to come to a well-founded decision.
 
 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
   platform-dependent.
 
 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration
 
 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
 same output for all team members regardless of their OS or locale. It is
 now
 to balance if this improvement is worth the potential breaks as illustrated
 above.
 
 So, please let us know:
 
 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent
 
 Regards,
 
 
 Benjamin Bentmann
 
 
 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: How to set up dependencies right for ejb projects

2008-04-29 Thread Arand, Thomas (NSN - DE/Muenich)


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 dependency in that other
project,
 what is definitely not wanted.

While I agree with you that the 2 provided solutions are more
workarounds 
than solutions, I have to say that if a project needs some server 
dependencies, it has to declare it anyway and should not rely on
transitiv 
dependencies.

In principle you are right, but not in this particular case. When
building the ear file for
an EJB (note that this is done in another maven project than the EJB
project itself) one step 
is the calculation of the classpath that must be set to run the
server-part of the EJB. For
this step the affected maven-plugin uses the transitive dependencies of
the EJB project.

- Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Mauro Talevi

+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 article
[0] for all details.

A controversial aspect of this proposal is which file encoding should be
assumed in case the user did not specify this in the POM. This poll should
help us to come to a well-founded decision.

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
  platform-dependent.

Approach a) matches the current behavior of most plugins and is as such
backwards-compatible. Approach b) on the other hand can potentially break
builds when users update to a newer version of an affected plugin if:
- the build relies on an encoding other than ASCII/Latin-1 and
- this encoding is not explicitly stated in the plugin configuration

The reason why b) was suggested is its positive effect on build
reproducibility: Unlike approach a), a build will out-of-the-box deliver 
the
same output for all team members regardless of their OS or locale. It is 
now

to balance if this improvement is worth the potential breaks as illustrated
above.

So, please let us know:

[a] Use platform default encoding, keep backward-compat
[b] Use fixed default encoding, be platform-independent

Regards,


Benjamin Bentmann


[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Marat Radchenko

+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 controversial aspect of this proposal is which file encoding should be
  assumed in case the user did not specify this in the POM. This poll should
  help us to come to a well-founded decision.

  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
   platform-dependent.

  Approach a) matches the current behavior of most plugins and is as such
  backwards-compatible. Approach b) on the other hand can potentially break
  builds when users update to a newer version of an affected plugin if:
  - the build relies on an encoding other than ASCII/Latin-1 and
  - this encoding is not explicitly stated in the plugin configuration

  The reason why b) was suggested is its positive effect on build
  reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
  same output for all team members regardless of their OS or locale. It is
 now
  to balance if this improvement is worth the potential breaks as illustrated
  above.

  So, please let us know:

  [a] Use platform default encoding, keep backward-compat
  [b] Use fixed default encoding, be platform-independent

  Regards,


  Benjamin Bentmann


  [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding


 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Jochen Wiedmann

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
   platform-dependent.

I'd opt for

c) Use a configurable value, by default the current platform encoding.

Should be

  * Upwards compatible
  * Simplify the use of Maven for people who don't need to care for that value.
(Most development teams have uniform development platforms, or at least
uniform default encodings.)
  * Make reproducable builds possible for the rest.




-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

 -- (Terry Pratchett, Thief of Time)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Paul MERLIN

+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 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 specify this in the POM. This poll should
 help us to come to a well-founded decision.

 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
platform-dependent.

 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration

 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the same output for all team members regardless of their OS or locale. It
 is now to balance if this improvement is worth the potential breaks as
 illustrated above.

 So, please let us know:

 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent

 Regards,


 Benjamin Bentmann


 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Enco
ding


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven pde rcp to build

2008-04-29 Thread thenew05

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 project to the C: directory, and I get this error,
but I
can not find where this is being called from. It seems like it is
failing on
the second run of the generateFeature target. I can not find where this
is
looking for this plug-in name value.

C:\mavenpde\test.pde_maven_plugin.simple_applicationmvn install
[del]
BUILD FAILED

C:\Program

Files\JavaWorkEnv\eclipse\plugins\org.eclipse.pde.build_3.3.2.v20071019\scripts\productBuild\productBuild.xml
:24: The following error occurred while executing this line:

C:\Program

Files\JavaWorkEnv\eclipse\plugins\org.eclipse.pde.build_3.3.2.v20071019\scripts\productBuild\productBuild.xml
:52: *Unable to find plug-in:
test.pde_maven_plugin.simple_application.*Please check the error log
for more details.

Did you follow the step Confirm the Project works?

If you can not run your project inside eclipse then there is no way
Maven and the PDE ant plugin will work.

Did you read the Getting Started guide?
http://mojo.codehaus.org/pde-maven-plugin/examples/getting_started.html

You can download working copies of the tutorials.
Make sure you can get those to work and then use that learning on your
own projects.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

When will maven-checkstyle-plugin 2.2 be released?

2008-04-29 Thread Hurragutt

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,
Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven pde rcp to build

2008-04-29 Thread thenew05

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.

On Mon, Apr 28, 2008 at 6:57 PM, Barrie Treloar [EMAIL PROTECTED]
wrote:

C:\mavenpde\test.pde_maven_plugin.simple_applicationmvn install
[del]
BUILD FAILED

C:\Program

Files\JavaWorkEnv\eclipse\plugins\org.eclipse.pde.build_3.3.2.v20071019\scripts\productBuild\productBuild.xml
:24: The following error occurred while executing this line:

C:\Program

Did you follow the step Confirm the Project works?

If you can not run your project inside eclipse then there is no way
Maven and the PDE ant plugin will work.

Did you read the Getting Started guide?
http://mojo.codehaus.org/pde-maven-plugin/examples/getting_started.html

You can download working copies of the tutorials.
Make sure you can get those to work and then use that learning on your
own projects.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scm:checkout question

2008-04-29 Thread Emmanuel Venisse

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 fresh copy of a project without a pom.xml or is
 this impossible? I'm assuming it is impossible just like ant needs a
 build.xml.  However how do most people checkout a project without the
 pom.xml the first time? If I copy the pom.xml and put it in my directory
 and then call mvn scm:bootstrap it will checkout my code, compile, run
 tests and install since I have a goal of install in the configuration.



   build

plugins

  plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-scm-plugin/artifactId

configuration

  connectionTypeconnection/connectionType

  goalsinstall/goals

/configuration

  /plugin

/plugins

  /build



 The reason I ask is because our build team deletes the project area at
 the beginning of every build.



 Also is scm:bootstrap the best way to checkout, compile, run tests and
 install? I might need to change that goal to deploy since the build team
 wants to do all those steps and then put it in our internal repo.



 Thanks,

 Daniel King

RE: zip dependency

2008-04-29 Thread Brian E. Fox

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 dependency

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 to a jar dependency everything works fine (i changed the
dependency declaration in my pom's project, the name of the archive, the
pom
of the repository).
So, I guess maven doesn't put the zip dependecies in the classpath. Is
it
normal? If yes, is there a way to fix this problem but not by renaming
my
dependency to a jar?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scm:checkout question

2008-04-29 Thread Emmanuel Venisse

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] -Dgoal=deploy

Emmanuel

On Mon, Apr 28, 2008 at 11:11 PM, Daniel King [EMAIL PROTECTED] wrote:

 How can you checkout a fresh copy of a project without a pom.xml or is
 this impossible? I'm assuming it is impossible just like ant needs a
 build.xml.  However how do most people checkout a project without the
 pom.xml the first time? If I copy the pom.xml and put it in my directory
 and then call mvn scm:bootstrap it will checkout my code, compile, run
 tests and install since I have a goal of install in the configuration.



   build

plugins

  plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-scm-plugin/artifactId

configuration

  connectionTypeconnection/connectionType

  goalsinstall/goals

/configuration

  /plugin

/plugins

  /build



 The reason I ask is because our build team deletes the project area at
 the beginning of every build.



 Also is scm:bootstrap the best way to checkout, compile, run tests and
 install? I might need to change that goal to deploy since the build team
 wants to do all those steps and then put it in our internal repo.



 Thanks,

 Daniel King

RE: How to set up dependencies right for ejb projects

2008-04-29 Thread Jörg Schaible

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 project,
 what is definitely not wanted.
 2. would require exclude statements in all other projects using the
 client part. This is also definitely not wanted.

Not necessarily. Use a common parent POM where the ejb-client is declared with 
all exclusions inthe dependencyManagement. With this declaration all projects 
depending on the ejb-client will only inherit anything that is not excluded.

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [POLL] Default Value for File Encoding

2008-04-29 Thread Brian E. Fox

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, April 29, 2008 7:24 AM
To: users@maven.apache.org
Subject: [POLL] Default Value for File Encoding

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 specify this in the POM. This poll
should
help us to come to a well-founded decision.

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
   platform-dependent.

Approach a) matches the current behavior of most plugins and is as such
backwards-compatible. Approach b) on the other hand can potentially
break
builds when users update to a newer version of an affected plugin if:
- the build relies on an encoding other than ASCII/Latin-1 and
- this encoding is not explicitly stated in the plugin configuration

The reason why b) was suggested is its positive effect on build
reproducibility: Unlike approach a), a build will out-of-the-box deliver
the
same output for all team members regardless of their OS or locale. It is
now
to balance if this improvement is worth the potential breaks as
illustrated
above.

So, please let us know:

[a] Use platform default encoding, keep backward-compat
[b] Use fixed default encoding, be platform-independent

Regards,


Benjamin Bentmann


[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+E
ncoding


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread ruimo


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 controversial aspect of this proposal is which file encoding should be
 assumed in case the user did not specify this in the POM. This poll should
 help us to come to a well-founded decision.
 
 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
platform-dependent.
 
 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration
 
 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
 same output for all team members regardless of their OS or locale. It is
 now
 to balance if this improvement is worth the potential breaks as
 illustrated
 above.
 
 So, please let us know:
 
 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent
 
 Regards,
 
 
 Benjamin Bentmann
 
 
 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16960887.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Saxon 8.8 in the maven repository

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, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Thierry Lach

+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 compatible
  * Simplify the use of Maven for people who don't need to care for that
 value.
(Most development teams have uniform development platforms, or at least
uniform default encodings.)
  * Make reproducable builds possible for the rest.




 --
 Look, that's why there's rules, understand? So that you think before
 you break 'em.

  -- (Terry Pratchett, Thief of Time)

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

OSGi project architecture

2008-04-29 Thread Arnaud Vandyck


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 maven-bundle-plugin from  
the Felix project and we are transforming our dependencies with it. We  
deploy them on a private repo.


We have a structure like this:

MainProject
  +-- pom.xml
  +-- src/site/...
  |
  +-- core
  |  +-- pom.xml
  |  +-- src/main/java/...
  |
  +-- log4j-osgi-fragment
  |  +-- src/main/resources/log4j.properties
  |
  \-- anotherbundle
 +-- pom.xml
 +-- src/main/java/...

What we'd like is: when you mvn package, you have something like this:

MainProject
  +-- ...
  |
  \-- target
 +-- equinoxe-X.Y.Z.jar (launcher)
 +-- configurations
 |  +-- config.ini
 |
 +-- features
 |  +-- core-1.0-SNAPSHOT.jar
 |  +-- anotherbundle-1.0-SNAPSHOT.jar
 |
 \-- plugins
+-- log4j-osgi-1.2.13.jar

Is there a plugin that can do that or do we have to consider writing  
our own plugin?


Many thanks for your time and attention.

PS: maven is really cool to use! :-D

--
Arnaud Vandyck
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 discussion ends. This poll is
merely about the question, whether this reproducibility comes
out-of-the-box or requires explicit user configuration. Also, out-of-the-box
reproducibility here does not mean that all builds will work with our
proposed default value of Latin-1, users will likely want to override this
value for the projects. But the major point is it will work for everybody on
the project or for nobody, no more works (just) for me.


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OSGi project architecture

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 search and I'm sorry about that!

 It's a multi-project question ;-)

 We are working on an OSGi project. I saw the maven-bundle-plugin from the
 Felix project and we are transforming our dependencies with it. We deploy
 them on a private repo.

 We have a structure like this:

 MainProject
  +-- pom.xml
  +-- src/site/...
  |
  +-- core
  |  +-- pom.xml
  |  +-- src/main/java/...
  |
  +-- log4j-osgi-fragment
  |  +-- src/main/resources/log4j.properties
  |
  \-- anotherbundle
 +-- pom.xml
 +-- src/main/java/...

 What we'd like is: when you mvn package, you have something like this:

 MainProject
  +-- ...
  |
  \-- target
 +-- equinoxe-X.Y.Z.jar (launcher)
 +-- configurations
 |  +-- config.ini
 |
 +-- features
 |  +-- core-1.0-SNAPSHOT.jar
 |  +-- anotherbundle-1.0-SNAPSHOT.jar
 |
 \-- plugins
+-- log4j-osgi-1.2.13.jar

 Is there a plugin that can do that or do we have to consider writing our own
 plugin?

 Many thanks for your time and attention.

 PS: maven is really cool to use! :-D

 --
 Arnaud Vandyck
 [EMAIL PROTECTED]




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 ways
are not golden. Until a flood of users pushes into this direction of UTF-8,
which is surely the more international/nicer choice, I believe we're better
off with staying to Latin-1 and keep consistency among the plugins.


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 encoding you save your files in, so the system default encoding 
should not matter.


we should deprecate any file operation that fails stating an explicit 
encoding and this way encourage users to explicitly state the encoding in 
use.


I'm not sure what you mean with file operation.

We have feature requests out for PMD and Checkstyle to detect usage of 
problematic IO APIs like java.io.FileReader and I know that already some 
work on these has been started.


As for the Maven plugins themselves and their file handling: We don't need 
to deprecate things here. Every plugin that reads/writes plain text files 
should offer an encoding parameter for the user to configure the correct 
file encoding. Work on extending unconfigurable plugins with such a 
parameter is in progress/scheduled.



c)  a) + discourage any use of files that do not state encoding explicitly


I take this as a vote for a) with the intention to output a warning in case 
the encoding was not specified. Please correct me if I misunderstood you.



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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]

Re: OSGi project architecture

2008-04-29 Thread Arnaud Vandyck


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 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 maven-bundle-plugin  
from the
Felix project and we are transforming our dependencies with it. We  
deploy

them on a private repo.

We have a structure like this:

MainProject
+-- pom.xml
+-- src/site/...
|
+-- core
|  +-- pom.xml
|  +-- src/main/java/...
|
+-- log4j-osgi-fragment
|  +-- src/main/resources/log4j.properties
|
\-- anotherbundle
   +-- pom.xml
   +-- src/main/java/...

What we'd like is: when you mvn package, you have something like  
this:


MainProject
+-- ...
|
\-- target
   +-- equinoxe-X.Y.Z.jar (launcher)
   +-- configurations
   |  +-- config.ini
   |
   +-- features
   |  +-- core-1.0-SNAPSHOT.jar
   |  +-- anotherbundle-1.0-SNAPSHOT.jar
   |
   \-- plugins
  +-- log4j-osgi-1.2.13.jar

Is there a plugin that can do that or do we have to consider  
writing our own

plugin?

Many thanks for your time and attention.

PS: maven is really cool to use! :-D

--
Arnaud Vandyck
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Arnaud Vandyck
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 of customization would be a design flaw par 
excellence.


Some day in the future, each and every plugin should offer a configuration 
parameter to control the encoding for its input/output files. So that is the 
finest grained control with regard to configuration. Next up, we are 
planning on a central POM property/element where users specify the file 
encoding for all their plugins. The already mentioned wiki article outlines 
this in more detail.


This thread is only about the situation in which a user did *not* configure 
the encoding but expects the build to use some default value.  Taking this 
default from the platform or from an established convention is the remaining 
question.



Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: scm:checkout question

2008-04-29 Thread Daniel King

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 to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify me immediately by replying to the
message and deleting it from your computer. Thank you. 

-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 29, 2008 9:23 AM
To: Maven Users List
Subject: Re: scm:checkout question

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] -Dgoal=deploy

Emmanuel

On Mon, Apr 28, 2008 at 11:11 PM, Daniel King [EMAIL PROTECTED] wrote:

 How can you checkout a fresh copy of a project without a pom.xml or is
 this impossible? I'm assuming it is impossible just like ant needs a
 build.xml.  However how do most people checkout a project without the
 pom.xml the first time? If I copy the pom.xml and put it in my
directory
 and then call mvn scm:bootstrap it will checkout my code, compile, run
 tests and install since I have a goal of install in the configuration.



   build

plugins

  plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-scm-plugin/artifactId

configuration

  connectionTypeconnection/connectionType

  goalsinstall/goals

/configuration

  /plugin

/plugins

  /build



 The reason I ask is because our build team deletes the project area at
 the beginning of every build.



 Also is scm:bootstrap the best way to checkout, compile, run tests and
 install? I might need to change that goal to deploy since the build
team
 wants to do all those steps and then put it in our internal repo.



 Thanks,

 Daniel King










-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Paolo Compieta


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
developing environments have already faced this problem: editing a file with
a different encoding requires some thought.. far before building
- most editors allow you select a proper charset, but they (usually)
automatically detect the default (file.encoding); it'd be not comfortable
changing every time the charset to a different one only because maven said
this is the standard; i.e., i wouldn't exchange platform-dependence with
implicit charset-dependence (potential drawbacks on all other kinds of
editor - java/sql/xml/properties/..)
- big trans-national companies (should!) have centralized and
well-configured building-machine to be asked for deliverables; those
deliverables are surely reproducible and should be deployed to
official/uniform testing and production environments

regards,
Paolo


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 controversial aspect of this proposal is which file encoding should be
 assumed in case the user did not specify this in the POM. This poll should
 help us to come to a well-founded decision.
 
 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
platform-dependent.
 
 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration
 
 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
 same output for all team members regardless of their OS or locale. It is
 now
 to balance if this improvement is worth the potential breaks as
 illustrated
 above.
 
 So, please let us know:
 
 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent
 
 Regards,
 
 
 Benjamin Bentmann
 
 
 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16963039.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

what is the status of maven 2.1?

2008-04-29 Thread Ittay Dror


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 commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 explicitly declares an encoding will not
notice the change, i.e. if your POM looks like

 plugin
   artifactIdmaven-compiler-plugin/artifactId
   configuration
 encodingbig5/encoding
 ...
   /confinguration
 /plugin

the build will work just as before (using big5) when you switch to the newer
plugin version that incorporates our proposal.

In contrast, the build will likely break if you effectively use an encoding
other than Latin-1 or ASCII (ASCII is just a subset of Latin-1) but did not
declare this in the configuration for the various plugins. The prime example
for potentially affected builds seem to be Asian projects that naturally use
the Non-Western encoding of the platforms (compare the comments on our wiki
article).

As for the kind of break: The best case is a plugin that entirely refuses
its work via an exception because the file contents it is trying to process
violates the assumed encoding (e.g. Latin-1 byte sequences are in general
not valid UTF-8 byte sequences). Why do I call this build failure a best
case? Because it tells you straight out that the desired encoding needs to
be declared in the POM. The other way is a plugin that works but silently
outputs garbage. This is more subtle but it requires human review to detect.
That's easy if you know where to look (Non-ASCII characters) but again
requires a user being aware of the issue.


and what it would take for the user to fix?


In one line: State the encoding you want to use in the POM.

The POM is our means to configure a build. If its default values don't fit
your need, you can always go ahead and explicitly add the configuration
element.

When we consider the state as is, i.e. the release versions of the plugins
and Maven, that means to configure each and every plugin separately. Once we
have the plugin versions released that follow our proposal and adhere to the
convention of evaluating the POM property ${project.build.sourceEncoding},
this configuration can in most cases reduced to adding

 properties
   project.build.sourceEncoding.../project.build.sourceEncoding
 /properties


 Could a tool be created to correct it automatically?


I believe the answer is no. This is basically related to the discussion we
had over on dev@ with Jason regarding the usage of JChardet [0]. A machine
tool cannot reliable tell what file encoding your sources use (because it
would need to semantically understand text). So this a human task but that
should be easily done.


Benjamin


[0]
http://www.nabble.com/-VOTE--POM-Element-for-Source-File-Encoding-to16515820s177.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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], when maven uses another
encoding such as utf-8
this is just an example and may not be the actual case, surely I know utf-8
is a good thing

furthermore, if a lot of applications behave like option [b], but
unfortunately they use inconsistent default encoding,
then you know what a hell is.

and always respecting platform default encoding is the correct way to make
an application encoding-transparent
so the application developer don't need to worry about converting
back-n-forth between several encodings/charsets,
given the context of a standalone system as a sandbox.

IMO, e.g.,  networking related applications, have to deal with encoding,
this is by nature, since network is used to connect
people from different places.

If the developer of a multi-encoding application don't understand what
encoding is, he/she should learn it, you just
can not assume the multi-encoding application as a single-encoding
application

an encoding, to a text parser application, is like the language spoked to
the audience,  you just can not assume
the speaker of any lecture always uses English.

It's easy for people to know that there are so many languages spoked in the
world, it's just one more step further
to understand that different text parsers also read in different encodings


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 controversial aspect of this proposal is which file encoding should be
 assumed in case the user did not specify this in the POM. This poll should
 help us to come to a well-founded decision.

 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
  platform-dependent.

 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration

 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the
 same output for all team members regardless of their OS or locale. It is
 now
 to balance if this improvement is worth the potential breaks as
 illustrated
 above.

 So, please let us know:

 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent

 Regards,


 Benjamin Bentmann


 [0]

 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Maven Archetype Plugin 2.0-alpha-3 Released

2008-04-29 Thread Clifton


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 to announce the release of the Maven
 Archetype Plugin, version 2.0-alpha-3
 
 The Archetype Plugin allows the user to create a Maven 2 project from
 an existing template called an archetype. It also allows the user to
 create an archetype from an existing project.
 
 http://maven.apache.org/plugins/maven-archetype-plugin/
 
 
 Release Notes - Maven Archetype - Version 2.0-alpha-3
 
 ** Bug
 * [ARCHETYPE-122] - The defined artifact is not an archetype?
 * [ARCHETYPE-124] - custom archetype-catalog.xml not read
 * [ARCHETYPE-126] - Site menu is corrupted
 * [ARCHETYPE-129] - incorrect error handling in batch mode
 * [ARCHETYPE-130] - selecting N to is this correct question
 resets all variables, even those that were input from the command line
 * [ARCHETYPE-132] - The create-from-project goal does not work on
 windows for multi-module projects
 * [ARCHETYPE-137] - Problem when setting default values for
 archetype-metadata.xml
 * [ARCHETYPE-139] - cannot create archetype for existing project
 without pre-existing pom
 * [ARCHETYPE-140] - archetype:generate doesn't support inserting a
 module into a multi-module build like :create did
 * [ARCHETYPE-141] - wrong goal name in docs
 * [ARCHETYPE-144] - Fails archetype:create when specify
 archetypeVersion
 * [ARCHETYPE-146] - Archetype Resources not being processed on
 Windows.
 * [ARCHETYPE-149] - archetype generate -DarchetypeRepository not
 working
 * [ARCHETYPE-150] - New maven-archetype-plugin ignores the
 remoteRepositories system property
 * [ARCHETYPE-153] - Multimodule archetype does not propagate the
 artifactId in module names.
 * [ARCHETYPE-159] - mvn archetype:generate is failing to download
 needed archetype artifacts
 * [ARCHETYPE-160] - [regression] the default (15) is no longer
 present in generate
 
 ** Improvement
 * [ARCHETYPE-109] - plugins should have a auto-generated goal help
 * [ARCHETYPE-112] - Allow to configure the filteredExtentions from
 the archetype.properties file
 * [ARCHETYPE-135] - add a variabl containing package in a path format
 * [ARCHETYPE-143] - Add the possibility to generate files at project's
 root
 
 ** Wish
 * [ARCHETYPE-154] - Can i ask when will alpha-3 released
 
 
 
 Enjoy,
 
 -The Maven team
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/-ANN--Maven-Archetype-Plugin-2.0-alpha-3-Released-tp16949530s177p16963772.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 encoding settings in our corporate POM...


- most editors allow you select a proper charset, but they (usually)
automatically detect the default (file.encoding); it'd be not
comfortable
changing every time the charset to a different one only because maven said
this is the standard; i.e., i wouldn't exchange platform-dependence with
implicit charset-dependence (potential drawbacks on all other kinds of
editor - java/sql/xml/properties/..)


If the proposed default value matches your platform encoding, you're just
fine. If it doesn't, you would simply configure your POM accordingly (i.e. 
configure Maven for your needs and not vice-versa) and both you and in 
particular all your co-workers are fine for the rest of their life, too. You 
don't promote to edit the same file with different encodings selected for 
your editor, don't you?



- big trans-national companies (should!) have centralized and
well-configured building-machine to be asked for deliverables;


Wouldn't you want to be able to create the same build output on your own dev
machine than the output from these centralized and well-configured
building-machine? For that reason, the encoding should be bound to the POM
(which is shared among all participants) in contrast to OS or locale.


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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 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 encoding you save your files in, so the system default
 encoding should not matter.


no offense, but this is your problem  for not being able to follow Manos's
arguments here,
please consider what if in Linux you've set LC_ALL=en_US.UTF-8, but in your
system no application respects this system wide setting.

we should deprecate any file operation that fails stating an explicit
  encoding and this way encourage users to explicitly state the encoding in
  use.
 

 I'm not sure what you mean with file operation.


easy, file reading and file writing, or file I/O, consider such APIs,
please.

We have feature requests out for PMD and Checkstyle to detect usage of
 problematic IO APIs like java.io.FileReader and I know that already some
 work on these has been started.

 As for the Maven plugins themselves and their file handling: We don't need
 to deprecate things here. Every plugin that reads/writes plain text files
 should offer an encoding parameter for the user to configure the correct
 file encoding. Work on extending unconfigurable plugins with such a
 parameter is in progress/scheduled.

  c)  a) + discourage any use of files that do not state encoding
  explicitly
 

 I take this as a vote for a) with the intention to output a warning in
 case the encoding was not specified. Please correct me if I misunderstood
 you.


Maybe an INFO is better for you, but if your maven powered project has
developers from all over the world, you'll understand a warning is rather
important.

Benjamin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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]

Re: [POLL] Default Value for File Encoding

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 in a multi-national meeting you should rule for a common language such
as English
or you'll have a mess instead of a meeting :P

Re: [m2] can't get hibernate plugin to work with hsql

Hello Mick.

First, is this a JPA project or a EJB3 one?

Regards

Johann Reyes

Re: [POLL] Default Value for File Encoding


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 the build is failing for 
him when you just tell works for me? The same POM should deliver the same 
build output, that's just what I consider of highest weight.



and always respecting platform default encoding is the correct way to make
an application encoding-transparent


I feel I misunderstand you. From your description, I imagine a world were 
text editors don't bother to ask users for an encoding but simply always use 
platform default encoding. In such a world, I wonder how people would 
collaboratively work on the same sources.



so the application developer don't need to worry about converting
back-n-forth between several encodings/charsets,


Considering the internet and its wonderful aspect of bringing people all 
over the world together, I really believe it is time that application 
developers *do* worry about encoding and converting file contents to pull 
down the walls that our different locales or OS impose.


Imagine two open-source projects, one using UTF-8 and the other Big5. How 
would people participate on these projects (using the same machine) if we 
expected applications to always stick to one system-wide encoding setting?



IMO, e.g.,  networking related applications, have to deal with encoding,
this is by nature, since network is used to connect
people from different places.


Let's remember that Maven is just sitting next to a networking related 
application, i.e. source control management.



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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




-- 
Thanks,
Mick Knutson

http://www.baselogic.com
http://www.blincmagazine.com
http://www.linkedin.com/in/mickknutson
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---

Re: [POLL] Default Value for File Encoding

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 editors allow you to
 select the file encoding you save your files in, so the system default
 encoding should not matter.
 

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 to maven encoding in case there is a pom along
the path. so, it might work for IDEs where all aspects are tightly integrated..)

(Personally, I would not like to be forced to dump good ol' vi (;-))

 we should deprecate any file operation that fails stating an explicit
 encoding and this way encourage users to explicitly state the encoding
 in use.
 
 I'm not sure what you mean with file operation.

here: reading from and writing to files

 
 We have feature requests out for PMD and Checkstyle to detect usage of
 problematic IO APIs like java.io.FileReader and I know that already some
 work on these has been started.
 
 As for the Maven plugins themselves and their file handling: We don't
 need to deprecate things here. Every plugin that reads/writes plain text
 files should offer an encoding parameter for the user to configure the
 correct file encoding. Work on extending unconfigurable plugins with
 such a parameter is in progress/scheduled.
 

Sorry for not being precise enough.
I did not mean deprecation in the specific meaning of interface elements.

It was more towards arranging for any file operation (see above) without 
explicit stated encoding to fail (ok, this might be to
tough, but a warning would be minimum here)

 c)  a) + discourage any use of files that do not state encoding
 explicitly
 
 I take this as a vote for a) with the intention to output a warning in
 case the encoding was not specified. Please correct me if I
 misunderstood you.
 

You are right: As I stated at the very top of my message: +1 for a)


This poll is about default without any explicit setting.
a) is the least disturbing one for users and teams within a homogeneous 
environment.
As inhomogeneous teams already face problems and sure will come to using 
encoding config quickly,
a) is least disturbing.

Rainer
 
 Benjamin
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 Linux you've set LC_ALL=en_US.UTF-8, but in 
your system no application respects this system wide setting.


I just mean system wide is quite coarse granular. Had you never the need 
to change this setting on a per-application basis?



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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 value, won't he be confused why the build is
 failing for him when you just tell works for me? The same POM should
 deliver the same build output, that's just what I consider of highest
 weight.

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?
Or just a warning for not to expect whole world is just using your preferred 
encoding?

 
 and always respecting platform default encoding is the correct way to
 make
 an application encoding-transparent
 
 I feel I misunderstand you. From your description, I imagine a world
 were text editors don't bother to ask users for an encoding but simply
 always use platform default encoding. In such a world, I wonder how
 people would collaboratively work on the same sources.
 
 so the application developer don't need to worry about converting
 back-n-forth between several encodings/charsets,
 
 Considering the internet and its wonderful aspect of bringing people all
 over the world together, I really believe it is time that application
 developers *do* worry about encoding and converting file contents to
 pull down the walls that our different locales or OS impose.

Fully agreed!
But, the discussion is about implied defaults not evangelizing explicit 
encoding declarations.
Cooperating people from different encoding worlds are usually already quite 
aware of those problems and used to attacking them.
Defining a default maven encoding brings this problem to solitaire users that 
just happen to live in a different encoding world than
maven default...

 
 Imagine two open-source projects, one using UTF-8 and the other Big5.
 How would people participate on these projects (using the same machine)
 if we expected applications to always stick to one system-wide encoding
 setting?
 
 IMO, e.g.,  networking related applications, have to deal with encoding,
 this is by nature, since network is used to connect
 people from different places.
 
 Let's remember that Maven is just sitting next to a networking related
 application, i.e. source control management.
 
 
 Benjamin
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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 builds for those projects.
Most likely the files are not compatible with the new implied default.

So the only intention can be ensuring consistent builds for any *future* 
project (version).
Thus flagging encoding problems will improve awareness and will surely 
contribute more to consistent builds that changing the rules
on the game...
Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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 has
 LC_ALL set to a different value, won't he be confused why the build is
 failing for him when you just tell works for me? The same POM should
 deliver the same build output, that's just what I consider of highest
 weight.


we can survive if we explicitly set the source file encoding in the project
pom.xml, this is visible and the overriding logic is reasonable.

and always respecting platform default encoding is the correct way to make
  an application encoding-transparent
 

 I feel I misunderstand you. From your description, I imagine a world were
 text editors don't bother to ask users for an encoding but simply always use
 platform default encoding. In such a world, I wonder how people would
 collaboratively work on the same sources.


the context of this statement is within a standalone system, I think this is
exactly what the notepad.exe does, notepad surely works, in its place.

so the application developer don't need to worry about converting
  back-n-forth between several encodings/charsets,


ditto


Considering the internet and its wonderful aspect of bringing people all
 over the world together, I really believe it is time that application
 developers *do* worry about encoding and converting file contents to pull
 down the walls that our different locales or OS impose.

 Imagine two open-source projects, one using UTF-8 and the other Big5. How
 would people participate on these projects (using the same machine) if we
 expected applications to always stick to one system-wide encoding setting?


by explicitly setting the source file  encoding in  each project's own
pom.xml,  as UTF-8 and Big5, respectively.
surely this will be a problem for you if you don't explicitly specify the
encoding
and please note with option [b] there'll be no answer if you still insist
not to explicitly set encoding.
by the way you're actually telling me that the two projects both have
explicit encoding,
this is not the case of the VOTE which discuss project without explicit
encoding.

IMO, e.g.,  networking related applications, have to deal with encoding,
  this is by nature, since network is used to connect
  people from different places.
 

 Let's remember that Maven is just sitting next to a networking related
 application, i.e. source control management.


That why I suggest explicit encoding in pom.xml,
Regarding SVN/CVS, I think the repository should have of strong type in case
of encoding, whether explicit or implicit.
e.g. if the SVN repository is using UTF-8, then it's strange if the file
checked out is in another one
about this I don't know much of SVN/CVS, this is an interesting topic I'd
like to know more.

Nice to discuss here
Roger

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Heinrich Nirschl

  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 imagine
cases where the encoding problem is just in a string. Chances are
high, that such a bug will go undetected for a long time.

Henry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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

Re: [POLL] Default Value for File Encoding


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 versions by the 
way. No guessing, no implicit default values, just full control, let's call 
it heaven ;-)


But how to get their? The threat I see with continuing to use the platform 
default encoding is that people will be left unaware of the encoding issue 
because platform default encoding works just nicely most of time.


Or just a warning for not to expect whole world is just using your 
preferred encoding?


Yes, a nice warning is surely due if a) wins.


Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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 applies to locking down plugin versions by
 the way. No guessing, no implicit default values, just full control,
 let's call it heaven ;-)
 
 But how to get their? The threat I see with continuing to use the
 platform default encoding is that people will be left unaware of the
 encoding issue because platform default encoding works just nicely most
 of time.

I'm still not convinced that we will get their by trading one problematic 
default for another.
As stated already, one way is creating and improving awareness, e.g. by 
flagging any problematic access to a file or better stop
working (for new projects) if encoding is not stated explicitly.

Sigh, I'm a bit idealistic, I know


 
 Or just a warning for not to expect whole world is just using your
 preferred encoding?
 
 Yes, a nice warning is surely due if a) wins.
 
 
 Benjamin
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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 culture. Might be one reason why I quickly had
 locked down all encoding settings in our corporate POM...


I love Linux, in which I can globally set UTF-8 as my default encoding
I hate Windows, in which I cannot do that, then for me only GB2312 is the
most appropriate.

maybe I'm not a Windows savvy, and I hope someone can tell how to do that :P

Roger

Re: [POLL] Default Value for File Encoding


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 
will implicitly use his platform default encoding during the build. Further 
assume that the platform default encoding among the project team differs 
(for whatever reason). This potentially causes the build output for 
developer A and developer B to differ although they are

- building from the same POM
- using the same Maven version
- using the same plugin versions

In contrast, if the unspecified file encoding defaulted to a 
platform-independent value defined by a Maven convention, the build will

a) either work for both developers or
b) work for none of them
in both cases, they observe the same build output.

I mean, the major aspect of the Maven default encoding being Latin-1 instead 
of UTF-8 or whatever people's platfrom encoding is, is that this value is 
platform-independent and as such applies to the entire team (unless their 
override it).



Most likely the files are not compatible with the new implied default.


Yes, but you would simply need to fix your POM and are back on the road.

Thus flagging encoding problems will improve awareness and will surely 
contribute more to consistent builds that changing the rules on the 
game...


If we change the rules such that the build of those people, that are 
currently unaware of the encoding issue and simply assume their platform 
encoding, can break, that's some kind (though not fully reliable) of 
flagging encoding problems, IMHO. Yes, yes, that might not be the most 
polite way of promoting things, but sometimes I feel a little emphasis is 
OK.



Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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] Environment.clinit(500) | Hibernate 3.2.0.cr5
[myproject] INFO [main] Environment.clinit(533) | hibernate.properties not
found
[myproject] INFO [main] Environment.buildBytecodeProvider(667) | Bytecode
provider name : cglib
[myproject] INFO [main] Environment.clinit(584) | using JDK 1.4
java.sql.Timestamp handling
[myproject] DEBUG [main] Ejb3Configuration.configure(194) | Look up for
persistence unit: ejb3test
[myproject] DEBUG [main] Ejb3Configuration.configure(206) | Analyse of
persistence.xml: file:/C:/opt/temp/appfuse/myproject/core/target/classes/M
ETA-INF/persistence.xml
[myproject] DEBUG [main] DTDEntityResolver.resolveEntity(38) | trying to
resolve system-id [http://java.sun.com/xml/ns/persistence/persistence_1_
0.xsd]
[myproject] DEBUG [main] EJB3DTDEntityResolver.resolveEntity(49) |
recognized EJB3 ORM namespace; attempting to resolve on classpath under
org/hi
bernate/ejb
[myproject] DEBUG [main] EJB3DTDEntityResolver.resolveEntity(58) | located [
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd] in classp
ath
[myproject] DEBUG [main] PersistenceXmlLoader.parsePersistenceUnit(115) |
Persistent Unit name from persistence.xml: ApplicationEntityManager
[myproject] DEBUG [main] Ejb3Configuration.configure(213) |
PersistenceMetadata [
name: ApplicationEntityManager
jtaDataSource: null
nonJtaDataSource: null
transactionType: RESOURCE_LOCAL
provider: org.hibernate.ejb.HibernatePersistence
classes[
com.baselogic.domain.VersionedObject
com.baselogic.domain.IdentifiedObject   com.baselogic.domain.User
com.baselogic.domain.Role   com.baselogic.domain.Address]
packages[
]
mappingFiles[
]
jarFiles[
]
hbmfiles: 0
properties[
hibernate.hbm2ddl.auto: create
]]
[myproject] DEBUG [main] Ejb3Configuration.getDetectedArtifacts(522) |
Detect class: true; detect hbm: true
[myproject] DEBUG [main] JarVisitor.unqualify(192) | Searching mapped
entities in jar/par: file:/C:/opt/temp/appfuse/myproject/core/target/classe
s
[ERROR] Persistence unit not found: 'ejb3test'.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Couldn't create Configuration object
[INFO]

[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't create
Configuration object
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't create
Configuration object
at
org.codehaus.mojo.hibernate3.configuration.AbstractComponentConfiguration.getConfiguration(AbstractComponentConfiguration.java:38)
at
org.codehaus.mojo.hibernate3.exporter.Hbm2DDLExporterMojo.doExecute(Hbm2DDLExporterMojo.java:87)
at
org.codehaus.mojo.hibernate3.HibernateExporterMojo.execute(HibernateExporterMojo.java:140)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Manos Batsis


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 arguments here. Proper text editors allow you to
select the file encoding you save your files in, so the system default
encoding should not matter.



no offense, but this is your problem  for not being able to follow Manos's
arguments here,



I hate this! Someone finally agrees with me but in a misquoted email; I 
never wrote that :-)



Sorry, i voted for b + warnings for plugins that have no clue, also made 
a rough proposal on how this could work.


Cheers,

Manos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: scm:checkout question

2008-04-29 Thread Daniel King

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 
8) Deleting the client spec

See below:

[INFO] Removing C:\workspace2\unitedProject\build
[INFO] Checkout working directory: C:\workspace2\unitedProject\build
[INFO] Executing: p4 -d C:\workspace2\unitedProject\build -p
perforce:1555 -u devuser -P ** client -i
[INFO] Executing: p4 -d C:\workspace2\unitedProject\build -p perforce:
1555 -u devuser -P ** client -d
devuser-F6NYG61-D-MavenSCM-C:\workspace2\unitedProject\build
[INFO] Removing C:\workspace2\unitedProject\build
[INFO] Checkout working directory: C:\workspace2\unitedProject\build
[INFO] Executing: p4 -d C:\workspace2\unitedProject\build -p perforce:
1555 -u devuser -P ** client -i
[INFO] Executing: p4 -d C:\workspace2\unitedProject\build -p perforce:
1555 -u devuser -P ** client -d
devuser-F443G61-D-MavenSCM-C:\workspace2\unitedProject\build
[INFO] Scanning for projects...
[INFO]


[INFO] Building Maven Default Project
[INFO]task-segment: [deploy]

Daniel King
Vurv


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 2.0.9 Super POM locking down some plugin
versions.


As stated already, one way is creating and improving awareness, e.g. by
flagging any problematic access to a file or better stop working (for
new projects) if encoding is not stated explicitly.


Once it's time to discuss the POM 4.1, we can surely come back to this and
consider if the encoding setting should have a default value of simply be
required by the user.

Alternatively, we could right now for Maven 2.0.x make plugins declare their
encoding parameter to be @required. This will definitively halt the build in
case the user did not specify an encoding. With regard to awareness, that
would surely be the cleanest solution. Is that were you would Maven see to 
go?



Sigh, I'm a bit idealistic, I know


Never mind, if you can accept me being a little of a radical ;-)


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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
persistence provider classname:
org.hibernate.ejb.HibernatePersistence
classloader: [EMAIL PROTECTED]
Temporary classloader:
[EMAIL PROTECTED]
excludeUnlistedClasses: false
JTA datasource: null
Non JTA datasource: com.mchange.v2.c3p0.ComboPooledDataSource [
acquireIncrement - 1, acquireRetryAttempts - 0, acquireRetryDelay - 10
00, autoCommitOnClose - false, automaticTestTable - null,
breakAfterAcquireFailure - false, checkoutTimeout - 0,
connectionCustomizerClassNam
e - null, connectionTesterClassName -
com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -
2xu9es7t1731bsy1czqhpw|1700391, debug
UnreturnedConnectionStackTraces - false, description - null, driverClass
- org.hsqldb.jdbcDriver, factoryClassLocation - null, forceIgnoreUnr
esolvedTransactions - false, identityToken -
2xu9es7t1731bsy1czqhpw|1700391, idleConnectionTestPeriod - 0,
initialPoolSize - 0, jdbcUrl - jd
bc:hsqldb:file:target/testdb-hsql;shutdown=true, maxAdministrativeTaskTime
- 0, maxConnectionAge - 0, maxIdleTime - 0, maxIdleTimeExcessConnec
tions - 0, maxPoolSize - 2, maxStatements - 0, maxStatementsPerConnection
- 0, minPoolSize - 1, numHelperThreads - 3, numThreadsAwaitingChe
ckoutDefaultUser - 0, preferredTestQuery - null, properties -
{user=**, password=**}, propertyCycle - 0, testConnectionOnCheckin
- f
alse, testConnectionOnCheckout - false, unreturnedConnectionTimeout - 0,
usesTraditionalReflectiveProxies - false ]
Transaction type: RESOURCE_LOCAL
PU root URL:
file:/C:/opt/temp/appfuse/myproject/core/target/classes/
Jar files URLs []
Managed classes names [
com.baselogic.domain.VersionedObject
com.baselogic.domain.IdentifiedObject
com.baselogic.domain.User
com.baselogic.domain.Role
com.baselogic.domain.Address]
Mapping files names []
Properties [
hibernate.hbm2ddl.auto: create]
*

*Then there is this error:*

*[myproject] INFO [main] SchemaExport.importScript(238) | Executing import
script: /import.sql
[myproject] DEBUG [main] SchemaExport.importScript(253) | INSERT INTO
`address` VALUES ('-1', '1', '725 Florida Street #5', 'San Francisco', 'US'
, '94110', 'CA')
[myproject] ERROR [main] SchemaExport.execute(202) | schema export
unsuccessful
org.hibernate.JDBCException: Error during import script execution
at
org.hibernate.tool.hbm2ddl.SchemaExport.importScript(SchemaExport.java:258)
at
org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:192)
at
org.hibernate.tool.hbm2ddl.SchemaExport.create(SchemaExport.java:133)
at
org.hibernate.impl.SessionFactoryImpl.init(SessionFactoryImpl.java:311)
at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
at
org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915)
at
org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:730)
at
org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactory
Bean.java:227)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:281)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java
:1333)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:12
99)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:463)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:404)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:375)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:263)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:170)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:260)
at

Re: [m2] can't get hibernate plugin to work with hsql

It looks like its missing the entity-manager dependency, do you have it
specified in your pom?

Regards

Johann Reyes

Re: [m2] can't get hibernate plugin to work with hsql

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 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
 persistence provider classname:
 org.hibernate.ejb.HibernatePersistence
 classloader: [EMAIL PROTECTED]
 Temporary classloader:
 [EMAIL PROTECTED]
 excludeUnlistedClasses: false
 JTA datasource: null
 Non JTA datasource: com.mchange.v2.c3p0.ComboPooledDataSource [
 acquireIncrement - 1, acquireRetryAttempts - 0, acquireRetryDelay - 10
 00, autoCommitOnClose - false, automaticTestTable - null,
 breakAfterAcquireFailure - false, checkoutTimeout - 0,
 connectionCustomizerClassNam
 e - null, connectionTesterClassName -
 com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -
 2xu9es7t1731bsy1czqhpw|1700391, debug
 UnreturnedConnectionStackTraces - false, description - null, driverClass
 - org.hsqldb.jdbcDriver, factoryClassLocation - null, forceIgnoreUnr
 esolvedTransactions - false, identityToken -
 2xu9es7t1731bsy1czqhpw|1700391, idleConnectionTestPeriod - 0,
 initialPoolSize - 0, jdbcUrl - jd
 bc:hsqldb:file:target/testdb-hsql;shutdown=true, maxAdministrativeTaskTime
 - 0, maxConnectionAge - 0, maxIdleTime - 0, maxIdleTimeExcessConnec
 tions - 0, maxPoolSize - 2, maxStatements - 0,
 maxStatementsPerConnection - 0, minPoolSize - 1, numHelperThreads - 3,
 numThreadsAwaitingChe
 ckoutDefaultUser - 0, preferredTestQuery - null, properties -
 {user=**, password=**}, propertyCycle - 0, testConnectionOnCheckin
 - f
 alse, testConnectionOnCheckout - false, unreturnedConnectionTimeout - 0,
 usesTraditionalReflectiveProxies - false ]
 Transaction type: RESOURCE_LOCAL
 PU root URL:
 file:/C:/opt/temp/appfuse/myproject/core/target/classes/
 Jar files URLs []
 Managed classes names [
 com.baselogic.domain.VersionedObject
 com.baselogic.domain.IdentifiedObject
 com.baselogic.domain.User
 com.baselogic.domain.Role
 com.baselogic.domain.Address]
 Mapping files names []
 Properties [
 hibernate.hbm2ddl.auto: create]
 *

 *Then there is this error:*

 *[myproject] INFO [main] SchemaExport.importScript(238) | Executing import
 script: /import.sql
 [myproject] DEBUG [main] SchemaExport.importScript(253) | INSERT INTO
 `address` VALUES ('-1', '1', '725 Florida Street #5', 'San Francisco', 'US'
 , '94110', 'CA')
 [myproject] ERROR [main] SchemaExport.execute(202) | schema export
 unsuccessful
 org.hibernate.JDBCException: Error during import script execution
 at
 org.hibernate.tool.hbm2ddl.SchemaExport.importScript(SchemaExport.java:258)
 at
 org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:192)
 at
 org.hibernate.tool.hbm2ddl.SchemaExport.create(SchemaExport.java:133)
 at
 org.hibernate.impl.SessionFactoryImpl.init(SessionFactoryImpl.java:311)
 at
 org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
 at
 org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915)
 at
 org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:730)
 at
 org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
 at
 org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactory
 Bean.java:227)
 at
 org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:281)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java
 :1333)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:12
 99)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:463)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:404)
 at java.security.AccessController.doPrivileged(Native Method)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:375)
 at

Re: [POLL] Default Value for File Encoding


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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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 plugins in use, each
 developer will implicitly use his platform default encoding during the
 build. Further assume that the platform default encoding among the
 project team differs (for whatever reason). This potentially causes the
 build output for developer A and developer B to differ although they are
 - building from the same POM
 - using the same Maven version
 - using the same plugin versions

Yes I see your argument,
nevertheless there are large areas where a breaking build does not imply 
receiving some kind of error message.
I'd assume there are numerous cases where breaking just implies strange 
results somewhere in an application.
This will not get improved on changing default encoding, it will just happen to 
break in a different way.
So why not leave the bad situation as is and avoiding making it worse by adding 
the chance that some build will exhibit breaks while
still in uncritical environments. (Causing some improvents for the price of 
being unpolite as you did put it below)

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 and keeping current problems on current project settings.
Fixing some by default while breaking others (causing them to get fixed).

Same effect if *any* build is flagging bad usage of encoding (aka missing 
encoding declarations) and building up some pressure on
people providing projects publicly.

No changes for old ones -- consistent improvement for anything else

 
 In contrast, if the unspecified file encoding defaulted to a
 platform-independent value defined by a Maven convention, the build will
 a) either work for both developers or
 b) work for none of them
 in both cases, they observe the same build output.
 
 I mean, the major aspect of the Maven default encoding being Latin-1
 instead of UTF-8 or whatever people's platfrom encoding is, is that this
 value is platform-independent and as such applies to the entire team
 (unless their override it).
 
 Most likely the files are not compatible with the new implied default.
 
 Yes, but you would simply need to fix your POM and are back on the road.
 
 Thus flagging encoding problems will improve awareness and will surely
 contribute more to consistent builds that changing the rules on the
 game...
 
 If we change the rules such that the build of those people, that are
 currently unaware of the encoding issue and simply assume their platform
 encoding, can break, that's some kind (though not fully reliable) of
 flagging encoding problems, IMHO. Yes, yes, that might not be the most
 polite way of promoting things, but sometimes I feel a little emphasis
 is OK.
 
 
 Benjamin
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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
 Maven
 2.1, comparable to the Maven 2.0.9 Super POM locking down some plugin
 versions.
 
 As stated already, one way is creating and improving awareness, e.g. by
 flagging any problematic access to a file or better stop working (for
 new projects) if encoding is not stated explicitly.
 
 Once it's time to discuss the POM 4.1, we can surely come back to this and
 consider if the encoding setting should have a default value of simply be
 required by the user.
 
 Alternatively, we could right now for Maven 2.0.x make plugins declare
 their
 encoding parameter to be @required. This will definitively halt the
 build in
 case the user did not specify an encoding. With regard to awareness, that
 would surely be the cleanest solution. Is that were you would Maven see
 to go?

Yes, I do consider this a cleaner solution and causing much more positive 
effective than changing some defaults

 
 Sigh, I'm a bit idealistic, I know
 
 Never mind, if you can accept me being a little of a radical ;-)
 
Wellcome to the club...

 
 Benjamin
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem mit release:perform

2008-04-29 Thread mgehring


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 there is a coherence.:wistle:
But my environment variables say this:

JAVA_HOME=/usr/lib/jvm/java-6-sun
M2_HOME=/home/marcus/progs/apache-maven-2.0.9
M2=$M2_HOME/bin
PATH=$M2:$JAVA_HOME/bin:$PATH
M2_REPO=/home/marcus/.m2/repository

I have no Idea. :confused:


matinh wrote:
 
 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 
 string clean verify with quotes where no quotes would be allowed (or 
 similar). Search your pom.xml for the string clean verify to locate the 
 problem.
 
 hth,
 - martin
 
  
 

-- 
View this message in context: 
http://www.nabble.com/Problem-with-release%3Aperform-tp16923146s177p16966488.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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 Reyes

Re: [POLL] Default Value for File Encoding


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 to maven encoding in case there is a pom along
the path. so, it might work for IDEs where all aspects are tightly 
integrated..)


(Personally, I would not like to be forced to dump good ol' vi (;-))


Surely, text editors shouldn't be aware of a Maven POM somewhere hanging 
around with an encoding setting burried in it, nor should people drop their 
favorite editors. I simply expect the user to tell both Maven and its text 
editor what the desired encoding is. I mean, when you work on a Maven 
project and its sources, you would like to edit a file with the same 
encoding as your colleagues do, don't you? So it's not about syncing your 
editor to Maven but syncing Maven to the convention of your team.



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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 based on my experience with moving
across versions, I'd be very surprised if this was the only thing they
needed to change in their pom (very few people lock down plugin
versions, and new plugins sometimes require changes to the pom). If
they simply kept using the old Maven build they originally built their
project with, they wouldn't need to do this.

New projects using the new Maven builds will either use the default
that we are discussing (I voted for b) or declare their own default
with a single property in their pom.

Which of the above cases are you most concerned about??

Wayne

On 4/29/08, Rainer Pruy [EMAIL PROTECTED] wrote:


 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 builds for those projects.
 Most likely the files are not compatible with the new implied default.

 So the only intention can be ensuring consistent builds for any *future* 
 project (version).
 Thus flagging encoding problems will improve awareness and will surely 
 contribute more to consistent builds that changing the rules
 on the game...
 Rainer

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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 around with some
 logic to default to maven encoding in case there is a pom along
 the path. so, it might work for IDEs where all aspects are tightly
 integrated..)

 (Personally, I would not like to be forced to dump good ol' vi (;-))
 
 Surely, text editors shouldn't be aware of a Maven POM somewhere hanging
 around with an encoding setting burried in it, nor should people drop
 their favorite editors. I simply expect the user to tell both Maven and
 its text editor what the desired encoding is. I mean, when you work on a
 Maven project and its sources, you would like to edit a file with the
 same encoding as your colleagues do, don't you? So it's not about
 syncing your editor to Maven but syncing Maven to the convention of your
 team.

To be honest,
I use to run recode on check-out / check-in to ensure checked-in versions are 
consistent with standard and checked-out ones are
conforming to my local environment.
This way my editor is doing the right thing.

(And I save some brain work for figuring out what project is using what 
encoding as of now. Just an aside: my world is not maven-only,
and some projects won't change encoding just to get in sync with some tool)

Thus I'm still with force people stating encoding explicitly and don't twiddle 
around with default settings that won't solve the
problem in the first place.


 
 
 Benjamin
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 you just wait until somebody 
reports a problem with the build because his default encoding does not work?


the context of this statement is within a standalone system, I think this 
is

exactly what the notepad.exe does, notepad surely works, in its place.


But do we talk about a standalone system? I really feel there this is a 
little difference between Maven and Notepad... I mean Maven is quite a 
global player, building one or the other project over here and there, 
whereas Notepad, well, I don't know.



by the way you're actually telling me that the two projects both have
explicit encoding,


OK, then I didn't clearly express myself. With using UTF-8 I mean that the 
sources are indeed UTF-8 encoded, but not necessarily that this encoding is 
also declared in the POM.


Regarding SVN/CVS, I think the repository should have of strong type in 
case

of encoding, whether explicit or implicit.
e.g. if the SVN repository is using UTF-8, then it's strange if the file
checked out is in another one
about this I don't know much of SVN/CVS, this is an interesting topic I'd
like to know more.


To my knowledge, SVN is currently not aware of file encoding.


Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 is bound to a 
specific plugin version, so updating a source processing plugin (say from 
maven-compiler 2.0.1 to maven-compiler 2.1) would require to watchout for 
the encoding change. Projects that didn't lock down their plugins versions 
are naturally affected by this change just like with any other change to the 
used plugins.



New projects using the new Maven builds will either use the default
that we are discussing (I voted for b) or declare their own default
with a single property in their pom.


That's it. And if people need to have different encodings for different 
plugins, they still have the freedom to configure the plugins individually, 
too.



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding



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
 consider this maintenance and based on my experience with moving
 across versions, I'd be very surprised if this was the only thing they
 needed to change in their pom (very few people lock down plugin
 versions, and new plugins sometimes require changes to the pom). If
 they simply kept using the old Maven build they originally built their
 project with, they wouldn't need to do this.
 
 New projects using the new Maven builds will either use the default
 that we are discussing (I voted for b) or declare their own default
 with a single property in their pom.
 
 Which of the above cases are you most concerned about??
 

None - or both if you like.

I just feel there is no real argument for changing current default encoding 
assumption.

Case one (old projects using old maven versions) are not affected, yes.
Case two (old projects with new maven versions) might get a hint for something 
needs to be fixed if build actually happen to break.
But otherwise nothing will get improved. Thus we will need a different 
mechanism anyway.

Same for case three (new projects with new maven): If one happens to get into 
trouble all is fine.
Otherwise no incentive for fixing any problem related to encoding.

Thus, we need something more effective, but then why change encoding default in 
the first place.

For case two
 Wayne
 
 On 4/29/08, Rainer Pruy [EMAIL PROTECTED] wrote:

 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 builds for those projects.
 Most likely the files are not compatible with the new implied default.

 So the only intention can be ensuring consistent builds for any *future* 
 project (version).
 Thus flagging encoding problems will improve awareness and will surely 
 contribute more to consistent builds that changing the rules
 on the game...
 Rainer

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-- 
Rainer Pruy
Geschäftsführer

Acrys Consult GmbH  Co. KG
Untermainkai 29-30, D-60329 Frankfurt
Tel: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com -  Email: [EMAIL PROTECTED]
Handelsregister: Frankfurt am Main, HRA 31151

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding

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 ;-)

 But how to get their? The threat I see with continuing to use the platform
 default encoding is that people will be left unaware of the encoding issue
 because platform default encoding works just nicely most of time.


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, e.g. I'm from China, I've created
a Maven project, using the my default encoding GBK, and then shared it with
you, Benjamin, then how would you collaborate with me? surely you cannot
assume the encoding to be iso-8859-xx (your system default, excuse me if I'm
wrong)
Then there are two solutions IMO:
1). we set GBK as source file encoding in pom.xml
2). we don't change pom.xml, but we both use an imaginary-maven-fork which
treats every file as encoded in GBK, this does not be platform-dependent. as
option b)

will you agree with solution 2)? even if there're 99 developers from China
while only one of you from Germany :P

so, I insist option a), and if it's problematic without explicit encoding,
it means an explicit encoding is required in the POM.

and I also insist that it's important for developers to understand the root
cause of the inconsistent build result generated by developers from
different country / region.
such developers should understand Unicode, and different encodings, and how
the platform default encoding affects the build result.

Thanks
Roger

Or just a warning for not to expect whole world is just using your
  preferred encoding?
 
  Yes, a nice warning is surely due if a) wins.
 Benjamin

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread walid joseph Gedeon

+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 don't use latin-1 to set
it in the pom, even if they're all using the same default encoding.

Note: it would probably be a good idea to include the encoding used (whether
default or set) in the plugin report information.

W

On Tue, Apr 29, 2008 at 8:32 PM, Roger Ye [EMAIL PROTECTED] wrote:

 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 ;-)
 
  But how to get their? The threat I see with continuing to use the
 platform
  default encoding is that people will be left unaware of the encoding
 issue
  because platform default encoding works just nicely most of time.


 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, e.g. I'm from China, I've
 created
 a Maven project, using the my default encoding GBK, and then shared it
 with
 you, Benjamin, then how would you collaborate with me? surely you cannot
 assume the encoding to be iso-8859-xx (your system default, excuse me if
 I'm
 wrong)
 Then there are two solutions IMO:
 1). we set GBK as source file encoding in pom.xml
 2). we don't change pom.xml, but we both use an imaginary-maven-fork which
 treats every file as encoded in GBK, this does not be platform-dependent.
 as
 option b)

 will you agree with solution 2)? even if there're 99 developers from China
 while only one of you from Germany :P

 so, I insist option a), and if it's problematic without explicit encoding,
 it means an explicit encoding is required in the POM.

 and I also insist that it's important for developers to understand the
 root
 cause of the inconsistent build result generated by developers from
 different country / region.
 such developers should understand Unicode, and different encodings, and
 how
 the platform default encoding affects the build result.

 Thanks
 Roger

 Or just a warning for not to expect whole world is just using your
   preferred encoding?
  
   Yes, a nice warning is surely due if a) wins.
  Benjamin

Re: how to prevent default goal in a phase to run?

2008-04-29 Thread walid joseph Gedeon

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 package phase. How can i prevent it from running, or skip this
 goal?

 --
 Thanks,
 Zemian Deng

Re: how to remove maven specific files

2008-04-29 Thread walid joseph Gedeon

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
artifactIdmaven-jar-plugin/artifactId
 version2.2/version
 configuration
archive

 manifestFile${basedir}/../wsear/META-INF/MANIFEST.MF/manifestFile
 addMavenDescriptorfalse/addMavenDescriptor
/archive
/configuration
/plugin


 On Wed, Apr 23, 2008 at 3:34 PM, Stephen Connolly 
 [EMAIL PROTECTED] wrote:

  On Tue, Apr 22, 2008 at 11:29 PM, I am Who i am [EMAIL PROTECTED]
 wrote:
 
   Hi All,
  
   How to remove maven related files like maven folder / pom.xml /
   pom.properties files from the jar file being created, i have the
  following
   in my pom, but still seeing the maven directory with pom /
   .xml/.properties
   under META-INF directory, my jar plugin version is 2.2
   build
   plugins
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-jar-plugin/artifactId
  executions
  execution
  idCUSTOM-MANIFEST/id
  goals
  goaljar/goal
  /goals
  configuration
  archive
  
   manifestFile${basedir}/../wsear/META-INF/MANIFEST.MF/manifestFile
   addMavenDescriptorfalse/addMavenDescriptor
  /archive
  /configuration
  /execution
  /executions
  /plugin
 /plugins
 /build
  
  
   Please help
  
 
  What you have done is only removed the files from the execution you
  added...
  additionally you have not attached this execution to any phase... what
 you
  want to do is change the default configuration for the jar plugin in
 your
  pom.xml by doing
 
 
  build
 plugins
plugin
groupIdorg.apache.maven.plugins/groupId
 
  artifactIdmaven-jar-plugin/artifactId
  configuration
  archive
  
   manifestFile${basedir}/../wsear/META-INF/MANIFEST.MF/manifestFile
   addMavenDescriptorfalse/addMavenDescriptor
  /archive
  /configuration
  /plugin
 /plugins
 /build

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Hervé BOUTEMY

+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 choice: explicitely declare 
encoding in their pom.

Hervé

Le mardi 29 avril 2008, Benjamin Bentmann a écrit :
 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 specify this in the POM. This poll should
 help us to come to a well-founded decision.

 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
platform-dependent.

 Approach a) matches the current behavior of most plugins and is as such
 backwards-compatible. Approach b) on the other hand can potentially break
 builds when users update to a newer version of an affected plugin if:
 - the build relies on an encoding other than ASCII/Latin-1 and
 - this encoding is not explicitly stated in the plugin configuration

 The reason why b) was suggested is its positive effect on build
 reproducibility: Unlike approach a), a build will out-of-the-box deliver
 the same output for all team members regardless of their OS or locale. It
 is now to balance if this improvement is worth the potential breaks as
 illustrated above.

 So, please let us know:

 [a] Use platform default encoding, keep backward-compat
 [b] Use fixed default encoding, be platform-independent

 Regards,


 Benjamin Bentmann


 [0]
 http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Enco
ding


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] can't get hibernate plugin to work with hsql

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
scopecompile/scope
/dependency

dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
scopecompile/scope
/dependency

dependency
groupIdcommons-beanutils/groupId
artifactIdcommons-beanutils/artifactId
version1.8.0-BETA/version
scopecompile/scope
/dependency

dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version3.2/version
scopecompile/scope
/dependency

dependency
groupIdcommons-dbcp/groupId
artifactIdcommons-dbcp/artifactId
version1.2.2/version
/dependency

dependency
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
version1.0.1B/version
/dependency

dependency
groupIdorg.dbunit/groupId
artifactIddbunit/artifactId
version2.2.1/version
scopetest/scope
/dependency

dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.13/version
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-aspects/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-beans/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-context/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-core/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-jdbc/artifactId
version${spring.version}/version
scopeprovided/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-orm/artifactId
version${spring.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-support/artifactId
version2.0.8/version
scopeprovided/scope
/dependency

dependency
groupIdorg.springframework/groupId
artifactIdspring-test/artifactId
version${spring.version}/version
/dependency


!-- Tests fail w/ org.jboss.seam.embedded:hibernate-all:beta3.
Expand it instead --
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate/artifactId
version${hibernate.version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-entitymanager/artifactId
version${hibernate-entitymanager.version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-annotations/artifactId
version${hibernate-annotations.version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-commons-annotations/artifactId
version${hibernate-annotations.version}/version
scopecompile/scope
/dependency

dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-tools/artifactId
version3.2.0.beta9a/version
/dependency

dependency
groupIdc3p0/groupId
artifactIdc3p0/artifactId
version0.9.1.2/version
/dependency

/dependencies


On Tue, Apr 29, 2008 at 11:04 AM, Johann Reyes [EMAIL PROTECTED]
wrote:

 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:

Re: [POLL] Default Value for File Encoding

2008-04-29 Thread Jesse McConnell

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 unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 if this awareness of encoding differences was in
everybody's head. If you like, grab yourself a POM of a Maven
component/plugin, run mvn help:effective-pom on it and search for
encoding...

I mean, unless something breaks, people tend to just be happy with the
status quo. Also, not everybody cares about warnings (Not an error and
works for me, so why bother?).


e.g. I'm from China, I've created
a Maven project, using the my default encoding GBK, and then shared it
with
you, Benjamin, then how would you collaborate with me?


I usually follow the conventions setup by the project owner/leader, so
naturally I tell my IDE (but only my IDE, not my entire OS) to user GBK for
our imaginary joint venture and are fine with editing the sources. The
remaining question is how will my build output look like.


surely you cannot assume the encoding to be iso-8859-xx (your system
default, excuse me if I'm wrong)


Just in case to be clear: Latin-1 was not chosen as the proposed default
value because it happens to be similar with my encoding. It was merely
proposed as a matter of consistency with another plugin that already had
this default value.


Then there are two solutions IMO:
1). we set GBK as source file encoding in pom.xml
2). we don't change pom.xml, but we both use an imaginary-maven-fork which
treats every file as encoded in GBK, this does not be platform-dependent.
as
option b)

will you agree with solution 2)? even if there're 99 developers from China
while only one of you from Germany :P


I'm not sure whether I got your point with solution 2) right: Of course we
shouldn't use some maven-fork, there should only be one Maven. So in either
way, the solution to go for your sketched project is 1), i.e. specify the
encoding GBK in the POM. Otherwise, if we leave the encoding unspecified I
would produce garbage output on my Western machine when building the GBK
encoded sources. The point with the option b) would have just been that
already the Chinese developers would have noticed the requirement to specify
the encoding in the POM, preventing build failures for people outside of
China. Wrong build output is quite a severe illness and should be fixed even
if only a minority of developers experience it.


so, I insist option a)


We have also five more votes for a) over on the wiki, so it seems you need
not worry too much for this coming through ;-)


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven pde rcp to build

2008-04-29 Thread Barrie Treloar

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 you can get it
built via ant you should also be able to get it built via maven.
Are there examples on how to build PDE project via ant with 3.3 on the
eclipse site?

If you are still having trouble, try the pde mailing list or newsgroup.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding


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 works for a
majority, i.e. convention over configuration only works if one has a
reasonable convention. However, Latin-1 is admittedly not international
enough to serve this, UTF-8 might have been (but again, if third of the
world uses Big5, GBK etc. that's questionable, too).

Requiring an explicit encoding in all cases would have been the most
consequent approach because it would have broken for everybody and as such
would have taught everybody to specify the encoding. It would have hurt once
but then never again.

Maybe in the next century.


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [POLL] Default Value for File Encoding