Re: POM5 proposal
Hi Benson! Txs for pushing that, looks really good!. As for compat: I read your proposal this way: pom5 projects can only be built with mvn3.1 or mvn4 (or whatever we call it) but while installing/deploying, a pom-4.0 will be created which can be _consumed_ as dependencies even by mvn2 and/or mvn3, right? As for the repo managers: *) distributionManagement repos should work with pom5. I think we can assume that Archiva and Nexus will support that. It's really not too much a problem. *) proxy Repos for mvn2/mvn3 will at least see and proxy the pom-4.0.0. So anyone behind a closed company firewall is still able to build in compat mode. Maybe he is not able to build the latest and greatest pom5 project, but thats not our fault then. LieGrue, strub --- On Wed, 7/27/11, Vincent Siveton vsive...@apache.org wrote: From: Vincent Siveton vsive...@apache.org Subject: Re: POM5 proposal To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 5:16 AM Hi Benson Thanks for your proposal! IMHO the pom5 should include some tags like wiki/ or qualityManagement/ and the javadoc api/ see MPIR-149 MJAVADOC-32 Cheers, Vincent 2011/7/24 Benson Margulies bimargul...@gmail.com: Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1150994 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
I won't fight about it but I dislike the idea of providing web links in
error messages. In a few years from now they might not exist any more or
provide irrelevant information. A stack trace is not pretty but google
doesn't mind that. At least log the stack trace at debug level if you
prefer.
-Lukas
On 07/27/2011 12:15 AM, Hervé BOUTEMY wrote:
did you try what an end-user can see when he tries to use an unavailable
protocol?
I'm ok with more detailed error message.
But the stacktrace, which is the only message which is displayed at the end of
Maven reactor run, stating that protocol could not be found, is not helpful:
the detailed error message is more expressive IMHO, telling the user where to
find information on how to fix.
Regards,
Hervé
Le mardi 26 juillet 2011, ltheu...@apache.org a écrit :
Author: ltheussl
Date: Tue Jul 26 06:42:00 2011
New Revision: 1150994
URL: http://svn.apache.org/viewvc?rev=1150994view=rev
Log:
move detailed error message to logger and preserve stacktrace
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/mai
n/java/org/apache/maven/plugins/site/AbstractDeployMojo.java?rev=1150994r1
=1150993r2=1150994view=diff
==
---
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java (original) +++
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugi
ns/site/AbstractDeployMojo.java Tue Jul 26 06:42:00 2011 @@ -343,7 +343,7
@@ public abstract class AbstractDeployMojo
return buildDirectory;
}
-private Wagon getWagon( final Repository repository, final
WagonManager manager, final Log log ) +private static Wagon getWagon(
final Repository repository, final WagonManager manager, final Log log )
throws MojoExecutionException
{
final Wagon wagon;
@@ -354,13 +354,12 @@ public abstract class AbstractDeployMojo
}
catch ( UnsupportedProtocolException e )
{
-log.error( Unavailable protocol for site deployment: ' +
repository.getProtocol() + ' ); +log.error( Unsupported
protocol for site deployment: ' + repository.getProtocol() +
+ '. For adding new protocols to the site plugin, see +
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-
protocol.html );
-throw new MojoExecutionException(
- this,
- Unavailable protocol for
site deployment: ' + repository.getProtocol() + ', -
To add a new protocol to site plugin, see -
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-
protocol.html ); +throw new MojoExecutionException(
Unsupported protocol for site deployment: ' ++
repository.getProtocol() + '., e );
}
catch ( TransferFailedException e )
{
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 proposal
Thx for your work Benson I'll read and comment your document ASAP About new elements we already discussed to add there was the project/build/encoding It may me think that we need to define about the compatibility management we'll have to setup for plugins For now we can say that a plugin works only for a minimum version of Maven but tomorrow we'll may have a constraint about the POM version for example if it requires a new data supported only by a new pom. I suppose we'll always try to propose if possible to keep the the compat with v4 for example by testing to read project/build/encoding first and then the property project.build.encoding but it will also add a lot of complexity/redundancy in plugins thus they may have to decide one day to not support old POMs Arnaud On Wed, Jul 27, 2011 at 7:16 AM, Vincent Siveton vsive...@apache.orgwrote: Hi Benson Thanks for your proposal! IMHO the pom5 should include some tags like wiki/ or qualityManagement/ and the javadoc api/ see MPIR-149 MJAVADOC-32 Cheers, Vincent 2011/7/24 Benson Margulies bimargul...@gmail.com: Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 proposal
Nice work. I somehow think that the starting point for this disucssion should be the intended functionality of such a change; so I'd like to start the discussion with the use cases. One very simple use case which I personally would appreciate is more compact pom format; less bloat. I could see us supporting a simple 4.1 format that is bidirectionally mappable between 4.0 and 4.1, and the mapping could happen both in a maven 3.1 and/or a repository manager. I somehow think just determining what would be necessary for such a feature would be a nice start; I'm quite sure a lot of our users would love a leaner pom format. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 proposal
Folks, A general theme of these comments is, 'and what are we going to put in our new pom version?' I didn't go there in my writeup, since I was concerned with the mechanics of 'how do we have a new POM *at all*'. But I see the point; we can't make a new pom model every week, so we need to combine a substantial list of proposed enhancements. Perhaps other could add more wiki content to start this? When I think about this, I find myself wishing that we could invent a middle ground between 'no changes at all' and 'a new major version.' In the same way that individual plugins can add new configuration/ elements any time, I'd like to enhance my overall proposal to include a section on 'future-proofing' the next schema rev by adding a few judicious xs:any/ specifications and documenting some conventions for their use. In other words, as of 'pom5', any tool that reads a POM should be prepared to gracefully ignore things it doesn't expect in some specified areas of the schema. How broad should this be? I'd also like to specify that all parsers should be namespace-aware, so that third-parties can define their own POM additions via namespaces. FInally, for today, does anyone have any sympathy for focussing on RNG schema instead of W3C? On Wed, Jul 27, 2011 at 7:28 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Nice work. I somehow think that the starting point for this disucssion should be the intended functionality of such a change; so I'd like to start the discussion with the use cases. One very simple use case which I personally would appreciate is more compact pom format; less bloat. I could see us supporting a simple 4.1 format that is bidirectionally mappable between 4.0 and 4.1, and the mapping could happen both in a maven 3.1 and/or a repository manager. I somehow think just determining what would be necessary for such a feature would be a nice start; I'm quite sure a lot of our users would love a leaner pom format. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven eclipse plugin
Hey guys, I really don't have problem with lack of commit access to maven repository. I know how ASF work and I don't expect write access to your repository at early stage of cooperation. :) I can do patches on my github fork and let you cherry-picking changes instead of merging them from svn branch. It will be easier for both sides. Best regards, Lukasz -- View this message in context: http://maven.40175.n5.nabble.com/Maven-eclipse-plugin-tp4634689p4638590.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Apache Maven distribution with fixes
Maven PMC, Benjamin and I would like to make a distribution available that addresses several issues with the Apache Maven 3.0.3 release. We have pushed back all bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their incorporation into the mainline and an official release is your decision. We haven't pushed any individual artifacts to Maven Central as part of creating the distribution, we have only created the distribution itself. If there is anything you want changed let us know and we'll change it, but we wanted to make these fixes available in a build for users who are having problems. We're not trying to represent it as anything other then a distribution that incorporates fixes users need. The build is available here: http://people.apache.org/~jvanzyl Summary of the issues Fixes pushed back to the ASF: [MNG-5064][1] mvn -nsu (--no-snapshot-updates) should not download snapshots (and break local builds) [MNG-5131][2] Wrong encoding for encrypted passwords [MNG-5113][3] NullPointerException on javadoc site generation [MNG-5137][4] Reactor resolution does not work for forked multi module builds [MNG-5096][5] exclusion on dependency with typetest-jar/type doesn't work in maven 3 [MNG-5135][6] Regression: in some cases aggregator mojo is unable to resolve dependencies with custom packaging Fixes not pushed back to the ASF as these are dependent on fixes in Eclipse Aether and Eclipse Sisu: [MNG-5042][7] Regression: CloningClassLoader causes StackOverflowError in groovy [MNG-5056][8] Test dependencies get packaged into WAR file. [MNG-5084][9] Resolver for plugins failing [MNG-5087][10] Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted [MNG-5125] [11]Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies [MNG-5138][12] Dependency conflicts are extremely opaque [1]: http://jira.codehaus.org/browse/MNG-5064 [2]: http://jira.codehaus.org/browse/MNG-5131 [3]: http://jira.codehaus.org/browse/MNG-5113 [4]: http://jira.codehaus.org/browse/MNG-5137 [5]: http://jira.codehaus.org/browse/MNG-5096 [6]: http://jira.codehaus.org/browse/MNG-5135 [7]: http://jira.codehaus.org/browse/MNG-5042 [8]: http://jira.codehaus.org/browse/MNG-5056 [9]: http://jira.codehaus.org/browse/MNG-5084 [10]: http://jira.codehaus.org/browse/MNG-5087 [11]: http://jira.codehaus.org/browse/MNG-5125 [12]: http://jira.codehaus.org/browse/MNG-5138 [a]: http://eclipse.org/proposals/technology.aether/ [b]: http://eclipse.org/proposals/technology.sisu/ Thanks, Jason -- Jason van Zyl Eclipse Board Member Founder, Apache Maven http://twitter.com/jvanzyl - If I find ten thousand ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is just one more step forward. -- Thomas Edison
Re: POM5 proposal
Vincent that seems like a mistake. Why add more specific elements like Wiki and API. Why make the POM syntax this specific. Why not make it free from, something like: resource type=wiki url!--- some Wiki URL --/url /resource Which you could compact down in some groovy syntax to something like wiki:url I see a lot of people using Maven for projects other than open source Java (or even projects that involve code). I'd like to see the next version of the POM move toward being something more agnostic. On Wed, Jul 27, 2011 at 12:16 AM, Vincent Siveton vsive...@apache.orgwrote: Hi Benson Thanks for your proposal! IMHO the pom5 should include some tags like wiki/ or qualityManagement/ and the javadoc api/ see MPIR-149 MJAVADOC-32 Cheers, Vincent 2011/7/24 Benson Margulies bimargul...@gmail.com: Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Wed, Jul 27, 2011 at 10:05 PM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 27.07.2011 08:16, schrieb Kasun Gajasinghe: We don't allow downloading of different versions of same plugin which in most cases does the 'same' job! So, we need the ability to set a default plugin versions that are available on the gentoo system. Hi Kasun, what about this: configure a local pluginRepository in Maven's global settings.xml [1] file. Pre-load it with all the plugins and plugin dependencies your maven installation will be allowed to use. Ansgar, well, this is possible, I'm working on some subtle gentoo-specific things I need to do first to test this out. Anyway, I already know this, and have specified about this in my original post. I'm looking for this and something beyond that. That is, set checkLatest true and retrieve plugins version from there. [2] says, checkLatest - Specifies whether the LATEST artifact metadata should be consulted while determining versions for unregistered plugins. I'm looking for that. I figured that it needs to set via maven-metadata.xml files. I'm not exactly sure that maven-metadata.xml is the file to be used for this purpose though. [2] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html Best Ansgar [1] http://maven.apache.org/settings.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 proposal
On Wed, Jul 27, 2011 at 7:45 PM, Tim O'Brien tobr...@discursive.com wrote: Vincent that seems like a mistake. Why add more specific elements like Wiki and API. Why make the POM syntax this specific. Why not make it free from, something like: resource type=wiki url!--- some Wiki URL --/url /resource Which you could compact down in some groovy syntax to something like wiki:url I see a lot of people using Maven for projects other than open source Java (or even projects that involve code). I'd like to see the next version of the POM move toward being something more agnostic. +1 On Wed, Jul 27, 2011 at 12:16 AM, Vincent Siveton vsive...@apache.org wrote: Hi Benson Thanks for your proposal! IMHO the pom5 should include some tags like wiki/ or qualityManagement/ and the javadoc api/ see MPIR-149 MJAVADOC-32 Cheers, Vincent 2011/7/24 Benson Margulies bimargul...@gmail.com: Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
[VOTE] Incorporate EPL Ether in Maven Releases
As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
as long as it's not over at Eclipse.org it's a -1 from me. LieGrue, strub --- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 6:45 PM As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 I can wait too. Kristian Den 27. juli 2011 kl. 20:55 skrev Mark Struberg strub...@yahoo.de: as long as it's not over at Eclipse.org it's a -1 from me. LieGrue, strub --- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 6:45 PM As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
There are 3 weeks left for community review, another week for the creation review, and another for the provisioning. So it's 5 weeks tops. http://eclipse.org/proposals/technology.aether/ On Jul 27, 2011, at 2:58 PM, Kristian Rosenvold wrote: -1 I can wait too. Kristian Den 27. juli 2011 kl. 20:55 skrev Mark Struberg strub...@yahoo.de: as long as it's not over at Eclipse.org it's a -1 from me. LieGrue, strub --- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 6:45 PM As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 Definitely not until it's all the way moved to Eclipse...and even then, I'm personally reluctant. I'd much prefer to see Aether's functionality moved back into Maven, and streamlined to the point where it's easier to maintain. On 7/27/11 2:45 PM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Mon, Jul 25, 2011 at 9:30 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich dbradic...@sonatype.com wrote: err...pluginManagement section even ;) Damian On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich dbradic...@sonatype.comwrote: Why not define the pluginDependency section in a parent pom, then each of your projects uses this as a parent, and pulls in all the plugin dep versions defined in it (or overrides in project pom if necessary). Seems that would be simplest solution Since these projects are unrelated, they can't be glued together via a parent pom. I don't see why not. Consider the following example: http://img.skitch.com/20110727-b3j3j8fk2rg4s2h9exm225skyd.png You just need to have a hierarchy of parent poms. Sure, if you update the top Corporate Super-Pom, you will then need to update the other parent poms that depend on that pom, but this way you can share only the most common stuff, such as plugin versions and generic configurations in the corporate super pom, and then in each of the other parent poms, you get more specific. -- Larry - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1150994 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractDeployMojo.java
Le mercredi 27 juillet 2011, Lukas Theussl a écrit :
I won't fight about it
sure, we won't fight :)
but I dislike the idea of providing web links in
error messages. In a few years from now they might not exist any more or
provide irrelevant information.
ok, I understand: I have idea on how to improve the log to have sufficient info
at first, and the link will only be useful for people needing more verbose
explanations
A stack trace is not pretty but google
doesn't mind that. At least log the stack trace at debug level if you
prefer.
I don't like the original stacktrace where it is: I'll add stacktrace when
listing available providers, it should be equivalent with what you're looking
for in case of the protocol is here but could not be fully loaded, but more
user friendly in expected case where the protocol is not here
please have a look at my next commits and see if it is ok
Regards,
Hervé
-Lukas
On 07/27/2011 12:15 AM, Hervé BOUTEMY wrote:
did you try what an end-user can see when he tries to use an unavailable
protocol?
I'm ok with more detailed error message.
But the stacktrace, which is the only message which is displayed at the
end of Maven reactor run, stating that protocol could not be found, is
not helpful: the detailed error message is more expressive IMHO, telling
the user where to find information on how to fix.
Regards,
Hervé
Le mardi 26 juillet 2011, ltheu...@apache.org a écrit :
Author: ltheussl
Date: Tue Jul 26 06:42:00 2011
New Revision: 1150994
URL: http://svn.apache.org/viewvc?rev=1150994view=rev
Log:
move detailed error message to logger and preserve stacktrace
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plu
gi ns/site/AbstractDeployMojo.java
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plu
gi ns/site/AbstractDeployMojo.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/m
ai
n/java/org/apache/maven/plugins/site/AbstractDeployMojo.java?rev=115099
4r1 =1150993r2=1150994view=diff
== ---
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plu
gi ns/site/AbstractDeployMojo.java (original) +++
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plu
gi ns/site/AbstractDeployMojo.java Tue Jul 26 06:42:00 2011 @@ -343,7
+343,7 @@ public abstract class AbstractDeployMojo
return buildDirectory;
}
-private Wagon getWagon( final Repository repository, final
WagonManager manager, final Log log ) +private static Wagon
getWagon( final Repository repository, final WagonManager manager,
final Log log ) throws MojoExecutionException
{
final Wagon wagon;
@@ -354,13 +354,12 @@ public abstract class AbstractDeployMojo
}
catch ( UnsupportedProtocolException e )
{
-log.error( Unavailable protocol for site deployment: ' +
repository.getProtocol() + ' ); +log.error( Unsupported
protocol for site deployment: ' + repository.getProtocol() +
+ '. For adding new protocols to the site plugin, see +
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deplo
y- protocol.html );
-throw new MojoExecutionException(
- this,
- Unavailable protocol for
site deployment: ' + repository.getProtocol() + ', -
To add a new protocol to site plugin, see
-
+
http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deplo
y- protocol.html ); +throw new MojoExecutionException(
Unsupported protocol for site deployment: ' ++
repository.getProtocol() + '., e );
}
catch ( TransferFailedException e )
{
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 for the same reasons. On Wednesday, July 27, 2011, John Casey jdca...@commonjava.org wrote: -1 Definitely not until it's all the way moved to Eclipse...and even then, I'm personally reluctant. I'd much prefer to see Aether's functionality moved back into Maven, and streamlined to the point where it's easier to maintain. On 7/27/11 2:45 PM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
Yea, that sounds good! Thanks for the update! LieGrue, strub --- On Wed, 7/27/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 7:03 PM There are 3 weeks left for community review, another week for the creation review, and another for the provisioning. So it's 5 weeks tops. http://eclipse.org/proposals/technology.aether/ On Jul 27, 2011, at 2:58 PM, Kristian Rosenvold wrote: -1 I can wait too. Kristian Den 27. juli 2011 kl. 20:55 skrev Mark Struberg strub...@yahoo.de: as long as it's not over at Eclipse.org it's a -1 from me. LieGrue, strub --- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 6:45 PM As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 for same reasons, but I'd be happy to switch to a +1 if the license was changed back to dual Eclipse/Apache AND it gets to Eclipse. Dan On Wednesday, July 27, 2011 3:04:42 PM John Casey wrote: -1 Definitely not until it's all the way moved to Eclipse...and even then, I'm personally reluctant. I'd much prefer to see Aether's functionality moved back into Maven, and streamlined to the point where it's easier to maintain. On 7/27/11 2:45 PM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
just for the record, -1 too waiting for Eclipse release, which is coming soon: great! Regards, Hervé Le mercredi 27 juillet 2011, Benson Margulies a écrit : As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM5 proposal
Le mercredi 27 juillet 2011, Tim O'Brien a écrit : Vincent that seems like a mistake. Why add more specific elements like Wiki and API. Why make the POM syntax this specific. Why not make it free from, something like: resource type=wiki url!--- some Wiki URL --/url /resource Which you could compact down in some groovy syntax to something like wiki:url I see a lot of people using Maven for projects other than open source Java (or even projects that involve code). I'd like to see the next version of the POM move toward being something more agnostic. great to hear: please help explaining what is needed to better do this, and who examples we, as Maven developpers, are naturally not java agnostic at all: being java agnostic will require some imagination ;) Regards, Hervé On Wed, Jul 27, 2011 at 12:16 AM, Vincent Siveton vsive...@apache.orgwrote: Hi Benson Thanks for your proposal! IMHO the pom5 should include some tags like wiki/ or qualityManagement/ and the javadoc api/ see MPIR-149 MJAVADOC-32 Cheers, Vincent 2011/7/24 Benson Margulies bimargul...@gmail.com: Since I can't edit the Wiki, I created: https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVj d3oUto/edit?hl=en_US - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-1 too and same reasons. -- Olivier Le 27 juil. 2011 21:05, John Casey jdca...@commonjava.org a écrit : -1 Definitely not until it's all the way moved to Eclipse...and even then, I'm personally reluctant. I'd much prefer to see Aether's functionality moved back into Maven, and streamlined to the point where it's easier to maintain. On 7/27/11 2:45 PM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
As long as 1.12+ of Aether makes it into the 3.0.4 release: +1 NON Binding Without it Maven quite easily gets seriously broken :( On 28/07/2011, at 6:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
Without it Maven quite easily gets seriously broken :( Thats exactly the reason. Do you like to have the Apache Maven project depending on a part which you have no control over? Which might change in a way which just doesn't fit for Maven? Remember: all this used to be just a part of maven-core in v2... LieGrue, strub --- On Wed, 7/27/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Wednesday, July 27, 2011, 8:32 PM As long as 1.12+ of Aether makes it into the 3.0.4 release: +1 NON Binding Without it Maven quite easily gets seriously broken :( On 28/07/2011, at 6:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
On Jul 27, 2011, at 4:32 PM, Mark Derricutt wrote: As long as 1.12+ of Aether makes it into the 3.0.4 release: +1 NON Binding What I would consider to be the fix set for 3.0.4 is here: http://people.apache.org/~jvanzyl/ Benjamin and I will continue to support these builds and push back any fixes we can into the ASF. Without it Maven quite easily gets seriously broken :( On 28/07/2011, at 6:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: [VOTE] Incorporate EPL Ether in Maven Releases
A point of process. If this vote goes negative, I'll just throw another one when the code is live at Eclipse.org. To Dan's point: I posted an analysis to the effect that the dual-license has no benefit to us, and no one offered any counter-argument. Perhaps Dan or someone else would care to offer an alternative analysis on the DISCUSS thread? On Wed, Jul 27, 2011 at 4:51 PM, Jason van Zyl ja...@sonatype.com wrote: On Jul 27, 2011, at 4:32 PM, Mark Derricutt wrote: As long as 1.12+ of Aether makes it into the 3.0.4 release: +1 NON Binding What I would consider to be the fix set for 3.0.4 is here: http://people.apache.org/~jvanzyl/ Benjamin and I will continue to support these builds and push back any fixes we can into the ASF. Without it Maven quite easily gets seriously broken :( On 28/07/2011, at 6:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
And was just as broken in 2.2.x with the exact same problem from what I've been told by Richard who diagnosed and raised the JIRA ticket. On 28/07/2011, at 8:46 AM, Mark Struberg wrote: Remember: all this used to be just a part of maven-core in v2...
Re: [VOTE] Incorporate EPL Ether in Maven Releases
Also .. from what I understand Maven and core plugins depend on a whole bunch of other libraries that are not in Maven and/or not in Apache so as long as there is license compatibilitys I am sure the Maven devs can work with upstream projects like Aether just like others like commons* or whatever else. manfred Maven dependsOn Wed, July 27, 2011 2:33 pm, Mark Derricutt wrote: And was just as broken in 2.2.x with the exact same problem from what I've been told by Richard who diagnosed and raised the JIRA ticket. On 28/07/2011, at 8:46 AM, Mark Struberg wrote: Remember: all this used to be just a part of maven-core in v2... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1150948 - in /maven/plugins/trunk/maven-site-plugin: pom.xml src/it/full-reporting/pom.xml src/it/full-reporting/verify.groovy src/main/java/org/apache/maven/plugins/site/AbstractSite
I found the culprit: MNG-5140 and the impact is reduced: only reports in a reportSet are affected Given this, I think it is safe to keep the fix Regards, Hervé Le mercredi 27 juillet 2011, Hervé BOUTEMY a écrit : I still need to investigate what's happenning with m-site-p 2.3 and Maven 2.2 yes, it's better to have same behaviour with every Maven version I'll work on it tomorrow Regards, Hervé Le mercredi 27 juillet 2011, Dennis Lundberg a écrit : Hervé, Do you have an idea how to fix this for Maven 2? If you don't, then I'd like to postpone this change to a time when we have a solution for Maven 2. I feel that it is better (and easier) if this version of the plugin behaves the same (as much as possible) when it is run with Maven 2 and Maven 3. On 2011-07-26 00:57, hbout...@apache.org wrote: Author: hboutemy Date: Mon Jul 25 22:57:29 2011 New Revision: 1150948 URL: http://svn.apache.org/viewvc?rev=1150948view=rev Log: [MSITE-402] ensure order of reports like defined in POM (works with Maven 3 but not with Maven 2.2 for the moment) Modified: maven/plugins/trunk/maven-site-plugin/pom.xml maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/pom.xml maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/verify. gr oovy maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/mave n /plugins/site/AbstractSiteRenderingMojo.java Modified: maven/plugins/trunk/maven-site-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/pom. x ml?rev=1150948r1=1150947r2=1150948view=diff === = == --- maven/plugins/trunk/maven-site-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-site-plugin/pom.xml Mon Jul 25 22:57:29 2011 @@ -205,7 +205,7 @@ under the License. dependency groupIdorg.apache.maven.reporting/groupId artifactIdmaven-reporting-exec/artifactId - version1.0/version + version1.0.1-SNAPSHOT/version /dependency !-- Maven -- Modified: maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src /i t/full-reporting/pom.xml?rev=1150948r1=1150947r2=1150948view=diff == == == --- maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/pom.xml (original) +++ maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/pom.xml Mon Jul 25 22:57:29 2011 @@ -65,6 +65,23 @@ dependencyDetailsEnabledfalse/dependencyDetailsEnabled dependencyLocationsEnabledfalse/dependencyLocationsEnable d /configuration +reportSets + reportSet +reports + reportindex/report + reportsummary/report + reportlicense/report + reportproject-team/report + reportscm/report + reportissue-tracking/report + reportmailing-list/report + reportdependencies/report + reportcim/report + reportplugin-management/report + reportplugins/report +/reports + /reportSet +/reportSets /plugin plugin groupIdorg.apache.maven.plugins/groupId Modified: maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/verify.groo v y URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/ i t/full-reporting/verify.groovy?rev=1150948r1=1150947r2=1150948view= dif f === = == --- maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/verify.groo v y (original) +++ maven/plugins/trunk/maven-site-plugin/src/it/full-reporting/verify.groo v y Mon Jul 25 22:57:29 2011 @@ -25,21 +25,71 @@ assert content.contains( 'Test set: org. assert content.contains( 'Tests run: 1, Failures: 0, Errors: 0, Skipped: 0' ); -assert new File( basedir, 'target/site/surefire-report.html' ).exists(); -assert new File( basedir, 'target/site/index.html' ).exists(); -assert new File( basedir, 'target/site/checkstyle.html' ).exists(); -assert new File( basedir, 'target/site/cpd.html' ).exists(); -assert new File( basedir, 'target/site/apidocs/index.html' ).exists(); -assert new File( basedir, 'target/site/apidocs/org/apache/maven/plugins/site/its/App.html' ).exists(); -assert new File( basedir, 'target/site/cobertura/index.html' ).exists(); -assert new File( basedir, 'target/site/xref/index.html' ).exists(); -assert
Re: [VOTE] Incorporate EPL Ether in Maven Releases
On Thu, Jul 28, 2011 at 7:34 AM, Manfred Moser manf...@mosabuam.com wrote: Also .. from what I understand Maven and core plugins depend on a whole bunch of other libraries that are not in Maven and/or not in Apache so as long as there is license compatibilitys I am sure the Maven devs can work with upstream projects like Aether just like others like commons* or whatever else. Repeat this over at the discuss thread (it doesn't belong here). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 2/3 and Cobetura plugin with both TestNG and JUnit tests (with Surefire plugin configuration)
I did send this to the users list, but got no response in over a week. I know dev lists are not a magical escalation path, but this might be a better venue for this email. I have an example project at https://gist.github.com/1090223 This project has both a JUnit test and a TestNG test. Following some instructions online to get surefire be able to run both I added lines 19-45 in the pom. This works fine when running mvn test, except it runs the TestNG tests twice. I can fix that by commenting out lines 34-43. Now when I run mvn cobertura:cobertura, this is where things get weird. In Maven 2.2.1, it runs both TestNG and JUnit just fine, and produces the correct coverage. Now in Maven 3.0.3 it just runs the JUnit tests. (With lines 34-43 still commented out). When I bring those back, this is the output: --- T E S T S --- Running com.company.JUnitTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running com.company.TestNGTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 So it appears to try to run both tests, but fails to actually run any tests, and gets 0% coverage. It appears there is something odd between Maven 2.2.1 and Maven 3.0.3 when the cobertura plugin runs, and its reading of the Surefire plugin configuration. Ideally I would only use JUnit or TestNG, and this would not be a problem. However, we are using TestNG exclusively, and wanted to introduce a tool that currently only is executed as a JUnit test (Spock). I wanted to avoid changing all our tests from TestNG to JUnit unless absolutely necessary. It appears to be a regression from Maven 2.2.1 to Maven 3.0.3, unless it was a bug in Maven 2 that was fixed. -- Larry - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
