Can't checkout trunk on Windows
Hi, There seems to be resources under: maven-embedder\src\test\error-reporting-projects\testReportUnresolvableArtifactWhileAddingExtensionPlugin\local-repo\org\apache\maven\errortest\testReportUnresolvableArtifactWhileAddingExtensionPlugin-maven-plugin that causes the checkout to fail under windows. Can someone on a non-windows box fix this please. Thanks, Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
+1 On 17-Jan-08, at 6:30 PM, Brian E. Fox wrote: It's not entirely true that versions don't matter. Alpha or Beta is really a less important distinction and we are generally trying to move away from more alpha/beta releases. I would argue that since Maven requires Shade to release, that the current version should be 1.0 not alpha or beta. Doing a release is much more than slapping a version (tag) on it. It makes the next version usable by other people to do releases because it means we've pushed a non-snapshot to the public. If there are people unaffected by MSHADE-9, then there is still value to those people in having a release now rather than later. I think in general we try to fix too many things at once and end up not getting important fixes out to the people that need them. I'd rather see a release come out with the current fixes and then when MSHADE-9 is fixed, we do another release. At least then some people can use it rather than making everyone wait...and realistically doing the release doesn't preclude someone from fixing the issue in parallel so it shouldn't in theory delay the inevitable release with the MSHADE-9 fix in it. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 9:25 PM To: Maven Developers List Subject: Re: [VOTE] release maven-shade-plugin 1.0-beta-1 Responding out of order, techincal stuff first... Daniel Kulp wrote: The fact is MSHADE-9 is not something we can fix in maven-shade-plugin. It's a bug in ASM and isn't fixable until they provide a fix. (unless someone wants to jump into ASM code. I don't have the time.) I'm not saying MSHADE-9 is easy to fix, but that claim assumes we're using ASM correctly, which seems like a pretty bold assumption to me; ASM is notoriously finicky. If anything's likely to be wrong, it's probably us! Since they haven't provided a new version into the repos in almost a year, I'm not going to hold my breath for a fix. Version 3.1 of ASM came out in October. ASM is very much a live project. I'd say it's at least worth trying the latest version of ASM. IMO, we shouldn't let that hold up moving forward with getting this plugin in shape for the many people and projects that don't need that fixed. I agree we should do a release now. But I do think it matters what we call it. I'd prefer to not get into "version number" arguments as it really just doesn't matter. I disagree that version numbers don't matter, though it's obviously a seductive argument. (It's just a number, right?) But bugs certainly do matter when they get released (or, at least, we have to behave as if they do or we'll release crappy software). But all we do when we make a "release" is slap a version number/name on something. If version numbers don't matter, then it doesn't matter what bugs we fix before we change version numbers, i.e. it doesn't matter what bugs we fix before we release. Since bugs and releases matter, version numbers matter just as much as that. Of course, if bugs don't matter, then sure, it doesn't matter whether we call our buggy software 1.0 or 2008 Business Edition. ;-) Specifically, if MSHADE-9 doesn't matter at all, well, it's the only "Blocker" bug filed against the shade plugin right now, so I guess we *SHOULD* release 1.0... none of the other bugs matter as much as that one, right? :-) -Dan - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (29 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
I agree 100%, release often its the only way things really get used and tested in the wild... if people have problems they can alway roll back to the last release in the deps... On Fri, 18 Jan 2008 15:30:51 Brian E. Fox wrote: ... > the people that need them. I'd rather see a release come out with the > current fixes and then when MSHADE-9 is fixed, we do another release. At > least then some people can use it rather than making everyone wait...and > realistically doing the release doesn't preclude someone from fixing the > issue in parallel so it shouldn't in theory delay the inevitable release > with the MSHADE-9 fix in it. > -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] release maven-shade-plugin 1.0-beta-1
It's not entirely true that versions don't matter. Alpha or Beta is really a less important distinction and we are generally trying to move away from more alpha/beta releases. I would argue that since Maven requires Shade to release, that the current version should be 1.0 not alpha or beta. Doing a release is much more than slapping a version (tag) on it. It makes the next version usable by other people to do releases because it means we've pushed a non-snapshot to the public. If there are people unaffected by MSHADE-9, then there is still value to those people in having a release now rather than later. I think in general we try to fix too many things at once and end up not getting important fixes out to the people that need them. I'd rather see a release come out with the current fixes and then when MSHADE-9 is fixed, we do another release. At least then some people can use it rather than making everyone wait...and realistically doing the release doesn't preclude someone from fixing the issue in parallel so it shouldn't in theory delay the inevitable release with the MSHADE-9 fix in it. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 9:25 PM To: Maven Developers List Subject: Re: [VOTE] release maven-shade-plugin 1.0-beta-1 Responding out of order, techincal stuff first... Daniel Kulp wrote: > The fact is MSHADE-9 is not something we can fix in maven-shade-plugin. > It's a bug in ASM and isn't fixable until they provide a fix. (unless > someone wants to jump into ASM code. I don't have the time.) I'm not saying MSHADE-9 is easy to fix, but that claim assumes we're using ASM correctly, which seems like a pretty bold assumption to me; ASM is notoriously finicky. If anything's likely to be wrong, it's probably us! > Since they haven't provided a new version into the repos in almost a > year, I'm not going to hold my breath for a fix. Version 3.1 of ASM came out in October. ASM is very much a live project. I'd say it's at least worth trying the latest version of ASM. > IMO, we shouldn't let that hold up moving forward with getting this > plugin in shape for the many people and projects that don't need that > fixed. I agree we should do a release now. But I do think it matters what we call it. > I'd prefer to not get into "version number" arguments as it really just > doesn't matter. I disagree that version numbers don't matter, though it's obviously a seductive argument. (It's just a number, right?) But bugs certainly do matter when they get released (or, at least, we have to behave as if they do or we'll release crappy software). But all we do when we make a "release" is slap a version number/name on something. If version numbers don't matter, then it doesn't matter what bugs we fix before we change version numbers, i.e. it doesn't matter what bugs we fix before we release. Since bugs and releases matter, version numbers matter just as much as that. Of course, if bugs don't matter, then sure, it doesn't matter whether we call our buggy software 1.0 or 2008 Business Edition. ;-) Specifically, if MSHADE-9 doesn't matter at all, well, it's the only "Blocker" bug filed against the shade plugin right now, so I guess we *SHOULD* release 1.0... none of the other bugs matter as much as that one, right? :-) -Dan - 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] release maven-shade-plugin 1.0-beta-1
Responding out of order, techincal stuff first... Daniel Kulp wrote: The fact is MSHADE-9 is not something we can fix in maven-shade-plugin. It's a bug in ASM and isn't fixable until they provide a fix. (unless someone wants to jump into ASM code. I don't have the time.) I'm not saying MSHADE-9 is easy to fix, but that claim assumes we're using ASM correctly, which seems like a pretty bold assumption to me; ASM is notoriously finicky. If anything's likely to be wrong, it's probably us! Since they haven't provided a new version into the repos in almost a year, I'm not going to hold my breath for a fix. Version 3.1 of ASM came out in October. ASM is very much a live project. I'd say it's at least worth trying the latest version of ASM. IMO, we shouldn't let that hold up moving forward with getting this plugin in shape for the many people and projects that don't need that fixed. I agree we should do a release now. But I do think it matters what we call it. I'd prefer to not get into "version number" arguments as it really just doesn't matter. I disagree that version numbers don't matter, though it's obviously a seductive argument. (It's just a number, right?) But bugs certainly do matter when they get released (or, at least, we have to behave as if they do or we'll release crappy software). But all we do when we make a "release" is slap a version number/name on something. If version numbers don't matter, then it doesn't matter what bugs we fix before we change version numbers, i.e. it doesn't matter what bugs we fix before we release. Since bugs and releases matter, version numbers matter just as much as that. Of course, if bugs don't matter, then sure, it doesn't matter whether we call our buggy software 1.0 or 2008 Business Edition. ;-) Specifically, if MSHADE-9 doesn't matter at all, well, it's the only "Blocker" bug filed against the shade plugin right now, so I guess we *SHOULD* release 1.0... none of the other bugs matter as much as that one, right? :-) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] release maven-shade-plugin 1.0-beta-1
+1 get it out and that doesn't stop us from doing another release soon. -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 6:22 PM To: dev@maven.apache.org Subject: Re: [VOTE] release maven-shade-plugin 1.0-beta-1 Well, I'd prefer to not get into "version number" arguments as it really just doesn't matter.Hell, we have plugins (like the release plugin, dependency plugin, etc..) that EVERYONE uses that haven't had a real release and others (like surefire) that never had a "alpha/beta" release, but probably should have. The fact is MSHADE-9 is not something we can fix in maven-shade-plugin. It's a bug in ASM and isn't fixable until they provide a fix. (unless someone wants to jump into ASM code. I don't have the time.) Since they haven't provided a new version into the repos in almost a year, I'm not going to hold my breath for a fix. IMO, we shouldn't let that hold up moving forward with getting this plugin in shape for the many people and projects that don't need that fixed. In it's current form, the plugin works perfectly fine for a large number of use cases. Thus, I say lets get it out. Wether it's call beta-1 or alpha-16 or even 1.0 is relatively irrelevant to me. Anway, that all said, any more PMC votes either way? Dan On Wednesday 16 January 2008, Dan Fabulich wrote: > I approve of the idea of releasing another version of > maven-shade-plugin, but I don't think we should call it non-alpha > until MSHADE-9 is fixed. > > http://jira.codehaus.org/browse/MSHADE-9 > > If this were called 1.0-alpha-16, I'd give it a +1; as it stands, I > have to vote -1 (non-binding). > > -Dan > > Daniel Kulp wrote: > > I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need > > it for some of my projects. I think Geronimo may need it as well. > > > > This fixes a couple issues we'e run into: > > > > ** Bug > >* [MSHADE-11] - Shaded jars are not unjarrable > >* [MSHADE-13] - META-INF/INDEX.LIST files need to be skipped > > ** New Feature > >* [MSHADE-12] - Ability to filter contents of the archives added > > to the shaded jar > > > > Release notes: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13921&style > >Name=Text&projectId=11540&Create=Create > > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugi > >n-1.0-beta-1/ > > > > Staged at: > > http://people.apache.org/~dkulp/stage_shade/ > > > > > > The vote will be open for 72 hours. > > > > Here is my +1 > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > > >- 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] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - 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] release maven-shade-plugin 1.0-beta-1
dkulp wrote: > > I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need it > for some of my projects. I think Geronimo may need it as well. > OpenEJB, actually. And here's my +1! (non-binding) -David -- View this message in context: http://www.nabble.com/-VOTE--release-maven-shade-plugin-1.0-beta-1-tp14892803s177p14942018.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
Well, I'd prefer to not get into "version number" arguments as it really just doesn't matter.Hell, we have plugins (like the release plugin, dependency plugin, etc..) that EVERYONE uses that haven't had a real release and others (like surefire) that never had a "alpha/beta" release, but probably should have. The fact is MSHADE-9 is not something we can fix in maven-shade-plugin. It's a bug in ASM and isn't fixable until they provide a fix. (unless someone wants to jump into ASM code. I don't have the time.) Since they haven't provided a new version into the repos in almost a year, I'm not going to hold my breath for a fix. IMO, we shouldn't let that hold up moving forward with getting this plugin in shape for the many people and projects that don't need that fixed. In it's current form, the plugin works perfectly fine for a large number of use cases. Thus, I say lets get it out. Wether it's call beta-1 or alpha-16 or even 1.0 is relatively irrelevant to me. Anway, that all said, any more PMC votes either way? Dan On Wednesday 16 January 2008, Dan Fabulich wrote: > I approve of the idea of releasing another version of > maven-shade-plugin, but I don't think we should call it non-alpha > until MSHADE-9 is fixed. > > http://jira.codehaus.org/browse/MSHADE-9 > > If this were called 1.0-alpha-16, I'd give it a +1; as it stands, I > have to vote -1 (non-binding). > > -Dan > > Daniel Kulp wrote: > > I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need > > it for some of my projects. I think Geronimo may need it as well. > > > > This fixes a couple issues we'e run into: > > > > ** Bug > >* [MSHADE-11] - Shaded jars are not unjarrable > >* [MSHADE-13] - META-INF/INDEX.LIST files need to be skipped > > ** New Feature > >* [MSHADE-12] - Ability to filter contents of the archives added > > to the shaded jar > > > > Release notes: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13921&style > >Name=Text&projectId=11540&Create=Create > > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugi > >n-1.0-beta-1/ > > > > Staged at: > > http://people.apache.org/~dkulp/stage_shade/ > > > > > > The vote will be open for 72 hours. > > > > Here is my +1 > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > > >- 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] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM Element for Source File Encoding
Please put it on the user proposal page on the wiki so we don't lose it. Done: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Ciao! Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: POM Element for Source File Encoding
This seems logical to me. Please put it on the user proposal page on the
wiki so we don't lose it.
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 2:30 PM
To: Maven Developers List
Subject: POM Element for Source File Encoding
Dear Developers,
a couple of plugins processes the contents of source files, e.g.
maven-resources-plugin, maven-compiler-plugin, maven-javadoc-plugin and
taglist-maven-plugin to name just a few. Unlike XML files, Java source
files
have no intrinsic means of determining the required character encoding.
Therefore, the plugins must be manually configured with the correct
character encoding in order to properly convert the byte contents of the
source files into characters.
Currently, each plugin must be configured individually. That is, the POM
contains duplicated configuration settings. Surely, one could move the
encoding into a property and use this for the plugin configuration but
this
does not feel say POM-like. The POM is not a silly Ant build file but a
data
structure to describe a project, right? My project uses XYZ as source
file
encoding. Wouldn't it be nice to state this once and not repeat it for
every
plugin hanging around? One already states once where the source files
are
located, so why not follow the same approach for their character
encoding?
Therefore, I would like to request the introduction of another POM
element
in Maven 2.1 or later to address the issue of source file encoding in a
central place. For example, Maven might add ${project.sourceEncoding}
that
would be defaulted in the Super POM to say ISO-8859-1 or UTF-8.
Plugins can and should continue to provide their own configuration
parameter
to specify the character encoding but their internals could be changed
to
something like
/*
* @parameter expression="${project.sourceEncoding}"
*/
private String encoding;
in order to start-off with the centrally provided POM setting.
Left to discussion is whether a single new POM element is sufficient or
whether there should be individual encoding elements for the different
kinds
of source files, e.g. one for Java source files, one for resources, one
for
scripts etc.
Regards,
Benjamin Bentmann
-
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: Common Bugs
Greetings,
I remember another subtle issue which I would like to make people aware of.
3) Case-Insensitive String Comparison
When developers need to compare strings without regard to case or want to
realize a map with case-insensitive string keys, they often employ
String.toLowerCase() or String.toUpperCase() to create a "normalized" string
before doing a simple String.equals(). Now, the to*Case() methods are
overloaded: One takes no arguments and one take a Locale object.
The gotcha with the arg-less methods is that their output depends on the
default locale of the JVM but the default locale is out of control of the
developer (see also [0], [1]). That means the string expected by the
developer (who runs/tests his code in a JVM using locale xy) does not
necessarily match the string seen by another user (that runs a JVM with
locale ab). For example, the comparison
"info".equals(debugLevel.toLowerCase())
is likely to fail for systems with default locale Turkish.
Since developers usually want to compare strings from the English language,
they must use String.to*Case(Locale.ENGLISH) to get reliable results
regardless of the end-user's default locale.
Just to make the picture complete: String.to*Case() is locale-sensitive and
context-aware. In contrast, Character.to*Case() and
String.equalsIgnoreCase() (which relies on Character.to*Case()) are neither
locale-sensitive nor context-aware [2]. For instance
"ΣΣ".toLowerCase(Locale.ENGLISH).equals("σσ")
is false while
"ΣΣ".equalsIgnoreCase("σσ")
is true (because the lower case form of "ΣΣ" is "σς").
Regards,
Benjamin Bentmann
[0]
http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()
[1] http://cafe.elharo.com/blogroll/turkish/
[2]
http://java.sun.com/javase/6/docs/api/java/lang/Character.html#toLowerCase(char)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
POM Element for Source File Encoding
Dear Developers,
a couple of plugins processes the contents of source files, e.g.
maven-resources-plugin, maven-compiler-plugin, maven-javadoc-plugin and
taglist-maven-plugin to name just a few. Unlike XML files, Java source files
have no intrinsic means of determining the required character encoding.
Therefore, the plugins must be manually configured with the correct
character encoding in order to properly convert the byte contents of the
source files into characters.
Currently, each plugin must be configured individually. That is, the POM
contains duplicated configuration settings. Surely, one could move the
encoding into a property and use this for the plugin configuration but this
does not feel say POM-like. The POM is not a silly Ant build file but a data
structure to describe a project, right? My project uses XYZ as source file
encoding. Wouldn't it be nice to state this once and not repeat it for every
plugin hanging around? One already states once where the source files are
located, so why not follow the same approach for their character encoding?
Therefore, I would like to request the introduction of another POM element
in Maven 2.1 or later to address the issue of source file encoding in a
central place. For example, Maven might add ${project.sourceEncoding} that
would be defaulted in the Super POM to say ISO-8859-1 or UTF-8.
Plugins can and should continue to provide their own configuration parameter
to specify the character encoding but their internals could be changed to
something like
/*
* @parameter expression="${project.sourceEncoding}"
*/
private String encoding;
in order to start-off with the centrally provided POM setting.
Left to discussion is whether a single new POM element is sufficient or
whether there should be individual encoding elements for the different kinds
of source files, e.g. one for Java source files, one for resources, one for
scripts etc.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin repositories (was: svn commit: r609772)
I gave this some thought. I definitely agree the separation is bad. The flags are useful, though maybe doing this by group/artifactId is more effective (since this has been requested for dependencies in general). But on the implementation side - regardless of whether you add this flag you either need to version the behaviour (not just the syntax) or document a backwards compatibility issue. I would say the latter is ok, and just pull in any elements into the main repositories and warn the user the behaviour might have changed. Cheers, Brett On 09/01/2008, at 11:21 PM, John Casey wrote: After talking this over some more with Brian Fox, I'm convinced that this approach of segregating plugin and project repositories will result in a large amount of duplication of effort for ~90% of projects, since so many project-dependency repositories also host plugins. This is especially true as the community migrates to a more general use of proxies. So, this would tend to support my original changes, where all artifacts are drawn from the list, even for plugin resolution. To keep Maven from resolving snapshot versions of plugins in this new setup, it would be great if we could add two new flags to the repository syntax: - dependencies (true|false) - plugins (true|false) These flags would combine with the existing settings for releases and snapshots, and allow fine-grained control over what a specific repository is used for. They also line up very nicely with the types of information typically stored in real repositories, where for instance you'd probably never see snapshots of project dependencies living alongside releases of plugins in the same repository...which would be one case where the new flags would require two separate repository entries pointing at the same URL. Again, we can't really put these new flags in place until we have a means of accommodating new modelVersion numbers in the POM...which requires a refactoring of the DefaultMavenProjectBuilder at a minimum. Brett, what do you think about this approach to flagging repositories instead of putting them in two lists? -john On Jan 8, 2008, at 10:21 AM, John Casey wrote: Well, I thought the discussion was over IRC, but searching the last year and a half, I'm at a loss. The original reasoning here was to clean up the usage of repositories in 2.1, and since there is no end to problems with pluginRepositories when people actually use them, this seemed like a good target. We had some discussion about disabling plugin auto- resolution when the version is missing on the dev list, but we didn't reach any sort of consensus there, except to say that not specifying versions is dangerous, I think. It would be good to drive that discussion to some resolution, and figure out how we can pin down plugin versions for everything used in a given build (even in default lifecycle bindings and such) in a scalable and effective way. However, this will almost certainly require changes to the project builder, since putting plugin-version information in released versions of maven itself is very bad, and there is currently no way to specify plugin versions for the default lifecycle bindings except through the pluginManagement section of a parent pom or similar. In any case, plugin repositories are mixed up with regular repositories during the plugin resolution process. At one point, I had written code to resolve only the plugin artifact itself using only the pluginRepositories list, then take another pass to resolve the plugin dependencies using the mixture of these two lists. That's gone now (I'm not entirely sure where it went, or when), and in any case it wouldn't have produced results that were easy to debug, I'm guessing. Aligning all artifact resolution to a consistent set of repositories seemed a good first step down the path of cleaning all of this up. However, I'm now starting to wonder whether we want to completely segregate the build activities - including the artifact repositories used to drive these activities - from the project dependencies. To me, it seems a better practice to take a lesson from plugin-level dependencies, which are kept separate from regular project dependencies because they are used in the build process and not at all in project code, and completely separate the two repository lists. Plugins and their dependencies would only be resolved from , and project dependencies would only be resolved from . This will prevent any unintentional injection of snapshots into the mix when resolving plugin versions (which, again, is a bad feature to be reliant upon...as evidenced by our repeated failure to control when plugins are re-resolved...see pluginRegistry and advice on using -U for plugin resolution for some examples). So, let's have the discussion now. What does anyone think about separating the pluginRepo
