Re: svn commit: r645833 - in /archiva/trunk: archiva-jetty/src/main/conf/jetty.xml archiva-modules/archiva-web/archiva-rss/src/main/java/org/apache/archiva/rss/processor/NewArtifactsRssFeedProcessor.j
On Wed, Apr 9, 2008 at 11:07 AM, Brett Porter [EMAIL PROTECTED] wrote: this sounds like a good optimisation, does it also take into account additions via upload (which triggers the consumers, just not the full scan)? It just relies on the full scan. Hmm, I wasn't aware that artifact uploads also triggers the consumers.. I'll take a look into this. Is it persisted to disk so it is still correct after a restart? Yep, it's being written into the disk with different filenames and is updated everytime new artifacts are discovered in the repo. Now that you've mentioned this, I think I should also put a check or limit as to how many entries in the feeds should be kept so as to prevent the size of the files from bloating. I wonder if instead of generating the full RSS, just the information about what is to be included could be stored/cached and then the RSS is generated on a request for it only so we can populate the host/port from the servlet context? Hmm, by 'request' do you mean when a user clicks the rss feed icon to subscribe to a feed? If it is, my only concern here is for the new feed entries. Since a user only subscribes to a feed once, if we have new feed entries (e.g. new artifacts discovered after another repo scan) then the rss would only be generated or updated if another user subscribes to the feed :-) - Brett On 09/04/2008, at 12:00 PM, Maria Odea Ching wrote: Unfortunately, not all the time.. The generation and update of the feeds are triggered after a repository scan, which can be scheduled or explicitly executed. I could get the servlet context when the scan is explicitly executed, but I don't think i can get it when it's executed by the task executor. -Deng On Tue, Apr 8, 2008 at 8:06 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi Deng, Is there any access to the servlet context to obtain this instead? - Brett Thanks, Deng
Re: svn commit: r645833 - in /archiva/trunk: archiva-jetty/src/main/conf/jetty.xml archiva-modules/archiva-web/archiva-rss/src/main/java/org/apache/archiva/rss/processor/NewArtifactsRssFeedProcessor.j
On 09/04/2008, at 4:10 PM, Maria Odea Ching wrote: Is it persisted to disk so it is still correct after a restart? Yep, it's being written into the disk with different filenames and is updated everytime new artifacts are discovered in the repo. Now that you've mentioned this, I think I should also put a check or limit as to how many entries in the feeds should be kept so as to prevent the size of the files from bloating. yep, I agree - and the size should be kept small so that it's quick to download. You also need to make sure that the when the client requests the RSS, it gets the right headers to not try and update it if it hasn't changed for performance. Hmm, by 'request' do you mean when a user clicks the rss feed icon to subscribe to a feed? If it is, my only concern here is for the new feed entries. Since a user only subscribes to a feed once, if we have new feed entries (e.g. new artifacts discovered after another repo scan) then the rss would only be generated or updated if another user subscribes to the feed :-) I don't think anything happens when they subscribe to the feed - the same request is made every time the feed reader checks for an update. The URLs given inside the feed do need to remain consistent, so passing them through the request for the RSS makes the most sense. How is the RSS accessed at the moment? I haven't checked the code -is there a ww action for it, or is it served as the flat file? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [plexus work] archiva-checksums
Not sure I understand what you are asking. :-( There was a suggestion in the #archiva irc channel that we should offer the code in archiva-checksum to the commons-codec project. An idea I fully support, but have no idea how to proceed with. ;-) Also, Brett asked a passing question about how well archiva-checksum handles streaming. I'd like to get some more information on expectations, then I can put together a few test cases to ensure that functionality. - Joakim James William Dumay wrote: Joakim, Is this based on any work from commons or have you implemented this stuff from whats provided in the JDK? James On Tue, 2008-04-08 at 21:54 -0700, Joakim Erdfelt wrote: Joakim Erdfelt wrote: I've been taking a stab and removing some of our dependencies on various plexus components. First up, plexus-digest. I've taken the varied code from many locations and come up with a stand alone archiva-checksum lib/component that I hope to be able to integrate into archiva/trunk. So ... uhm ... consider this a call for discussion. ;-) - Joakim Some more details... These are 4 classes present in archiva-checksum 1) org/apache/archiva/checksum/Hash.java 2) org/apache/archiva/checksum/Hasher.java 3) org/apache/archiva/checksum/Hex.java 4) org/apache/archiva/checksum/ChecksumFile.java This is how the replacements work ... Hash.class is an enum identifying the types of Hash functions (currently only SHA1 and MD5), with a few details on ids that the hash techniques expose. This is similar in scope, but not a 100% replacement for ... org/codehaus/plexus/digest/Sha1Digester.java org/codehaus/plexus/digest/Md5Digester.java org/codehaus/plexus/digest/StreamingSha1Digester.java Hasher.class is the main hashing routines, stream based, and has a few optimizations for performing bulk or group hashing based on a single stream, without processing the stream multiple times (one for each hash). Hasher.class replaces the following classes in plexus-digest org/codehaus/plexus/digest/Digester.java org/codehaus/plexus/digest/StreamingDigester.java Hex.class is just a simple utility class to convert a byte array to a Hex string. It is a suitable replacement for plexus-digest org/codehaus/plexus/digest/Hex.java ChecksumFile.class is the file specific implementation, for dealing with the .md5 and .sha1 files (parsing, validating, creating, etc..) It is a replacement for plexus-digest org/codehaus/plexus/digest/ChecksumFile.java org/codehaus/plexus/digest/DigestUtils.java And also covers the logic present in archiva-common too org/apache/maven/archiva/common/utils/Checksums.java - Joakim
Re: plugin versions in super POM and future releases
-1. if I recall the discussion about plugin versions in super pom correctly, the solution was accepted not as a way to have 100% reprodicible build, but have reproducible builds with one version of maven for a duration longer than a few weeks (exagerating here a bit). So it's basically just a way to improve the first impression for new users and reduce the learning cur[vs]e.The correct bullet-proof solution remains to have the versions declared in your pom I think. Milos On Wed, Apr 9, 2008 at 7:43 AM, nicolas de loof [EMAIL PROTECTED] wrote: Putting (core) plugin versions in the super POM is not a full fix for projects to be reproductible. Users can still use other non-core plugins without a version set. Based on this, I'm +0 to let the superPOM plugins as is as I'd prefer a rule to have NO plugin with version unset. Could we move the pluginVersion enforcer rule to the maven core as a 2.0.10 / 2.1 feature ? 2008/4/9, Brett Porter [EMAIL PROTECTED]: Hi, I was wondering if anyone had opinions about what happens in 2.0.10, 2.1, etc with the versions of plugins that are now specified in the super POM. My gut feeling is that we should not upgrade these without a change to the modelVersion - the POM should be the sole reference for build behaviour and while I accept that changing the version of Maven can bring some behavioural differences this would be the most significant. On the other hand, we wouldn't want to perpetuate forever bugs that might be in the plugins (especially those that are a bit newer and labelled alpha/beta). I think our default stance from here on should be to make no modifications to the super POM without bumping the modelVersion, but reserve the right to make exceptions if the case arises. How do others feel about this? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: [VOTE] Maven 2.0.9
On 08/04/2008, Brian E. Fox [EMAIL PROTECTED] wrote:
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
+1 (non-binding)
successfully built Apache Felix and various local projects using it
--
Cheers, Stuart
Release is staged at:
http://people.apache.org/~brianf/stage-2.0.9
Binaries are here:
http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/
List of issues fixed:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
* [MNG-3316] - Barfs at attribues named .*encoding
* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
* [MNG-3394] - Plugin versions inherited via pluginManagement
cannot be overriden by build.plugins section of sub modules
* [MNG-3396] - Managed versions dont affect over constrained ranges
* [MNG-3400] - MavenProject is not extensible
* [MNG-3405] - Checking for updates from repository logging should
not display if WagonManager is offline
* [MNG-3410] - Managed versions in plugins are not considered when
using them
* [MNG-3415] - Transfer errors cause junk metadata in the local repo
* [MNG-3426] - regression : dependency in plugin configuration
doesn't override plugin classpath
* [MNG-3430] - Toolchain doesn't match Toolchain extensions
* [MNG-3431] - Pom Extensions not supported for Toolchains
* [MNG-3439] - incorrect child dependency selected when parent is
not selected
* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository
* [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo
* [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly
* [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken
* [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells
* [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions
* [MNG-3494] - local pom dependencies should get injected before
inherited dependencies
* [MNG-3495] - NPE at
org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24
1)
** Improvement
* [MNG-428] - Japanese message resource
* [MNG-2881] - Improve logging when downloading snapshots in offline
mode
* [MNG-3279] - Support Exception Chaining for MojoFailureException
* [MNG-3318] - ActiveProjectArtifact should have appropriate equals
and hashCode methods
* [MNG-3331] -
Re: [VOTE] Maven 2.0.9
On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commit r495157 - use of system properties
Hi Brett, 2008/4/8, Brett Porter [EMAIL PROTECTED]: Hi Vincent, I was reviewing the commits for 2.0.9 and saw this one: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles/activation/FileProfileActivator.java?r1=495147r2=609976diff_format=h Doesn't this need to be able to use the execution properties instead? Since WDYM by execution properties? this isn't present in the activator, I'm wondering if the value needs to be interpolated before the profile activators get it. In the DefaultProfileManager? Cheers, Vincent (not a blocker for 2.0.9, but it is present there and on trunk) Thanks, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: [VOTE] Maven 2.0.9
Just to let you know, I made more tests I noticed two problems : - I have several javadocs errors I hadn't before with 2.0.7 on our continuous integration server. Those errors are related to the jdk : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4923163 I don't understand why I didn't have them with 2.0.7. - I have an infinite loop with the sonar plugin : 09-Apr-2008 03:23:10[ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare 09-Apr-2008 03:23:10java.lang.StackOverflowError 09-Apr-2008 03:23:10at java.security.AccessController.doPrivileged(Native Method) 09-Apr-2008 03:23:10at java.net.URLClassLoader.findResource(URLClassLoader.java:359) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232) 09-Apr-2008 03:23:10at java.lang.ClassLoader.getResource(ClassLoader.java:977) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) Those problems are minor for me. I'll try to have a fix for them later. cheers Arnaud On Wed, Apr 9, 2008 at 9:27 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven repository mirror
Hi, We are thinking about setting up an internal maven 2 repository mirror here at the European Commission. How much space is currently required for the central repository? The maven website mentions 16GB and growing. Can we just rsync every couple of hours using one of the following commands or do we need te follow a procedure? We don't want to be blacklisted and kicked off. rsync -v -t -l -r mirrors.ibiblio.org::maven2 /your/local/path rsync -v -t -l -r rsync://rsync.cica.es/maven2 /your/local/path Are these locations still the primary locations to rsync? Kind regards, Geert Van Bastelaere Geert Van Bastelaere European Commission - DIGIT.A.3.001 B-28 03/151, Belliardstraat 28, 1040 Brussel phone: +32-(0)2-29.57102 mailto:[EMAIL PROTECTED]
RE: Maven repository mirror
As far as I know, the recommended method is not to rsync, as you don't need a full copy. Try running a maven proxy, like Archiva, Nexus or Artifactory, which work like a mirroring proxy. When they don't have a requested artifact, they will collect it from central or any other repository you set up and will keep it in their local repository. These also can work as a inhouse repository, to deploy your own artifacts to. With regards, Nick Stolwijk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wed 4/9/2008 14:00 To: dev@maven.apache.org Subject: Maven repository mirror Hi, We are thinking about setting up an internal maven 2 repository mirror here at the European Commission. How much space is currently required for the central repository? The maven website mentions 16GB and growing. Can we just rsync every couple of hours using one of the following commands or do we need te follow a procedure? We don't want to be blacklisted and kicked off. rsync -v -t -l -r mirrors.ibiblio.org::maven2 /your/local/path rsync -v -t -l -r rsync://rsync.cica.es/maven2 /your/local/path Are these locations still the primary locations to rsync? Kind regards, Geert Van Bastelaere Geert Van Bastelaere European Commission - DIGIT.A.3.001 B-28 03/151, Belliardstraat 28, 1040 Brussel phone: +32-(0)2-29.57102 mailto:[EMAIL PROTECTED]
Re: Stack overflow in 2.0.9 was: [VOTE] Maven 2.0.9
What version of the javadoc plugin? The only thing I can think it'd be related to is the change to the lifecycle forking. - Brett On 09/04/2008, at 10:09 PM, Arnaud HERITIER wrote: Just to let you know, I made more tests I noticed two problems : - I have several javadocs errors I hadn't before with 2.0.7 on our continuous integration server. Those errors are related to the jdk : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4923163 I don't understand why I didn't have them with 2.0.7. - I have an infinite loop with the sonar plugin : 09-Apr-2008 03:23:10[ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare 09-Apr-2008 03:23:10java.lang.StackOverflowError 09-Apr-2008 03:23:10at java.security.AccessController.doPrivileged(Native Method) 09-Apr-2008 03:23:10at java.net.URLClassLoader.findResource(URLClassLoader.java:359) 09-Apr-2008 03:23:10at org .codehaus .classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232) 09-Apr-2008 03:23:10at java.lang.ClassLoader.getResource(ClassLoader.java:977) 09-Apr-2008 03:23:10at org .codehaus .classworlds .RealmClassLoader.getResourceDirect(RealmClassLoader.java:247) 09-Apr-2008 03:23:10at org .codehaus .classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300) 09-Apr-2008 03:23:10at org .codehaus .classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org .codehaus .classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org .codehaus .classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) 09-Apr-2008 03:23:10at org .codehaus .classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org .codehaus .classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org .codehaus .classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) Those problems are minor for me. I'll try to have a fix for them later. cheers Arnaud On Wed, Apr 9, 2008 at 9:27 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commit r495157 - use of system properties
On 09/04/2008, at 9:49 PM, Vincent Siveton wrote: Hi Brett, 2008/4/8, Brett Porter [EMAIL PROTECTED]: Hi Vincent, I was reviewing the commits for 2.0.9 and saw this one: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles/activation/FileProfileActivator.java?r1=495147r2=609976diff_format=h Doesn't this need to be able to use the execution properties instead? Since WDYM by execution properties? The env and sysprops are passed in from the CLI via a properties object in the session now, I think. This is particularly emphasised on trunk, but I think it's also available on the branch. this isn't present in the activator, I'm wondering if the value needs to be interpolated before the profile activators get it. In the DefaultProfileManager? That's what I was thinking... - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: plugin versions in super POM and future releases
I previously put forth a set of guidelines when we voted on doing this initially. Essentially we would update the plugins only to non alpha or beta versions and versions of plugins that had been released longer than a month unless there was a good reason to do otherwise. I don't see any benefit in forever locking the plugins to where they are now. For the plugins that were locked at alphas/betas (like assembly), these should be upgraded with caution until it reaches a full release version and then the usual rules apply. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 11:54 PM To: Maven Developers List Subject: plugin versions in super POM and future releases Hi, I was wondering if anyone had opinions about what happens in 2.0.10, 2.1, etc with the versions of plugins that are now specified in the super POM. My gut feeling is that we should not upgrade these without a change to the modelVersion - the POM should be the sole reference for build behaviour and while I accept that changing the version of Maven can bring some behavioural differences this would be the most significant. On the other hand, we wouldn't want to perpetuate forever bugs that might be in the plugins (especially those that are a bit newer and labelled alpha/beta). I think our default stance from here on should be to make no modifications to the super POM without bumping the modelVersion, but reserve the right to make exceptions if the case arises. How do others feel about this? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: [VOTE] Maven 2.0.9
Did you check if these occur in 2.0.8? -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 8:09 AM To: Maven Developers List Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] Maven 2.0.9 Just to let you know, I made more tests I noticed two problems : - I have several javadocs errors I hadn't before with 2.0.7 on our continuous integration server. Those errors are related to the jdk : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4923163 I don't understand why I didn't have them with 2.0.7. - I have an infinite loop with the sonar plugin : 09-Apr-2008 03:23:10[ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare 09-Apr-2008 03:23:10java.lang.StackOverflowError 09-Apr-2008 03:23:10at java.security.AccessController.doPrivileged(Native Method) 09-Apr-2008 03:23:10at java.net.URLClassLoader.findResource(URLClassLoader.java:359) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader. java:232) 09-Apr-2008 03:23:10at java.lang.ClassLoader.getResource(ClassLoader.java:977) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLo ader.java:247) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:300) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.j ava:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:314) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.j ava:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:314) Those problems are minor for me. I'll try to have a fix for them later. cheers Arnaud On Wed, Apr 9, 2008 at 9:27 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - 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: plugin versions in super POM and future releases
So just to clarify (with pretend numbers), would this sort of scenario be fair: maven-2.0.9 includes: maven-install-plugin-1.9, maven-test-plugin-2.2 maven-compile-plugin-2.7 but maven-2.0.10 includes: maven-install-plugin-1.9, maven-test-plugin-2.3 maven-compile-plugin-2.8 So then would any two executions of 2.0.9 in its default configuration would always use 1.9 of install and 2.2 of test, etc.? And would it be fair to say that plugin versions might change between maven releases (2.0.x-2.0.x+1 or 2.x-2.x+1), but would not bump until the next maven version? If that logic is true, then I consider the problem mostly solved, and am exceedingly excited about it. Christian. On 9-Apr-08, at 08:55 , Brian E. Fox wrote: I previously put forth a set of guidelines when we voted on doing this initially. Essentially we would update the plugins only to non alpha or beta versions and versions of plugins that had been released longer than a month unless there was a good reason to do otherwise. I don't see any benefit in forever locking the plugins to where they are now. For the plugins that were locked at alphas/betas (like assembly), these should be upgraded with caution until it reaches a full release version and then the usual rules apply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Maven 2.0.9
Yes, I tried several weeks ago and I didn't have them. Arnaud On Wed, Apr 9, 2008 at 2:56 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Did you check if these occur in 2.0.8? -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 8:09 AM To: Maven Developers List Cc: [EMAIL PROTECTED] Subject: Re: [VOTE] Maven 2.0.9 Just to let you know, I made more tests I noticed two problems : - I have several javadocs errors I hadn't before with 2.0.7 on our continuous integration server. Those errors are related to the jdk : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4923163 I don't understand why I didn't have them with 2.0.7. - I have an infinite loop with the sonar plugin : 09-Apr-2008 03:23:10[ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare 09-Apr-2008 03:23:10java.lang.StackOverflowError 09-Apr-2008 03:23:10at java.security.AccessController.doPrivileged(Native Method) 09-Apr-2008 03:23:10at java.net.URLClassLoader.findResource(URLClassLoader.java:359) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader. java:232) 09-Apr-2008 03:23:10at java.lang.ClassLoader.getResource(ClassLoader.java:977) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLo ader.java:247) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:300) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.j ava:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:314) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.j ava:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm .java:314) Those problems are minor for me. I'll try to have a fix for them later. cheers Arnaud On Wed, Apr 9, 2008 at 9:27 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - 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 HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stack overflow in 2.0.9 was: [VOTE] Maven 2.0.9
for the bug on javadoc, those projects are using 2.3. I couldn't test 2.4 on them. I have some projects on 2.4 but they have many less code. Arnaud On Wed, Apr 9, 2008 at 2:32 PM, Brett Porter [EMAIL PROTECTED] wrote: What version of the javadoc plugin? The only thing I can think it'd be related to is the change to the lifecycle forking. - Brett On 09/04/2008, at 10:09 PM, Arnaud HERITIER wrote: Just to let you know, I made more tests I noticed two problems : - I have several javadocs errors I hadn't before with 2.0.7 on our continuous integration server. Those errors are related to the jdk : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4923163 I don't understand why I didn't have them with 2.0.7. - I have an infinite loop with the sonar plugin : 09-Apr-2008 03:23:10[ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare 09-Apr-2008 03:23:10java.lang.StackOverflowError 09-Apr-2008 03:23:10at java.security.AccessController.doPrivileged(Native Method) 09-Apr-2008 03:23:10at java.net.URLClassLoader.findResource(URLClassLoader.java:359) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232) 09-Apr-2008 03:23:10at java.lang.ClassLoader.getResource(ClassLoader.java:977) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) 09-Apr-2008 03:23:10at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) 09-Apr-2008 03:23:10at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) Those problems are minor for me. I'll try to have a fix for them later. cheers Arnaud On Wed, Apr 9, 2008 at 9:27 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Time to vote on the final Maven 2.0.9 Release. We went through 8 Release Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during that time. Note that there were no source changes between RC8 and this final build. Release is staged at: http://people.apache.org/~brianf/stage-2.0.9 +1 - No problems with the Struts and OpenJPA builds, and the .tar.gz distribution looks good. Thanks for all your work on this, Brian. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
Benjamin Bentmann wrote:
You could of course write an encoding detection plugin which could
examine the code and set the required property accordingly.
Personally, I don't see the use case for that. If there are really users
out there that don't know what file encoding they are using when writing up
their sources, they are most probably happy with the proposed default value
of Latin-1. Alternatively, this encoding detection plugin could be as
simple as printing out the Java system property ${file.encoding} which obviously
worked well enough for the user.
${file.encoding} will only work if the file originated on the same machine.
I think of semi-automatic conversions of inhomogenous code into maven.
E.g. some teacher collects homework from his students as a bunch of zip
files containing only source, has a script to turn each into a maven
project, and a master project interacting with them, like letting them
compete with one another or whatever. In this case one might wish to
automatically detect the encoding of every module, especially in locales
with several commonly used encodings, so that string literals in these
classes are handled correctly without the students even knowing what an
encoding is.
But that's a corner case, so I guess we should stop discussion about the
use of such a program here, until someone actually requires it.
Greetings,
Martin
signature.asc
Description: OpenPGP digital signature
RE: plugin versions in super POM and future releases
Yes. The intent was never to lock everyone in place indefinitely. Although I like the appeal of forcing people to choose to upgrade the plugin versions and start managing them, this isn't what the users have asked for nor expect. -Original Message- From: Christian Edward Gruber [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 9:15 AM To: Maven Developers List Subject: Re: plugin versions in super POM and future releases So just to clarify (with pretend numbers), would this sort of scenario be fair: maven-2.0.9 includes: maven-install-plugin-1.9, maven-test-plugin-2.2 maven-compile-plugin-2.7 but maven-2.0.10 includes: maven-install-plugin-1.9, maven-test-plugin-2.3 maven-compile-plugin-2.8 So then would any two executions of 2.0.9 in its default configuration would always use 1.9 of install and 2.2 of test, etc.? And would it be fair to say that plugin versions might change between maven releases (2.0.x-2.0.x+1 or 2.x-2.x+1), but would not bump until the next maven version? If that logic is true, then I consider the problem mostly solved, and am exceedingly excited about it. Christian. On 9-Apr-08, at 08:55 , Brian E. Fox wrote: I previously put forth a set of guidelines when we voted on doing this initially. Essentially we would update the plugins only to non alpha or beta versions and versions of plugins that had been released longer than a month unless there was a good reason to do otherwise. I don't see any benefit in forever locking the plugins to where they are now. For the plugins that were locked at alphas/betas (like assembly), these should be upgraded with caution until it reaches a full release version and then the usual rules apply. - 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: commit r495157 - use of system properties
There is a context value called SystemProperties that the DefaultProfileManager is maintaining. That's how the system-property profile activator is working. Just make the activator Contextualizable, and you can pull that properties instance for use in place of System.getProperties(). -john On Apr 9, 2008, at 8:33 AM, Brett Porter wrote: On 09/04/2008, at 9:49 PM, Vincent Siveton wrote: Hi Brett, 2008/4/8, Brett Porter [EMAIL PROTECTED]: Hi Vincent, I was reviewing the commits for 2.0.9 and saw this one: http://svn.apache.org/viewvc/maven/components/branches/ maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles/ activation/FileProfileActivator.java? r1=495147r2=609976diff_format=h Doesn't this need to be able to use the execution properties instead? Since WDYM by execution properties? The env and sysprops are passed in from the CLI via a properties object in the session now, I think. This is particularly emphasised on trunk, but I think it's also available on the branch. this isn't present in the activator, I'm wondering if the value needs to be interpolated before the profile activators get it. In the DefaultProfileManager? That's what I was thinking... - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
RE: How to submit a bug
Start by explaining the problem and the expected / actual result on the user list. If it really is a bug, a lot of dev'ers are also reading there and will redirect you to the jira system[1] and tell you which component it affects. The dev list is more for the developers to communicate. Hth, Nick S. [1] http://jira.codehaus.org/ -Original Message- From: John Wu [mailto:[EMAIL PROTECTED] Sent: Wed 4/9/2008 16:59 To: [EMAIL PROTECTED]; dev@maven.apache.org Subject: How to submit a bug I'm Maven 2 user, and I believe that I found an issue with Maven 2.0.8, how can I submit it somewhere? Thanks, John Wu IMPORTANT NOTICE: If you have received this message in error, please notify the sender immediately and erase the original from your email system. This message is intended only for the use of the individual(s) or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If this message has been received in error, please contact the sender and delete all copies. Like other forms of communication, e-mail communications may be vulnerable to interception by unauthorized parties. If you do not wish us to communicate with you by e-mail, please notify us at your earliest convenience. In the absence of such notification, your consent is assumed. Should you choose to allow us to communicate by e-mail, we will not take any additional security measures (such as encryption) unless specifically requested.
Re: [VOTE] POM Element for Source File Encoding
Paul Benedict wrote: Just a proposal: Maven could loosen its parsing rules when it detects versions greater than it is configured to accept. Forward compatibility would be nice. For anyone seriously interested in interoperability , I suggest a look at http://www.w3.org/2005/05/xsd-versioning-resources.html , especially the use cases, which illustrate several issues quite well. Martin signature.asc Description: OpenPGP digital signature
Re: [VOTE] POM Element for Source File Encoding
Benjamin Bentmann wrote: With regard to user errors, my general suggestion is to fail the build. This unforgiving attitude should not be that unfamilar to users: It has been chosen for a popular format like XML which is also employed by Maven for a few files. The problems depend on the encodings: If one feeds Latin-1 into an UTF-8 decoder, you most likely encouter invalid byte sequences, making the decoder fail. That's my favorite case as it clearly shows the user something is wrong and needs his attention. The other case is worse because more subtle: Feeding UTF-8 into a Latin-1 decoder will pass but produces output that only a human can tell being garbage by closing analyzing the few Non-ASCII characters. Taking this together, one might argue to have UTF-8 the default, not ISO-8859-1. Almost anything that passes UTF-8 encoding constraints will be indeed UTF-8, as non-ASCII files that are not UTF-8 will almost certainly contain sequences not valid in UTF-8. So if a user fails to specify the encoding he uses, and if this encoding isn't UTF-8, then things will break for him. This has two advantages: 1. fail-fast behaviour. If there is a misconfiguration, the maven run will die, and the developer can fix the issue. You don't have to wait for some other developer complaining about garbled strings or a user complaining about a broken website until you can fix things. 2. promote unicode. While there are a lot of encosings out there for historic reasons, most of them suffer severe drawbacks in an international software project, because they either can't express all needed characters, or they are not common outside a small region. So while Taiwanese developers might be happy to develop an English/Chinese project in Big5, prospective american Contributors might not get their editor to load files as Big5. UTF-8, on the other hand, is used worldwide and provides the whole Unicode range. For new projects, I guess UTF-8 would be a reasonable best practice, and making this best practice the default in maven might promote it. Of course this conflicts with previous discussions about Latin1 ensuring that any project can get compiled, as it has no invalid byte sequences. The choice is whether, in the absence of configuration, A) you want your compile to succeed all the time, possibly generating the wrong results, or B) you want your build to fail in case of a misconfiguration (including missing configuration), but ensure correct results if it does not fail. If I understood him correctly, Jason voted for A). I took his request for non-dying builds as a requirement and pointed out that this is possible with Latin1. Now that I think about it, I believe I would rather want B), as I'm all for failfast deterministic behaviour. It should be checked whether plugins really die for invalid UTF-8 sequences, and what the output looks like. If possible, plugins should point out that a misconfiguration of the encoding in the pom (either the plugin configuration or the proposed global configuration property) is possibly the cause of the error, if it's not a developer using another encoding. Note that ASCII-only sources will compile cleanly no matter the default encoding, so all projects that don't need to worry about encoding won't be forced to do so. Only international projects where encoding is relevant will force their developers to either follow best practices or explicitely state their policy. Greetings, Martin signature.asc Description: OpenPGP digital signature
Re: plugin versions in super POM and future releases
On 10/04/2008, at 2:11 AM, John Casey wrote: We cannot change the modelVersion without a fairly major refactor of one of the most complex classes in Maven - DefaultMavenProjectBuilder. http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x-terse/maven-project/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java?r1=620420r2=620422diff_format=h This isn't that hard if the model hasn't changed significantly - the difficulty is going to be when behaviour differs or it needs to be translated. (I haven't even started on the project-builder refactor...I don't know about others). See my other message about setting up regression testing for this - I'd like to think about how we get started on it. If users are not specifying plugin versions, then they are implicitly saying they're okay with some drift WRT plugin versions in their builds. I think this is a reasonable argument, in conjunction with the guidelines Brian set out - the key being sufficient time to identify any regressions before updating a plugin.Given more time I see the reasons for updating - it would be good to incorporate the toolchain enabled plugins, for example. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
Taking this together, one might argue to have UTF-8 the default, not
ISO-8859-1.
In general, I completely agree with your preference to Unicode and fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today, I tried to consider consistency with existing behavior. The
Maven Site Plugin was already using Latin-1 as the default value for
inputEncoding and outputEncoding and so I proposed this for other plugins,
too. Indeed, one of the patches (MJAVADOC-165) was just released such that
already two plugins teach users this default value. Therefore I fear it
might be too late to introduce another default value. If the community
believes this change is worth the confusion caused on users, I'm the first
one running the other way round ;-)
It should be checked whether plugins really die for invalid UTF-8
sequences, and what the output looks like.
That's a good point. It appears we need to do some extra homework here: The
simplisitic use of InputStreamReader and OutputStreamReader will silently
convert unmappable byte sequences to a default character ('?', see also
[0]). I guess we could nicely hide the required implementation by means of
the existing methods in Reader-/WriterFactory from plexus-utils.
Note that ASCII-only sources will compile cleanly no matter the default
encoding
Most of time, but UTF-16 or EBCDIC have not even ASCII in common.
Benjamin
[0] http://java.sun.com/javase/6/docs/api/java/io/OutputStreamWriter.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin versions in super POM and future releases
-1 We cannot change the modelVersion without a fairly major refactor of one of the most complex classes in Maven - DefaultMavenProjectBuilder. So to make this declaration, we're basically pinning users to these plugin versions until sometime after 2.1 most likely (I haven't even started on the project-builder refactor...I don't know about others). If users are not specifying plugin versions, then they are implicitly saying they're okay with some drift WRT plugin versions in their builds. Specifying plugin versions in the super-POM merely slows that velocity down to a manageable speed (an actual drift, I guess, not a headlong rush). If they want their plugin versions pinned, they can (and should, by all means) manage that themselves...but I think it's a bad idea to freeze all plugin progress by default until sometime post-2.1. -john On Apr 8, 2008, at 11:54 PM, Brett Porter wrote: Hi, I was wondering if anyone had opinions about what happens in 2.0.10, 2.1, etc with the versions of plugins that are now specified in the super POM. My gut feeling is that we should not upgrade these without a change to the modelVersion - the POM should be the sole reference for build behaviour and while I accept that changing the version of Maven can bring some behavioural differences this would be the most significant. On the other hand, we wouldn't want to perpetuate forever bugs that might be in the plugins (especially those that are a bit newer and labelled alpha/beta). I think our default stance from here on should be to make no modifications to the super POM without bumping the modelVersion, but reserve the right to make exceptions if the case arises. How do others feel about this? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Planning for 2.0.10
Now that 2.0.9 is essentially behind us, I think the focus for the next release needs to continue on preventing new regressions and stomping out the old ones. This should take precedence over new features and other nice to haves as we still have a significant user base stuck on various releases due to changes and regressions we introduced in the past. There are 27 issues scheduled for .10 currently [1], most of these issues are things that represent regressions introduced in earlier releases and issues with the highest number of votes (usually they are the same). While not set in concrete, we should try to maintain this list and resist the urge to pile in tons of cruft. Only really important issues or regressions should be brought forward to .10 I'd like to aim for starting the release process in 4-6 weeks. We should be cognizant of the no regression plan when fixing any issues so we don't have to chase them down at the end. This means good unit tests and core Its should be introduced for all changes. This is important to build upon to help identify future regressions and more importantly gives us a concrete set of tests to judge 2.1's compatibility. I've found that in many cases the unit tests alone simply aren't good enough to detect issues as we go forward...I think in most cases they just aren't exhaustive enough, but also they don't cover all the interactions and classpath weirdness. As we discussed before, the doxia beta should be introduced to .10 asap so we have time to work out any issues. Thanks, Brian
RE: [VOTE] POM Element for Source File Encoding
As for today, I tried to consider consistency with existing behavior. The Maven Site Plugin was already using Latin-1 as the default value for inputEncoding and outputEncoding and so I proposed this for other plugins, too. Indeed, one of the patches (MJAVADOC-165) was just released such that already two plugins teach users this default value. Therefore I fear it might be too late to introduce another default value. If the community believes this change is worth the confusion caused on users, I'm the first one running the other way round ;-) Don't break existing builds. No regressions. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven 2.0.9 and enforcer plugin
Can you show the debug output to see the real stack trace? We've run through several tests with people using the enforcer so this is interesting. -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 12:41 PM To: Maven Developers List Subject: maven 2.0.9 and enforcer plugin Using maven 2.0.9 and the enforcer plugin I receive this error : mvn install [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building POM Parent Generali [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-enforcer-plugin:1.0-alpha-3 Cause: Class 'org.apache.maven.shared.enforcer.rule.api.EnforcerRule' cannot be instantiated [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed Apr 09 18:36:40 CEST 2008 [INFO] Final Memory: 7M/63M [INFO] My pom has this : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.0-alpha-3/version executions execution idenforce-versions/id goals goalenforce-once/goal /goals configuration rules requireMavenVersion version2.0.9/version /requireMavenVersion requireJavaVersion version1.5/version /requireJavaVersion requirePluginVersions messageBest Practice is to always define plugin versions!/message /requirePluginVersions /rules /configuration /execution /executions /plugin any idea ? -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - 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]
maven 2.0.9 and enforcer plugin
Using maven 2.0.9 and the enforcer plugin I receive this error : mvn install [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building POM Parent Generali [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-enforcer-plugin:1.0-alpha-3 Cause: Class 'org.apache.maven.shared.enforcer.rule.api.EnforcerRule' cannot be instantiated [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed Apr 09 18:36:40 CEST 2008 [INFO] Final Memory: 7M/63M [INFO] My pom has this : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.0-alpha-3/version executions execution idenforce-versions/id goals goalenforce-once/goal /goals configuration rules requireMavenVersion version2.0.9/version /requireMavenVersion requireJavaVersion version1.5/version /requireJavaVersion requirePluginVersions messageBest Practice is to always define plugin versions!/message /requirePluginVersions /rules /configuration /execution /executions /plugin any idea ? -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning for 2.0.10
Sounds good. I think we should consider MNG-3160 - to get all the integration tests that have been disabled for one reason or another working again. - Brett On 10/04/2008, at 2:51 AM, Brian E. Fox wrote: Now that 2.0.9 is essentially behind us, I think the focus for the next release needs to continue on preventing new regressions and stomping out the old ones. This should take precedence over new features and other nice to haves as we still have a significant user base stuck on various releases due to changes and regressions we introduced in the past. There are 27 issues scheduled for .10 currently [1], most of these issues are things that represent regressions introduced in earlier releases and issues with the highest number of votes (usually they are the same). While not set in concrete, we should try to maintain this list and resist the urge to pile in tons of cruft. Only really important issues or regressions should be brought forward to .10 I'd like to aim for starting the release process in 4-6 weeks. We should be cognizant of the no regression plan when fixing any issues so we don't have to chase them down at the end. This means good unit tests and core Its should be introduced for all changes. This is important to build upon to help identify future regressions and more importantly gives us a concrete set of tests to judge 2.1's compatibility. I've found that in many cases the unit tests alone simply aren't good enough to detect issues as we go forward...I think in most cases they just aren't exhaustive enough, but also they don't cover all the interactions and classpath weirdness. As we discussed before, the doxia beta should be introduced to .10 asap so we have time to work out any issues. Thanks, Brian -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Planning for 2.0.10
That could be a potentially massive undertaking but I agree it's worth pursuing. The existing Its and infrastructure seems to be pretty stable now so it's at least manageable. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 1:13 PM To: Maven Developers List Subject: Re: Planning for 2.0.10 Sounds good. I think we should consider MNG-3160 - to get all the integration tests that have been disabled for one reason or another working again. - Brett On 10/04/2008, at 2:51 AM, Brian E. Fox wrote: Now that 2.0.9 is essentially behind us, I think the focus for the next release needs to continue on preventing new regressions and stomping out the old ones. This should take precedence over new features and other nice to haves as we still have a significant user base stuck on various releases due to changes and regressions we introduced in the past. There are 27 issues scheduled for .10 currently [1], most of these issues are things that represent regressions introduced in earlier releases and issues with the highest number of votes (usually they are the same). While not set in concrete, we should try to maintain this list and resist the urge to pile in tons of cruft. Only really important issues or regressions should be brought forward to .10 I'd like to aim for starting the release process in 4-6 weeks. We should be cognizant of the no regression plan when fixing any issues so we don't have to chase them down at the end. This means good unit tests and core Its should be introduced for all changes. This is important to build upon to help identify future regressions and more importantly gives us a concrete set of tests to judge 2.1's compatibility. I've found that in many cases the unit tests alone simply aren't good enough to detect issues as we go forward...I think in most cases they just aren't exhaustive enough, but also they don't cover all the interactions and classpath weirdness. As we discussed before, the doxia beta should be introduced to .10 asap so we have time to work out any issues. Thanks, Brian -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: [VOTE] POM Element for Source File Encoding
Benjamin Bentmann wrote:
In general, I completely agree with your preference to Unicode and
fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today, I tried to consider consistency with existing behavior. The
Maven Site Plugin was already using Latin-1 as the default value for
inputEncoding and outputEncoding and so I proposed this for other plugins,
too. Indeed, one of the patches (MJAVADOC-165) was just released such that
already two plugins teach users this default value. Therefore I fear it
might be too late to introduce another default value. If the community
believes this change is worth the confusion caused on users, I'm the first
one running the other way round ;-)
I see your point. Worth another vote? Or should this switch be postponed
to 2.1, trading consistency in minor version upgrades for a longer time
for these Latin1 defaults to be established?
Given the failfast nature of the UTF-8 default, we won't have to worry
about the switch going unnoticed. Developers switching from a version
defaulting to Latin1 to UTF-8 will notice the change immediately, and
for development in a heterogenous environment they can simply override
the super-POM with their own default.
So while I agree that a change in default either now or in the future is
ugly, it is not taboo, and I believe woth the gain.
That's a good point. It appears we need to do some extra homework here: The
simplisitic use of InputStreamReader and OutputStreamReader will silently
convert unmappable byte sequences to a default character ('?', see also
[0]). I guess we could nicely hide the required implementation by means of
the existing methods in Reader-/WriterFactory from plexus-utils.
That works for plugins doing the conversion in code under our control.
Other plugins that use external libraries or tools might be more difficult.
Note that ASCII-only sources will compile cleanly no matter the default
encoding
Most of time, but UTF-16 or EBCDIC have not even ASCII in common.
I was thinking about the default of the default, i.e. the value to be
set in the super-POM. We certainly won't choose UTF-16 or EBCDIC for
this global default, and as files encoded in UTF-16 or EBCDIC don't
count as ASCII-only, my
Martin
signature.asc
Description: OpenPGP digital signature
Re: [VOTE] POM Element for Source File Encoding
All sounds fine. Just wanted you to think about the bigger picture in mind. Please do the work on a branch and go through the rigor of Brian's example and make sure it works before you merge it into something we would release to users. This is not an insignificant change. On 9-Apr-08, at 10:36 AM, Benjamin Bentmann wrote: Make sure you consider the case where you have people developing the same code base all over the world, and the possible reasoning of falling back to platform default encoding. Consider the team spread across the US, Russia, and China and what do they do normally? This international spread of developers is in particular the case we have in mind. I mean, how should such a team (say the Maven community) deliver reliable build output if not all developers have agreed to use the same file encoding for the sources? Say the US devs would have ASCII as default encoding, the Europeans Latin-1 and the Asians Big5 for our nice potpourri. Even if all have agreed to use English for coding, you still might encounter Non-ASCII characters that get messed up, e.g. in javadoc comments that carry the name of the contributor/committer. Other developers might experience build failures because of encoding mismatch, at best other people's names are disfigured which is rather impolite. The Eclipse folks had a similar problem [0]. The solution: Lock the encoding down for the entire project. Is it possible to specify an encoding in one place that doesn't work somewhere else? Yes, in theory you can have one user specify an encoding that another user's JVM does not support. As the class javadoc about Charset [1] states, only a few encodings - including Latin-1 and UTF-8 - are required to be supported, although the reference implementation from Sun supports quite more encodings [2]. However, I don't consider this as a practical concern. Given that support for UTF-8 is mandatory, there exists an encoding that can handle quite any character people would like to enter and Java can handle. Hence there exists a solution that works for everyone on the team. I am fortunate in that I've never seen an encoding problem in Maven personally. In your proposal you talk about aligning the encoding value but my question in what cases have you found the default encoding not working as you don't talk about that at all in the proposal. Well, choose your favorite from a search for encoding on all Maven 2 projects in JIRA ;-) - http://jira.codehaus.org/browse/MNG-2932 - http://jira.codehaus.org/browse/MANTTASKS-14 - http://jira.codehaus.org/browse/MTAGLIST-27 - http://jira.codehaus.org/browse/MRELEASE-302 - http://jira.codehaus.org/browse/DOXIA-103 - http://jira.codehaus.org/browse/MCHANGES-71 - (about 300 more hits) ASCII is quite safe, but anything which requires more than those 7 bits just needs special care. Do you know what happens with all the tools that people use. Like checking into all SCMs, and what happens when people checkout on to their system, editors, IDEs. I'm merely suggesting that their might be a reason most things fall back to the default encoding on the system because it's generally been a hard thing to coral. In principle you're right, most of the tools are intended for usage with the platform's encoding. This seems to include the popular diff/ patch tools used by many SCMs, they have not really support for different encodings [3] (yet another historic design flaw, next to the two-digit year format). Also, the SCMs themselves seem not to care about (file content) encoding yet, I have found proposals for Subversion [5] and Bazaar [4] but that's it. However, as far as I can tell, not knowing about file encoding SCMs also do not perform any conversions on the file content but simply assume a simple byte-to-char mapping like ASCII when doing EOL normalization or keyword substitution. As for editors and IDEs: Even this tiny thing Notepad from Windows supports UTF-8 nowadays and I wouldn't call that an editor. Does anybody know about a popular editor/IDE that calls itself mature but does not allow to configure file encoding? Benjamin [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132898 [1] http://java.sun.com/javase/6/docs/api/java/nio/charset/ Charset.html [2] http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html [3] http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#Internationalization [4] http://bazaar-vcs.org/UnicodeSupport?action=showredirect=EncodingSupport#head-43c0111da063796da433179faaf8d065bda5c42e [5] http://svn.haxx.se/dev/archive-2006-03/1182.shtml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype
Re: [VOTE] POM Element for Source File Encoding
Make sure you consider the case where you have people developing the same code base all over the world, and the possible reasoning of falling back to platform default encoding. Consider the team spread across the US, Russia, and China and what do they do normally? This international spread of developers is in particular the case we have in mind. I mean, how should such a team (say the Maven community) deliver reliable build output if not all developers have agreed to use the same file encoding for the sources? Say the US devs would have ASCII as default encoding, the Europeans Latin-1 and the Asians Big5 for our nice potpourri. Even if all have agreed to use English for coding, you still might encounter Non-ASCII characters that get messed up, e.g. in javadoc comments that carry the name of the contributor/committer. Other developers might experience build failures because of encoding mismatch, at best other people's names are disfigured which is rather impolite. The Eclipse folks had a similar problem [0]. The solution: Lock the encoding down for the entire project. Is it possible to specify an encoding in one place that doesn't work somewhere else? Yes, in theory you can have one user specify an encoding that another user's JVM does not support. As the class javadoc about Charset [1] states, only a few encodings - including Latin-1 and UTF-8 - are required to be supported, although the reference implementation from Sun supports quite more encodings [2]. However, I don't consider this as a practical concern. Given that support for UTF-8 is mandatory, there exists an encoding that can handle quite any character people would like to enter and Java can handle. Hence there exists a solution that works for everyone on the team. I am fortunate in that I've never seen an encoding problem in Maven personally. In your proposal you talk about aligning the encoding value but my question in what cases have you found the default encoding not working as you don't talk about that at all in the proposal. Well, choose your favorite from a search for encoding on all Maven 2 projects in JIRA ;-) - http://jira.codehaus.org/browse/MNG-2932 - http://jira.codehaus.org/browse/MANTTASKS-14 - http://jira.codehaus.org/browse/MTAGLIST-27 - http://jira.codehaus.org/browse/MRELEASE-302 - http://jira.codehaus.org/browse/DOXIA-103 - http://jira.codehaus.org/browse/MCHANGES-71 - (about 300 more hits) ASCII is quite safe, but anything which requires more than those 7 bits just needs special care. Do you know what happens with all the tools that people use. Like checking into all SCMs, and what happens when people checkout on to their system, editors, IDEs. I'm merely suggesting that their might be a reason most things fall back to the default encoding on the system because it's generally been a hard thing to coral. In principle you're right, most of the tools are intended for usage with the platform's encoding. This seems to include the popular diff/patch tools used by many SCMs, they have not really support for different encodings [3] (yet another historic design flaw, next to the two-digit year format). Also, the SCMs themselves seem not to care about (file content) encoding yet, I have found proposals for Subversion [5] and Bazaar [4] but that's it. However, as far as I can tell, not knowing about file encoding SCMs also do not perform any conversions on the file content but simply assume a simple byte-to-char mapping like ASCII when doing EOL normalization or keyword substitution. As for editors and IDEs: Even this tiny thing Notepad from Windows supports UTF-8 nowadays and I wouldn't call that an editor. Does anybody know about a popular editor/IDE that calls itself mature but does not allow to configure file encoding? Benjamin [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132898 [1] http://java.sun.com/javase/6/docs/api/java/nio/charset/Charset.html [2] http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html [3] http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#Internationalization [4] http://bazaar-vcs.org/UnicodeSupport?action=showredirect=EncodingSupport#head-43c0111da063796da433179faaf8d065bda5c42e [5] http://svn.haxx.se/dev/archive-2006-03/1182.shtml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
I see your point. Worth another vote? Or should this switch be postponed to 2.1, trading consistency in minor version upgrades for a longer time for these Latin1 defaults to be established? [...] So while I agree that a change in default either now or in the future is ugly, it is not taboo, and I believe woth the gain. Latin-1 being the default value was part of our proposal and not many people complained about that nor changed their previous votes. So I believe another vote won't deliver a different outcome. Besides, Brian's honorable efforts to ban regressions are a good argument to keep the already started route with Latin-1. It might not be the best default value, but it's only a one liner to change it. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
On Wed, Apr 9, 2008 at 7:36 PM, Benjamin Bentmann [EMAIL PROTECTED] wrote: Make sure you consider the case where you have people developing the same code base all over the world, and the possible reasoning of falling back to platform default encoding. Consider the team spread across the US, Russia, and China and what do they do normally? This international spread of developers is in particular the case we have in mind. I mean, how should such a team (say the Maven community) deliver reliable build output if not all developers have agreed to use the same file encoding for the sources? Say the US devs would have ASCII as default encoding, the Europeans Latin-1 and the Asians Big5 for our nice potpourri. Even if all have agreed to use English for coding, you still might encounter Non-ASCII characters that get messed up, e.g. in javadoc comments that carry the name of the contributor/committer. Other developers might experience build failures because of encoding mismatch, at best other people's names are disfigured which is rather impolite. The Eclipse folks had a similar problem [0]. The solution: Lock the encoding down for the entire project.\ just for the record, netbeans.org projects all use UTF-8. We have devs in US, Czech rep, Russia and elsewhere. Netbeans allows to set default encoding per project, for maven project I currently lookup how maven-compiler-plugin is configured. If no configuration is in place I fallback to platform encoding. Encoding is not only different across countries but also across platforms. While most Linux distributions use UTF-8, you get different encoding based on what localized version of Windows you buy I think. East european set is different from west europe. My Mac fallbacks to something called MacRoman as default encoding. Milos Is it possible to specify an encoding in one place that doesn't work somewhere else? Yes, in theory you can have one user specify an encoding that another user's JVM does not support. As the class javadoc about Charset [1] states, only a few encodings - including Latin-1 and UTF-8 - are required to be supported, although the reference implementation from Sun supports quite more encodings [2]. However, I don't consider this as a practical concern. Given that support for UTF-8 is mandatory, there exists an encoding that can handle quite any character people would like to enter and Java can handle. Hence there exists a solution that works for everyone on the team. I am fortunate in that I've never seen an encoding problem in Maven personally. In your proposal you talk about aligning the encoding value but my question in what cases have you found the default encoding not working as you don't talk about that at all in the proposal. Well, choose your favorite from a search for encoding on all Maven 2 projects in JIRA ;-) - http://jira.codehaus.org/browse/MNG-2932 - http://jira.codehaus.org/browse/MANTTASKS-14 - http://jira.codehaus.org/browse/MTAGLIST-27 - http://jira.codehaus.org/browse/MRELEASE-302 - http://jira.codehaus.org/browse/DOXIA-103 - http://jira.codehaus.org/browse/MCHANGES-71 - (about 300 more hits) ASCII is quite safe, but anything which requires more than those 7 bits just needs special care. Do you know what happens with all the tools that people use. Like checking into all SCMs, and what happens when people checkout on to their system, editors, IDEs. I'm merely suggesting that their might be a reason most things fall back to the default encoding on the system because it's generally been a hard thing to coral. In principle you're right, most of the tools are intended for usage with the platform's encoding. This seems to include the popular diff/patch tools used by many SCMs, they have not really support for different encodings [3] (yet another historic design flaw, next to the two-digit year format). Also, the SCMs themselves seem not to care about (file content) encoding yet, I have found proposals for Subversion [5] and Bazaar [4] but that's it. However, as far as I can tell, not knowing about file encoding SCMs also do not perform any conversions on the file content but simply assume a simple byte-to-char mapping like ASCII when doing EOL normalization or keyword substitution. As for editors and IDEs: Even this tiny thing Notepad from Windows supports UTF-8 nowadays and I wouldn't call that an editor. Does anybody know about a popular editor/IDE that calls itself mature but does not allow to configure file encoding? Benjamin [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132898 [1] http://java.sun.com/javase/6/docs/api/java/nio/charset/Charset.html [2] http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html [3] http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#Internationalization [4]
Re: Planning for 2.0.10
Brian E. Fox skrev: Now that 2.0.9 is essentially behind us, I think the focus for the next release needs to continue on preventing new regressions and stomping out the old ones. This should take precedence over new features and other nice to haves as we still have a significant user base stuck on [snip] All this is important (killing of regressions). But I also want to bring focus to another really killer-issue which seems to have been dormant for a long time - and which is a wagon problem - and which probably is a real PITA for enterprise users - which is probably a large userbase: http://jira.codehaus.org/browse/WAGON-80 It has 19 votes and 20 watchers - and is a year old. It essentially renders maven useless behind a corporate firewall because proxying is applied globally in maven - and nonProxyHosts are not taken into account. Even by using a local mirror with proximity or archiva - there is still a need for proxy-support to reach external resources like findbugs rules etc - or the other way - to access local LAN resources - without going through the corporate proxy. WDYT? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Planning for 2.0.10
It essentially renders maven useless behind a corporate firewall because proxying is applied globally in maven - and nonProxyHosts are not taken into account. Someplace with a corporate firewall most likely needs a repo manager anyway, which should handle this without blinking. Even by using a local mirror with proximity or archiva - there is still a need for proxy-support to reach external resources like findbugs rules etc - or the other way - to access local LAN resources - without going through the corporate proxy. It's not a good idea to have your build dependent on urls. For one, urls have a funny way of changing over time. Second, it breaks offline use and possibly outside the network building (pseudo-offline). A better way to handle these rules is usually to stick them in a jar with assembly and then add them to the plugin's classpath (I know checkstyle and pmd can do this, I don't know about findbugs). The added benefit to this is you have now versioned your rules with your source. Ever tried to build an old codebase after the pmd rules have been tightened? All that being said, I put in MNG-3512 for 2.0.10 to use the updated wagon. We'll try to get the patch applied and wagon released soon so it doesn't hold up the .10 release. I still suggest not relying on urls strictly for portability reasons, but Maven should still attempt to do the right thing. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
Le mercredi 09 avril 2008, Benjamin Bentmann a écrit : I see your point. Worth another vote? Or should this switch be postponed to 2.1, trading consistency in minor version upgrades for a longer time for these Latin1 defaults to be established? [...] So while I agree that a change in default either now or in the future is ugly, it is not taboo, and I believe woth the gain. Latin-1 being the default value was part of our proposal and not many people complained about that nor changed their previous votes. So I believe another vote won't deliver a different outcome. Besides, Brian's honorable efforts to ban regressions are a good argument to keep the already started route with Latin-1. It might not be the best default value, but it's only a one liner to change it. I have one argument in favor of ISO-8859-1 as default: it's the default encoding of properties files, as defined by JDK java.util.Properties class. When Maven will be JDK 1.5+, we'll be able to switch to XML properties files, and then no problem for UTF-8 as default... 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: [VOTE] POM Element for Source File Encoding
Le mercredi 09 avril 2008, Jason van Zyl a écrit : All sounds fine. Just wanted you to think about the bigger picture in mind. Please do the work on a branch and go through the rigor of Brian's example and make sure it works before you merge it into something we would release to users. This is not an insignificant change. I created http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/ with javadoc and jxr plugins branches to test the change, and sample use case. Isn't it sufficient? Hervé On 9-Apr-08, at 10:36 AM, Benjamin Bentmann wrote: Make sure you consider the case where you have people developing the same code base all over the world, and the possible reasoning of falling back to platform default encoding. Consider the team spread across the US, Russia, and China and what do they do normally? This international spread of developers is in particular the case we have in mind. I mean, how should such a team (say the Maven community) deliver reliable build output if not all developers have agreed to use the same file encoding for the sources? Say the US devs would have ASCII as default encoding, the Europeans Latin-1 and the Asians Big5 for our nice potpourri. Even if all have agreed to use English for coding, you still might encounter Non-ASCII characters that get messed up, e.g. in javadoc comments that carry the name of the contributor/committer. Other developers might experience build failures because of encoding mismatch, at best other people's names are disfigured which is rather impolite. The Eclipse folks had a similar problem [0]. The solution: Lock the encoding down for the entire project. Is it possible to specify an encoding in one place that doesn't work somewhere else? Yes, in theory you can have one user specify an encoding that another user's JVM does not support. As the class javadoc about Charset [1] states, only a few encodings - including Latin-1 and UTF-8 - are required to be supported, although the reference implementation from Sun supports quite more encodings [2]. However, I don't consider this as a practical concern. Given that support for UTF-8 is mandatory, there exists an encoding that can handle quite any character people would like to enter and Java can handle. Hence there exists a solution that works for everyone on the team. I am fortunate in that I've never seen an encoding problem in Maven personally. In your proposal you talk about aligning the encoding value but my question in what cases have you found the default encoding not working as you don't talk about that at all in the proposal. Well, choose your favorite from a search for encoding on all Maven 2 projects in JIRA ;-) - http://jira.codehaus.org/browse/MNG-2932 - http://jira.codehaus.org/browse/MANTTASKS-14 - http://jira.codehaus.org/browse/MTAGLIST-27 - http://jira.codehaus.org/browse/MRELEASE-302 - http://jira.codehaus.org/browse/DOXIA-103 - http://jira.codehaus.org/browse/MCHANGES-71 - (about 300 more hits) ASCII is quite safe, but anything which requires more than those 7 bits just needs special care. Do you know what happens with all the tools that people use. Like checking into all SCMs, and what happens when people checkout on to their system, editors, IDEs. I'm merely suggesting that their might be a reason most things fall back to the default encoding on the system because it's generally been a hard thing to coral. In principle you're right, most of the tools are intended for usage with the platform's encoding. This seems to include the popular diff/ patch tools used by many SCMs, they have not really support for different encodings [3] (yet another historic design flaw, next to the two-digit year format). Also, the SCMs themselves seem not to care about (file content) encoding yet, I have found proposals for Subversion [5] and Bazaar [4] but that's it. However, as far as I can tell, not knowing about file encoding SCMs also do not perform any conversions on the file content but simply assume a simple byte-to-char mapping like ASCII when doing EOL normalization or keyword substitution. As for editors and IDEs: Even this tiny thing Notepad from Windows supports UTF-8 nowadays and I wouldn't call that an editor. Does anybody know about a popular editor/IDE that calls itself mature but does not allow to configure file encoding? Benjamin [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=132898 [1] http://java.sun.com/javase/6/docs/api/java/nio/charset/ Charset.html [2] http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html [3] http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#Internat ionalization [4] http://bazaar-vcs.org/UnicodeSupport?action=showredirect=EncodingSupport #head-43c0111da063796da433179faaf8d065bda5c42e [5] http://svn.haxx.se/dev/archive-2006-03/1182.shtml
Re: Planning for 2.0.10
I'm also interested if we can try to fix this one : http://jira.codehaus.org/browse/MECLIPSE-394 If we can validate it by reproducing it with another plugin we can suppose that it i related to the core (I don't see how i can be a bug in the plugin). (I already had this bug but I didn't yet take the time to create a testcase) arnaud On Wed, Apr 9, 2008 at 10:13 PM, Brian E. Fox [EMAIL PROTECTED] wrote: It essentially renders maven useless behind a corporate firewall because proxying is applied globally in maven - and nonProxyHosts are not taken into account. Someplace with a corporate firewall most likely needs a repo manager anyway, which should handle this without blinking. Even by using a local mirror with proximity or archiva - there is still a need for proxy-support to reach external resources like findbugs rules etc - or the other way - to access local LAN resources - without going through the corporate proxy. It's not a good idea to have your build dependent on urls. For one, urls have a funny way of changing over time. Second, it breaks offline use and possibly outside the network building (pseudo-offline). A better way to handle these rules is usually to stick them in a jar with assembly and then add them to the plugin's classpath (I know checkstyle and pmd can do this, I don't know about findbugs). The added benefit to this is you have now versioned your rules with your source. Ever tried to build an old codebase after the pmd rules have been tightened? All that being said, I put in MNG-3512 for 2.0.10 to use the updated wagon. We'll try to get the patch applied and wagon released soon so it doesn't hold up the .10 release. I still suggest not relying on urls strictly for portability reasons, but Maven should still attempt to do the right thing. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2.0.9 and enforcer plugin
I had this when I attempted to use the enforcer plugin, I assumed it was http://jira.codehaus.org/browse/MENFORCER-25. It works okay with the trunk, but that's no good if your project can't rely on snapshots. Mark On 09/04/2008, Brian E. Fox [EMAIL PROTECTED] wrote: Can you show the debug output to see the real stack trace? We've run through several tests with people using the enforcer so this is interesting. -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 12:41 PM To: Maven Developers List Subject: maven 2.0.9 and enforcer plugin Using maven 2.0.9 and the enforcer plugin I receive this error : mvn install [INFO] Scanning for projects... WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building POM Parent Generali [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-enforcer-plugin:1.0-alpha-3 Cause: Class 'org.apache.maven.shared.enforcer.rule.api.EnforcerRule' cannot be instantiated [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed Apr 09 18:36:40 CEST 2008 [INFO] Final Memory: 7M/63M [INFO] My pom has this : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.0-alpha-3/version executions execution idenforce-versions/id goals goalenforce-once/goal /goals configuration rules requireMavenVersion version2.0.9/version /requireMavenVersion requireJavaVersion version1.5/version /requireJavaVersion requirePluginVersions messageBest Practice is to always define plugin versions!/message /requirePluginVersions /rules /configuration /execution /executions /plugin any idea ? -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - 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: maven 2.0.9 and enforcer plugin
On 09/04/2008, Mark Hobson [EMAIL PROTECTED] wrote: I had this when I attempted to use the enforcer plugin, I assumed it was http://jira.codehaus.org/browse/MENFORCER-25. It works okay with the trunk, but that's no good if your project can't rely on snapshots. P.S. That was with 2.0.8, not 2.0.9. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Maven 2.0.9
Results:
Binding +11: Brian, Wendy, Arnaud, Brett, Vincent, Lukas, Stepane,
Jason, Jesse, John, Olivier
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2008 12:42 PM
To: Maven Developers List
Subject: [VOTE] Maven 2.0.9
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
Release is staged at:
http://people.apache.org/~brianf/stage-2.0.9
Binaries are here:
http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/
List of issues fixed:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
* [MNG-3316] - Barfs at attribues named .*encoding
* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
* [MNG-3394] - Plugin versions inherited via pluginManagement
cannot be overriden by build.plugins section of sub modules
* [MNG-3396] - Managed versions dont affect over constrained ranges
* [MNG-3400] - MavenProject is not extensible
* [MNG-3405] - Checking for updates from repository logging should
not display if WagonManager is offline
* [MNG-3410] - Managed versions in plugins are not considered when
using them
* [MNG-3415] - Transfer errors cause junk metadata in the local repo
* [MNG-3426] - regression : dependency in plugin configuration
doesn't override plugin classpath
* [MNG-3430] - Toolchain doesn't match Toolchain extensions
* [MNG-3431] - Pom Extensions not supported for Toolchains
* [MNG-3439] - incorrect child dependency selected when parent is
not selected
* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository
* [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo
* [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly
* [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken
* [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells
* [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions
* [MNG-3494] - local pom dependencies should get injected before
inherited dependencies
* [MNG-3495] - NPE at
org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24
1)
** Improvement
* [MNG-428] - Japanese message resource
* [MNG-2881] - Improve logging when downloading snapshots in offline
mode
* [MNG-3279] - Support Exception Chaining for MojoFailureException
* [MNG-3318] - ActiveProjectArtifact should have appropriate equals
and hashCode methods
