Re: [RESULT] Maven Compiler Plugin 3.0 and maven-shared-incremental 1.0
late but anyway. +1 tried some simple operations with netbeans.org annotations (and annotation processors) Milos Kleint On Mon, Nov 19, 2012 at 12:37 AM, Olivier Lamy ol...@apache.org wrote: Hi, The vote has passed with the following result: +1 (binding): Arnaud Heritier, Emmanuel Venisse, Stephan Nicoll, Mark Struberg, Hervé Boutemy, Robert Scholte, Olivier Lamy +1 (non binding): Mirko Friedenhagen, Anders Hammar I will continue the release process. Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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
Easy update sites for Eclipse with Sonatype Nexus
Hi guys, I'm looking for a better solution for a problem, I solved it last week, but I'm not happy ;) My task: Create a fully functional Eclipse update site with Nexus (can be used for updates and target platform definitions) My problem: The original extension for P2 sites for Nexus only considers plugins (https://github.com/sonatype/nexus-p2-repository-plugin) Unfortunately, the Fork, which considered features, is also out of date. But I found a workaround (https://github.com/reficio/p2-maven-plugin) in Maven P2 plugin. If a plugin is categorized, you can install it with Eclipse. Therefore, I searched for a way to categorize my plugins. I build with Tycho, but the Nexus does not consider the metadata of Tycho. So I had to find a way to let Nexus categorize my plugins without Tycho. Finally, I patched (https://github.com/nachtgold/nexus-p2-bridge-plugin/commit/c0941a2398efd7662dc3c8d64e91fd72d1eb18df) the Nexus P2 bridge plugin and add a default category to each plugin. In addition, we can use this way to omit features! Categorization with Eclipse, I only know the composition of repositories. Tycho can categorize repositories as well, but the Nexus completely ignored the metadata. Does anyone have a suggestion on how to categorize plugins or bundles? The target is to construct a more useful processing with these metadata in P2 Nexus plugin. thx Kai -- View this message in context: http://maven.40175.n5.nabble.com/Easy-update-sites-for-Eclipse-with-Sonatype-Nexus-tp5731750.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
[ANN] Maven Compiler Plugin 3.0 Released
The Maven team is pleased to announce the release of the Maven Compiler Plugin, version 3.0 The Compiler Plugin is used to compile the sources of your project. http://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.0/version /plugin Release Notes - Maven 2.x Compiler Plugin - Version 3.0 ** Bug * [MCOMPILER-160] - javac error but build SUCCESS * [MCOMPILER-173] - use new maven plugin annotations * [MCOMPILER-179] - Warnings * [MCOMPILER-181] - Exception on compilation are not properly reported * [MCOMPILER-182] - Case sensitivity changes in class names not detected by compiler * [MCOMPILER-184] - use last plexus-compiler 2.0 api * [MCOMPILER-186] - mojos are in wrong package (org.apache.maven.plugin) ** Task * [MCOMPILER-171] - use maven-plugin-tools' java 5 annotations Have Fun, -- The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logger name for mojo
Hi,
I did the two implementations and it's available for testing:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the
mojo logger name is maven.${groupId}.${goal} (see
simplelogger.properties on how to mark a plugin in debug level)
*
https://github.com/olamy/maven-3/commits/logger-mojo-classname-plus-mdc-for-plugin-info
(the mojo logger is the mojo class name + MDC key maven.pluginInfo
value maven.${groupId}.${goal}) note this version doesn't work very
well with site plugin as the site plugin doesn't reset correctly this
MDC value)
Then both branches available with log4j2:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info-log4j2
*
https://github.com/olamy/maven-3/tree/logger-mojo-classname-plus-mdc-for-plugin-info-log4j2
To try that: ant (-DskipTests=true) NOTE that this will erase your
current maven installation so take care :-)
2012/11/17 Hervé BOUTEMY herve.bout...@free.fr:
Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Inject the SLF4J logger factory and use that with the underlying
component
descriptor's implementation definition which is the class name.
if we change the code, yes, we can do anything
I mean in the plugin manager in this specific case for plugins, not
everywhere
if we only change the logger name put in Mojos, I'm not in favor of using the
classical classname as the logger name, since actual logger use is shared
between mojo and other classes, then what seems to be the classical convention
is not
Having a temporary other logger name is better, to give us time to work on
more extensive solution
and if we want to have the logger as class name (which is a good choice),
we'll need to change a lot of code to be consistent with this convention
I think in the vast majority of cases it is injected by @Requirement,
can you point me to an example, please? I don't see
descend from AbstractLogEnabled,
yes, this one is the most used for Mojos
or is set in the plugin manager
the plugin manager uses AbstractLogEnabled, so that's the same as
AbstractLogEnabled
which
makes it possible to change the hierarchy in the system without changing
much. When I'm finished working on this release I will make an
implementation using Logback as a point of disucssion with Olivier's Log4j2
implementation.
choosing the logger name doesn't have anything to do with choosing the logging
implementation: I'd prefer have the two discussions completely separated
(BTW, thanks Olivier for working on logging questions that are independant
from implementation solution, just to continue progress)
see the actual pattern found in some plugins where a logger instance is
given from one class to another, like [1]
AFAIK, actually, logger in injected through AbstractLogEnabled class.
Is there a way to inject a logger or a logger manager into a plexus
component? some example?
@Requirement has worked for quite some time,
can point me to an example, please?
I'd like to rework plugin-tools code to make better use of logging, and test
ideas we share, since I don't really know which ideas are just a question of
my bad knowledge of existing solutions and which ideas are really ideas
without concrete code
@Inject also now works with the
code in trunk. I believe most other cases are plugins that have their
logger set by the plugin manager which we have full access to.
as said before, plugins then give the logger to other classes for them to do
log
At any rate I spent all day yesterday looking at the snapshot bounds issue
so I'm going to continue with the list for 3.1.0.
I'm not in a hurry :)
I'll participate more in
the logging discussion post 3.1.0 with an implementation as an example.
please don't mix logger name discussion with implementation: it works with
slf4j-simple, and this is exactly why doing most logging design when we're
still using slf4j-simple is a good idea.
The discussion to getting more advanced implementation is for the future
If I understand the idea, I still don't know how to do that
Regards,
Hervé
[1] http://maven.apache.org/plugin-tools/maven-plugin-
plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
herve.bout...@free.frwrote:
+1 for the idea
other complementary ideas:
- groupId is not really useful, plugins's artifactId is in general
sufficient
- I'd add goal name
- dot separator, since this is the classical separator in every java
logging
implementations (due to the classical class name as logger pattern)
- add prefix with something like maven., to separate maven logs from
logs
from other tools (probably organized by full class name)
then my preference would go to
maven.${artifactId}.${goal}
which is a domain specific pattern, not the classical full class
name
(FYI,
Re: Easy update sites for Eclipse with Sonatype Nexus
The Maven dev list is not the appropriate mailing list for this question. I would try the Nexus user list or the tycho user list. /Anders On Mon, Nov 19, 2012 at 9:12 AM, kai.zimmermann kai.zimmerm...@robotron.dewrote: Hi guys, I'm looking for a better solution for a problem, I solved it last week, but I'm not happy ;) My task: Create a fully functional Eclipse update site with Nexus (can be used for updates and target platform definitions) My problem: The original extension for P2 sites for Nexus only considers plugins (https://github.com/sonatype/nexus-p2-repository-plugin) Unfortunately, the Fork, which considered features, is also out of date. But I found a workaround (https://github.com/reficio/p2-maven-plugin) in Maven P2 plugin. If a plugin is categorized, you can install it with Eclipse. Therefore, I searched for a way to categorize my plugins. I build with Tycho, but the Nexus does not consider the metadata of Tycho. So I had to find a way to let Nexus categorize my plugins without Tycho. Finally, I patched ( https://github.com/nachtgold/nexus-p2-bridge-plugin/commit/c0941a2398efd7662dc3c8d64e91fd72d1eb18df ) the Nexus P2 bridge plugin and add a default category to each plugin. In addition, we can use this way to omit features! Categorization with Eclipse, I only know the composition of repositories. Tycho can categorize repositories as well, but the Nexus completely ignored the metadata. Does anyone have a suggestion on how to categorize plugins or bundles? The target is to construct a more useful processing with these metadata in P2 Nexus plugin. thx Kai -- View this message in context: http://maven.40175.n5.nabble.com/Easy-update-sites-for-Eclipse-with-Sonatype-Nexus-tp5731750.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
[VOTE] Maven Indexer 5.1.0 Release
Hi, we'd like to release Maven Indexer 5.1.0. We fixed 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=18972 Staging repository: https://repository.apache.org/content/repositories/maven-045/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~
Re: Logger name for mojo
I'm going to work on the 3.1.0 release all this week and then I will clean up
my Logback implementation for comparison and discussion.
On Nov 19, 2012, at 3:38 AM, Olivier Lamy ol...@apache.org wrote:
Hi,
I did the two implementations and it's available for testing:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the
mojo logger name is maven.${groupId}.${goal} (see
simplelogger.properties on how to mark a plugin in debug level)
*
https://github.com/olamy/maven-3/commits/logger-mojo-classname-plus-mdc-for-plugin-info
(the mojo logger is the mojo class name + MDC key maven.pluginInfo
value maven.${groupId}.${goal}) note this version doesn't work very
well with site plugin as the site plugin doesn't reset correctly this
MDC value)
Then both branches available with log4j2:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info-log4j2
*
https://github.com/olamy/maven-3/tree/logger-mojo-classname-plus-mdc-for-plugin-info-log4j2
To try that: ant (-DskipTests=true) NOTE that this will erase your
current maven installation so take care :-)
2012/11/17 Hervé BOUTEMY herve.bout...@free.fr:
Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Inject the SLF4J logger factory and use that with the underlying
component
descriptor's implementation definition which is the class name.
if we change the code, yes, we can do anything
I mean in the plugin manager in this specific case for plugins, not
everywhere
if we only change the logger name put in Mojos, I'm not in favor of using the
classical classname as the logger name, since actual logger use is shared
between mojo and other classes, then what seems to be the classical
convention
is not
Having a temporary other logger name is better, to give us time to work on
more extensive solution
and if we want to have the logger as class name (which is a good choice),
we'll need to change a lot of code to be consistent with this convention
I think in the vast majority of cases it is injected by @Requirement,
can you point me to an example, please? I don't see
descend from AbstractLogEnabled,
yes, this one is the most used for Mojos
or is set in the plugin manager
the plugin manager uses AbstractLogEnabled, so that's the same as
AbstractLogEnabled
which
makes it possible to change the hierarchy in the system without changing
much. When I'm finished working on this release I will make an
implementation using Logback as a point of disucssion with Olivier's Log4j2
implementation.
choosing the logger name doesn't have anything to do with choosing the
logging
implementation: I'd prefer have the two discussions completely separated
(BTW, thanks Olivier for working on logging questions that are independant
from implementation solution, just to continue progress)
see the actual pattern found in some plugins where a logger instance is
given from one class to another, like [1]
AFAIK, actually, logger in injected through AbstractLogEnabled class.
Is there a way to inject a logger or a logger manager into a plexus
component? some example?
@Requirement has worked for quite some time,
can point me to an example, please?
I'd like to rework plugin-tools code to make better use of logging, and test
ideas we share, since I don't really know which ideas are just a question of
my bad knowledge of existing solutions and which ideas are really ideas
without concrete code
@Inject also now works with the
code in trunk. I believe most other cases are plugins that have their
logger set by the plugin manager which we have full access to.
as said before, plugins then give the logger to other classes for them to do
log
At any rate I spent all day yesterday looking at the snapshot bounds issue
so I'm going to continue with the list for 3.1.0.
I'm not in a hurry :)
I'll participate more in
the logging discussion post 3.1.0 with an implementation as an example.
please don't mix logger name discussion with implementation: it works with
slf4j-simple, and this is exactly why doing most logging design when we're
still using slf4j-simple is a good idea.
The discussion to getting more advanced implementation is for the future
If I understand the idea, I still don't know how to do that
Regards,
Hervé
[1] http://maven.apache.org/plugin-tools/maven-plugin-
plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
herve.bout...@free.frwrote:
+1 for the idea
other complementary ideas:
- groupId is not really useful, plugins's artifactId is in general
sufficient
- I'd add goal name
- dot separator, since this is the classical separator in every java
logging
implementations (due to the classical class name as logger pattern)
- add prefix with something like maven., to separate maven logs from
logs
Re: Easy update sites for Eclipse with Sonatype Nexus
You probably want to take this up on the Nexus list. Today if you manage the creation of the update site or TP you can deploy the zip to Nexus and it will unpack it into a site repository and then further manipulation will require work. But you can share update sites and TPs in a primitive way. There are a handful of plugins that exist for Nexus for generating p2 metadata but, I believe, you want to build and deploy to Nexus and have Nexus generate the composite along with any additional metadata. To see how this currently works you'll need to build an install the unpack plugin[1] and if you want to see how it's used for deploying m2e and all the extras you can take a look at this pom[2]. Most of the bits and pieces exist to do what you want and I don't think composite generation would be terribly difficult. I see people trying to implement this over and over so I encourage you to bring it up on the Nexus because you're not the only one trying to do this. In fact the Eclipse Foundation is trying to solve this problem as well. [1]: https://github.com/sonatype/nexus-unpack-plugin [2]: https://github.com/tesla/tycho-support On Nov 19, 2012, at 3:12 AM, kai.zimmermann kai.zimmerm...@robotron.de wrote: Hi guys, I'm looking for a better solution for a problem, I solved it last week, but I'm not happy ;) My task: Create a fully functional Eclipse update site with Nexus (can be used for updates and target platform definitions) My problem: The original extension for P2 sites for Nexus only considers plugins (https://github.com/sonatype/nexus-p2-repository-plugin) Unfortunately, the Fork, which considered features, is also out of date. But I found a workaround (https://github.com/reficio/p2-maven-plugin) in Maven P2 plugin. If a plugin is categorized, you can install it with Eclipse. Therefore, I searched for a way to categorize my plugins. I build with Tycho, but the Nexus does not consider the metadata of Tycho. So I had to find a way to let Nexus categorize my plugins without Tycho. Finally, I patched (https://github.com/nachtgold/nexus-p2-bridge-plugin/commit/c0941a2398efd7662dc3c8d64e91fd72d1eb18df) the Nexus P2 bridge plugin and add a default category to each plugin. In addition, we can use this way to omit features! Categorization with Eclipse, I only know the composition of repositories. Tycho can categorize repositories as well, but the Nexus completely ignored the metadata. Does anyone have a suggestion on how to categorize plugins or bundles? The target is to construct a more useful processing with these metadata in P2 Nexus plugin. thx Kai -- View this message in context: http://maven.40175.n5.nabble.com/Easy-update-sites-for-Eclipse-with-Sonatype-Nexus-tp5731750.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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
RE: Thrift difficulties
Good Morning Benson this is the second instance of gmail turkey virus this weekcan you change your gmail password (from a secure location) Martin __ Man in the middle...keep your 'mitt's off this email Date: Sun, 18 Nov 2012 17:52:28 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org A gmail prank. Urk. Sorry. Please ignore. On Sun, Nov 18, 2012 at 5:49 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Any reason you sent this to the Maven list? On 18 November 2012 21:50, Benson Margulies bimargul...@gmail.com wrote: Here I am on osx. trying to build thrift 0.8, I run aground at: Making all in rb /usr/bin/rake (in /opt/thrift-0.8.0/lib/rb) rake aborted! no such file to load -- spec/rake/spectask /opt/thrift-0.8.0/lib/rb/Rakefile:23 Can I use 0.9? Is there some know way to dodge this? - 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
Releasing Wagon 2.3 for Maven 3.1.0
I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog and I haven't seen any work in there in the last while so I assume it's all good to go. Let me know if there's anything you want to squeeze in, but it needs to be released before Maven can so I'd like to take care of it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: Thrift difficulties
they were went within 2 minutes of each other, and the problem is gmail completion fooling my fingers. On Mon, Nov 19, 2012 at 7:32 AM, Martin Gainty mgai...@hotmail.com wrote: Good Morning Benson this is the second instance of gmail turkey virus this weekcan you change your gmail password (from a secure location) Martin __ Man in the middle...keep your 'mitt's off this email Date: Sun, 18 Nov 2012 17:52:28 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org A gmail prank. Urk. Sorry. Please ignore. On Sun, Nov 18, 2012 at 5:49 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Any reason you sent this to the Maven list? On 18 November 2012 21:50, Benson Margulies bimargul...@gmail.com wrote: Here I am on osx. trying to build thrift 0.8, I run aground at: Making all in rb /usr/bin/rake (in /opt/thrift-0.8.0/lib/rb) rake aborted! no such file to load -- spec/rake/spectask /opt/thrift-0.8.0/lib/rb/Rakefile:23 Can I use 0.9? Is there some know way to dodge this? - 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: Site plugin and forked executions
Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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: Site plugin and forked executions
Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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
MNG-5336
Dennis, FYI, Hervé flipped the deployment of Modello over to using Nexus OSSRH and the ticket[1] has been processed. The first deployment will get checked, but once done the release should go through and you should be able to proceed with MNG-5336. [1]: https://issues.sonatype.org/browse/OSSRH-4723 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - 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
Re: Releasing Wagon 2.3 for Maven 3.1.0
If nothing pops up tonight, I'll cut the release tonight. Hopefully it will be ready for integration on Friday. On Nov 19, 2012, at 7:35 AM, Jason van Zyl ja...@tesla.io wrote: I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog and I haven't seen any work in there in the last while so I assume it's all good to go. Let me know if there's anything you want to squeeze in, but it needs to be released before Maven can so I'd like to take care of it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: Site plugin and forked executions
Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Site plugin and forked executions
The second wasn't involved in this case. The first was. On Mon, Nov 19, 2012 at 2:50 PM, Dennis Lundberg denn...@apache.org wrote: Hi Yes, most likely. There are a bunch of JIRAs for the Site Plugin about issues like the one you're experiencing. The two things that stands out from memory are: - aggregate reporting plugins (like Javadoc in your example) - using the new way of configuring reporting plugins, i.e. under the Site Plugin's configuration element I try to stay away from both if I can... On 2012-11-19 14:31, Benson Margulies wrote: Or is this the real villan: [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [INFO] [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo [INFO] [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies bimargul...@gmail.com wrote: Does the below show the enforcer plugin, of all things, forking? [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with basic configurator -- [DEBUG] (s) fail = true [DEBUG] (s) failFast = false [DEBUG] (f) ignoreCache = false [DEBUG] (s) project = MavenProject: org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @ /Users/benson/asf/accumulo/pom.xml [DEBUG] (s) version = [2.2.0,) [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d] [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f [DEBUG] (s) skip = false [DEBUG] -- end configuration -- [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable. [DEBUG] Detected Maven Version: 3.0.4 [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,). [INFO] [INFO] [INFO] Forking cloudtrace 1.5.0-SNAPSHOT [INFO] On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies bimargul...@gmail.com wrote: Barrie, I understand this much, but what I don't understand is what to do about it. Is there any choice other than to stop using reporting plugins that do the forking? Or can I put the executions of them ahead of site:site on the command line or something? I think the technical term is SOL. Unless there is a no-fork variant of the goal. I've only noticed this to be a problem more recently so I haven't had the time to give it much more thought. The knee jerk reaction is that fork should be deprecated and replaced with an alternative model. - 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 -- Dennis Lundberg - 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: Releasing Wagon 2.3 for Maven 3.1.0
Hi I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 into that release. I'm just not sure which version of slf4j to use, given that Maven core uses it now. Could you have a look? It's a matter of adding back a dependency to wagon-webdav-jackrabbit that got lost, see comments on the issue. On 2012-11-19 13:35, Jason van Zyl wrote: I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog and I haven't seen any work in there in the last while so I assume it's all good to go. Let me know if there's anything you want to squeeze in, but it needs to be released before Maven can so I'd like to take care of it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing Wagon 2.3 for Maven 3.1.0
I updated SLF4J to 1.7.2 to match the core. If you want to try it out now I can help you if anything is wrong. I'd like to try and cut the release tonight/early tomorrow. On Nov 19, 2012, at 2:57 PM, Dennis Lundberg denn...@apache.org wrote: Hi I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 into that release. I'm just not sure which version of slf4j to use, given that Maven core uses it now. Could you have a look? It's a matter of adding back a dependency to wagon-webdav-jackrabbit that got lost, see comments on the issue. On 2012-11-19 13:35, Jason van Zyl wrote: I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog and I haven't seen any work in there in the last while so I assume it's all good to go. Let me know if there's anything you want to squeeze in, but it needs to be released before Maven can so I'd like to take care of it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. -- Dennis Lundberg - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Releasing Wagon 2.3 for Maven 3.1.0
This is fixed now. On 2012-11-19 20:57, Dennis Lundberg wrote: Hi I'd like to get a fix for https://jira.codehaus.org/browse/WAGON-370 into that release. I'm just not sure which version of slf4j to use, given that Maven core uses it now. Could you have a look? It's a matter of adding back a dependency to wagon-webdav-jackrabbit that got lost, see comments on the issue. On 2012-11-19 13:35, Jason van Zyl wrote: I'd like to release Wagon 2.3 in preparation for Maven 3.1.0. I'd like to start the vote tomorrow at the latest so that the release can be completed (if there are no problems) by Friday so that I can integrate it into the release. I took the remaining open issues and pushed them into the backlog and I haven't seen any work in there in the last while so I assume it's all good to go. Let me know if there's anything you want to squeeze in, but it needs to be released before Maven can so I'd like to take care of it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Maven Rar Plugin 2.3
Hi, Last release is from feb 2007. We fixed 7 issues: http://s.apache.org/RAR-PLUGIN-2.3 Staging repo: https://repository.apache.org/content/repositories/maven-048/ Source release: maven-rar-plugin-2.3-source-release.zip Staging site: http://maven.apache.org/plugins/maven-rar-plugin-2.3 (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Rar Plugin 2.3
+1 (non binding) -Chris PS: thanks! Sent from my iPhone On 20/11/2012, at 9:09 AM, Olivier Lamy ol...@apache.org wrote: Hi, Last release is from feb 2007. We fixed 7 issues: http://s.apache.org/RAR-PLUGIN-2.3 Staging repo: https://repository.apache.org/content/repositories/maven-048/ Source release: maven-rar-plugin-2.3-source-release.zip Staging site: http://maven.apache.org/plugins/maven-rar-plugin-2.3 (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: Site plugin and forked executions
Feel like doing the manual cleansing of the output file and just keep * lifecycle events [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] * plugin details [INFO] maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo * forking info messages [INFO] [INFO] Forking accumulo 1.5.0-SNAPSHOT [INFO] At least you can get a few more eyes having a look at the problem. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-changes-plugin: rest
Ever since JIRA 4.2, they have had a REST API. So I think that we need to make m-c-p learn to use it. Anyone else game to pitch in? Anyone mind the thought of the CXF REST client library as a (not very small) dependency? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Thrift difficulties
possibly a runaway bot can your run a VirusScan to locate? Martin __ To: Man in the middle..Subject: do NOT alter or disrupt this transmission. Date: Mon, 19 Nov 2012 08:09:08 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org they were went within 2 minutes of each other, and the problem is gmail completion fooling my fingers. On Mon, Nov 19, 2012 at 7:32 AM, Martin Gainty mgai...@hotmail.com wrote: Good Morning Benson this is the second instance of gmail turkey virus this weekcan you change your gmail password (from a secure location) Martin __ Man in the middle...keep your 'mitt's off this email Date: Sun, 18 Nov 2012 17:52:28 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org A gmail prank. Urk. Sorry. Please ignore. On Sun, Nov 18, 2012 at 5:49 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Any reason you sent this to the Maven list? On 18 November 2012 21:50, Benson Margulies bimargul...@gmail.com wrote: Here I am on osx. trying to build thrift 0.8, I run aground at: Making all in rb /usr/bin/rake (in /opt/thrift-0.8.0/lib/rb) rake aborted! no such file to load -- spec/rake/spectask /opt/thrift-0.8.0/lib/rb/Rakefile:23 Can I use 0.9? Is there some know way to dodge this? - 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: Thrift difficulties
On Mon, Nov 19, 2012 at 7:18 PM, Martin Gainty mgai...@hotmail.com wrote: possibly a runaway bot can your run a VirusScan to locate? The joke was funny once. As I explained, when I start typing 'dev@' at gmail, sometimes it completes to the wrong dev list, and I fail to notice before sending. Martin __ To: Man in the middle..Subject: do NOT alter or disrupt this transmission. Date: Mon, 19 Nov 2012 08:09:08 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org they were went within 2 minutes of each other, and the problem is gmail completion fooling my fingers. On Mon, Nov 19, 2012 at 7:32 AM, Martin Gainty mgai...@hotmail.com wrote: Good Morning Benson this is the second instance of gmail turkey virus this weekcan you change your gmail password (from a secure location) Martin __ Man in the middle...keep your 'mitt's off this email Date: Sun, 18 Nov 2012 17:52:28 -0500 Subject: Re: Thrift difficulties From: bimargul...@gmail.com To: dev@maven.apache.org A gmail prank. Urk. Sorry. Please ignore. On Sun, Nov 18, 2012 at 5:49 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Any reason you sent this to the Maven list? On 18 November 2012 21:50, Benson Margulies bimargul...@gmail.com wrote: Here I am on osx. trying to build thrift 0.8, I run aground at: Making all in rb /usr/bin/rake (in /opt/thrift-0.8.0/lib/rb) rake aborted! no such file to load -- spec/rake/spectask /opt/thrift-0.8.0/lib/rb/Rakefile:23 Can I use 0.9? Is there some know way to dodge this? - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-changes-plugin: rest
You might just want to try using this: https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client On Nov 19, 2012, at 7:14 PM, Benson Margulies bimargul...@gmail.com wrote: Ever since JIRA 4.2, they have had a REST API. So I think that we need to make m-c-p learn to use it. Anyone else game to pitch in? Anyone mind the thought of the CXF REST client library as a (not very small) dependency? - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Re: maven-changes-plugin: rest
I'd have to get it to maven central. And the comments on the forum page are not terrifically encouraging. I'm pretty speedy at coding rest clients using CXF. On Mon, Nov 19, 2012 at 7:37 PM, Jason van Zyl ja...@tesla.io wrote: You might just want to try using this: https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client On Nov 19, 2012, at 7:14 PM, Benson Margulies bimargul...@gmail.com wrote: Ever since JIRA 4.2, they have had a REST API. So I think that we need to make m-c-p learn to use it. Anyone else game to pitch in? Anyone mind the thought of the CXF REST client library as a (not very small) dependency? - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Logging in plugins right now
Do we have, right now, either: 1) A way of mapping java-commons-logging to the mojo log API, or 2) A way of mapping slf4j to the mojo log? ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logging in plugins right now
On Nov 19, 2012, at 8:29 PM, Benson Margulies bimargul...@gmail.com wrote: Do we have, right now, either: 1) A way of mapping java-commons-logging to the mojo log API, or Do you mean commons-logging, JUL, or both? There are ways to adapt both to SLF4J. 2) A way of mapping slf4j to the mojo log? Mojo.getLog() feeds into SLF4J with the code on trunk. ? - 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 CTO, Sonatype 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
*shameless plug*
Shameless plug for Petclinic webapp i ported to Spring Framework 3.2.x http://www.laconiadatasystems.com/Downloads.html Comments, suggestions or advice are welcome Thanks, Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Re: [VOTE] Maven Rar Plugin 2.3
+1 Regards, Hervé Le lundi 19 novembre 2012 23:09:06 Olivier Lamy a écrit : Hi, Last release is from feb 2007. We fixed 7 issues: http://s.apache.org/RAR-PLUGIN-2.3 Staging repo: https://repository.apache.org/content/repositories/maven-048/ Source release: maven-rar-plugin-2.3-source-release.zip Staging site: http://maven.apache.org/plugins/maven-rar-plugin-2.3 (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: Logging in plugins right now
On Mon, Nov 19, 2012 at 8:34 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 19, 2012, at 8:29 PM, Benson Margulies bimargul...@gmail.com wrote: Do we have, right now, either: 1) A way of mapping java-commons-logging to the mojo log API, or Do you mean commons-logging, JUL, or both? There are ways to adapt both to SLF4J. The former, but it doesn't matter. If I add a dependency, in a plugin, that uses commons-logging, I want to map the log messages from that dependency to the mojo log, so that they look right even with Maven 3.0.x. I appreciate that as of 3.1 I can just use the usual jcl-over-slf4j (or jul or whatever) and the messages will end up in the right-ish place, though not associated with the mojo. I was hoping for plugin code calls (e.g.) CXF code calls SLF4J calls something-we-lack calls mojo log calls SLF4J calls SLF4J-simple (in 3.1) and plugin code calls (e.g.) CXF code calls SLF4J calls something-we-lack calls mojo log calls whatever we have today (in 2.x or 3.0.x) 2) A way of mapping slf4j to the mojo log? Mojo.getLog() feeds into SLF4J with the code on trunk. ? - 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 CTO, Sonatype 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: Logging in plugins right now
On Nov 19, 2012, at 8:44 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Nov 19, 2012 at 8:34 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 19, 2012, at 8:29 PM, Benson Margulies bimargul...@gmail.com wrote: Do we have, right now, either: 1) A way of mapping java-commons-logging to the mojo log API, or Do you mean commons-logging, JUL, or both? There are ways to adapt both to SLF4J. The former, but it doesn't matter. If I add a dependency, in a plugin, that uses commons-logging, I want to map the log messages from that dependency to the mojo log, so that they look right even with Maven 3.0.x. If memory serves, commons-logging will look for Log4j, then JUL, and if neither of those are present then a NoOp implementation is selected. So in our case, most people being 1.4+, the JDK implementation will be chosen and the default for JUL is to output to the console so they will come out with the rest of the output but the formatting will be slightly different. Probably nothing horrible. I appreciate that as of 3.1 I can just use the usual jcl-over-slf4j (or jul or whatever) and the messages will end up in the right-ish place, though not associated with the mojo. I was hoping for No mojo specific logging is present right now. It's just all using SLF4J but no real hierarchy, or markers have been established. So for 3.1.0 and before the output is going to look more or less the same. plugin code calls (e.g.) CXF code calls SLF4J calls something-we-lack calls mojo log calls SLF4J calls SLF4J-simple (in 3.1) and plugin code calls (e.g.) CXF code calls SLF4J calls something-we-lack calls mojo log calls whatever we have today (in 2.x or 3.0.x) In both cases now it's just all going to come out on the console. 2) A way of mapping slf4j to the mojo log? Mojo.getLog() feeds into SLF4J with the code on trunk. ? - 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 CTO, Sonatype 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
