Re: releasing maven-toolchains-plugin
Hi Hervé, Perhaps add a menu item for your new page about Custom Toolchains :-) On Sun, Nov 9, 2014 at 3:01 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: a complete IT has been added with custom toolchain, and documentation http://maven.eu.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/toolchains/custom.html I intend to do the release in a few days: please chime in if you see anything to do before releasing Regards, Hervé - 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: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
It would appear to me that this output is coming to stderr, which is why it's being logged to ERROR. Any way to make JUL not go to stderr ? Kristian 2014-11-11 8:48 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, I'm working on the Cobertura Maven Plugin over at Mojo, and have run into a problem that I cannot solve. This plugin wraps an external tool, Cobertura, which logs stuff either by System.out.println() or by using Java Util Logging (JUL). The printing to standard out/err is not a problem and the output ends up where expected. The problem is with JUL. Here's an output example when using Cobertura's own command line inteface: Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file 2014-nov-11 08:18:03 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. Report time: 231ms The first line is using stdout and the last 2 lines are a log message using JUL. Now here's what the output form the plugin looks like, after being handled by CommandLineUtils.executeCommanLine() from plexus-utils: [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] 2014-nov-11 08:24:29 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. As you can see the first line is OK, but the second line is not. Somewhere the logging output from JUL is interpreted as being an error on the Maven side of things. Is there any way to tell plexus-utils to treat JUL as being on INFO level, or better yet to wrap JUL inside a Mojo logger? -- 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
Is there any documentation of the process of releasing an Apache project built with maven?
Hi, at the Flex project there are some parts being built with Maven. Now we would like to release some of them and currently there is a bit of a discussion about how to do this. Currently most people are insisting on a rather manual process they have been using for releasing the Ant built stuff. Now I think maven could make life a lot easier for us, but I don't quite know how to comply to the Apache release rules. I think simply releasing the auto-generated source jars isn't what Apache understands as Source release. I guess you on this list have a lot of experience with releasing Maven built Apache projects. Would be glad for some pointers. Searching the Maven Confluence page doesn't guide me to release documentations dealing with the requirements of the ASF and even mentioning apache maven and release swamps me with maven-release-plugin documentation ;-) Would be grateful for some links or clarification. Chris
Re: Is there any documentation of the process of releasing an Apache project built with maven?
Hi Chris, there is a quite detailed explanation of what Apache understands as a release: http://www.apache.org/dev/release.html Uploading the source JARs to Maven Central is afaik not enough. What UIMA does is, we set up the build so that as part of the Maven build, a ZIP of the checked out sources is done starting from the root of the checkout. It's actually pretty straight. I believe this ZIP is augmented with some license files etc. As part of the release this source ZIP and a corresponding ZIP containing a compiled distribution are uploaded to the Apache mirror system. If you would like to take Apache UIMA as a role model, check out our release guidelines: http://uima.apache.org/release.html And of course our Maven-based build setup which helps us in doing the releases is in the Apache SVN. Cheers, -- Richard On 11.11.2014, at 10:23, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, at the Flex project there are some parts being built with Maven. Now we would like to release some of them and currently there is a bit of a discussion about how to do this. Currently most people are insisting on a rather manual process they have been using for releasing the Ant built stuff. Now I think maven could make life a lot easier for us, but I don't quite know how to comply to the Apache release rules. I think simply releasing the auto-generated source jars isn't what Apache understands as Source release. I guess you on this list have a lot of experience with releasing Maven built Apache projects. Would be glad for some pointers. Searching the Maven Confluence page doesn't guide me to release documentations dealing with the requirements of the ASF and even mentioning apache maven and release swamps me with maven-release-plugin documentation ;-) Would be grateful for some links or clarification. Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: Is there any documentation of the process of releasing an Apache project built with maven?
Yeah ... think this was what I was looking for. I know the maven release process quite well and therefore knew that probably the source-jar was not enough ... I didn't want to have to maintain an assembly config though but I was sort of surprised that the default config of the assembly plugin does exactly what I was looking for. I borrowed some plugin config from your project and I think I might be able to convince the others to start maven releases (Eventually even start converting some of the stuff to maven ;-) ) Chris Von: Richard Eckart de Castilho r...@apache.org Gesendet: Dienstag, 11. November 2014 10:33 An: Maven Developers List Betreff: Re: Is there any documentation of the process of releasing an Apache project built with maven? Hi Chris, there is a quite detailed explanation of what Apache understands as a release: http://www.apache.org/dev/release.html Uploading the source JARs to Maven Central is afaik not enough. What UIMA does is, we set up the build so that as part of the Maven build, a ZIP of the checked out sources is done starting from the root of the checkout. It's actually pretty straight. I believe this ZIP is augmented with some license files etc. As part of the release this source ZIP and a corresponding ZIP containing a compiled distribution are uploaded to the Apache mirror system. If you would like to take Apache UIMA as a role model, check out our release guidelines: http://uima.apache.org/release.html And of course our Maven-based build setup which helps us in doing the releases is in the Apache SVN. Cheers, -- Richard On 11.11.2014, at 10:23, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, at the Flex project there are some parts being built with Maven. Now we would like to release some of them and currently there is a bit of a discussion about how to do this. Currently most people are insisting on a rather manual process they have been using for releasing the Ant built stuff. Now I think maven could make life a lot easier for us, but I don't quite know how to comply to the Apache release rules. I think simply releasing the auto-generated source jars isn't what Apache understands as Source release. I guess you on this list have a lot of experience with releasing Maven built Apache projects. Would be glad for some pointers. Searching the Maven Confluence page doesn't guide me to release documentations dealing with the requirements of the ASF and even mentioning apache maven and release swamps me with maven-release-plugin documentation ;-) Would be grateful for some links or clarification. Chris - 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: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
Thanks Kristian, Yes, the output is going to stderr. I've confirmed that via some debugging statements in the plugin. I haven't used native JUL before, but I'll investigate it. Any pointers are much appreciated. Here is a snippet of the code that does the logging in Cobertura: import java.util.logging.Level; import java.util.logging.Logger; private static Logger logger = Logger.getLogger(CoverageDataFileHandler.class.getCanonicalName()); logger.log(Level.INFO, Cobertura: Loaded information on + projectData.getNumberOfClasses() + classes.); On Tue, Nov 11, 2014 at 9:19 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: It would appear to me that this output is coming to stderr, which is why it's being logged to ERROR. Any way to make JUL not go to stderr ? Kristian 2014-11-11 8:48 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, I'm working on the Cobertura Maven Plugin over at Mojo, and have run into a problem that I cannot solve. This plugin wraps an external tool, Cobertura, which logs stuff either by System.out.println() or by using Java Util Logging (JUL). The printing to standard out/err is not a problem and the output ends up where expected. The problem is with JUL. Here's an output example when using Cobertura's own command line inteface: Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file 2014-nov-11 08:18:03 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. Report time: 231ms The first line is using stdout and the last 2 lines are a log message using JUL. Now here's what the output form the plugin looks like, after being handled by CommandLineUtils.executeCommanLine() from plexus-utils: [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] 2014-nov-11 08:24:29 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. As you can see the first line is OK, but the second line is not. Somewhere the logging output from JUL is interpreted as being an error on the Maven side of things. Is there any way to tell plexus-utils to treat JUL as being on INFO level, or better yet to wrap JUL inside a Mojo logger? -- 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
Maybe this helps: http://stackoverflow.com/questions/194165/how-do-i-change-java-logging-console-output-from-std-err-to-std-out http://stackoverflow.com/questions/2533227/how-can-i-disable-the-default-console-handler-while-using-the-java-logging-api/2533250#2533250 -- Alexander Kriegisch http://scrum-master.de Yes, the output is going to stderr. I've confirmed that via some debugging statements in the plugin. I haven't used native JUL before, but I'll investigate it. Any pointers are much appreciated. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
To be more precise:
===
import java.util.logging.ConsoleHandler;
import java.util.logging.Level;
import java.util.logging.LogRecord;
import java.util.logging.SimpleFormatter;
import java.util.logging.StreamHandler;
public class DualConsoleHandler extends StreamHandler {
private final ConsoleHandler stderrHandler = new ConsoleHandler();
public DualConsoleHandler() {
super(System.out, new SimpleFormatter());
}
@Override
public void publish(LogRecord record) {
if (record.getLevel().intValue() = Level.INFO.intValue()) {
super.publish(record);
super.flush();
} else {
stderrHandler.publish(record);
stderrHandler.flush();
}
}
}
===
import java.util.logging.Level;
import java.util.logging.Logger;
public class Application {
private static Logger logger =
Logger.getLogger(Application.class.getCanonicalName());
static {
logger.addHandler(new DualConsoleHandler());
logger.setUseParentHandlers(false);
}
public static void main(String[] args) {
logger.log(Level.INFO, Does the output go to stout or
stderr?);
logger.log(Level.WARNING, Does the output go to stout or
stderr?);
}
}
--
Alexander Kriegisch
http://scrum-master.de
Alexander Kriegisch schrieb am 11.11.2014 14:25:
Maybe this helps:
http://stackoverflow.com/questions/194165/how-do-i-change-java-logging-console-output-from-std-err-to-std-out
http://stackoverflow.com/questions/2533227/how-can-i-disable-the-default-console-handler-while-using-the-java-logging-api/2533250#2533250
Yes, the output is going to stderr. I've confirmed that via some
debugging statements in the plugin.
I haven't used native JUL before, but I'll investigate it. Any
pointers are much appreciated.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
Hello Dennis, Yup - the odd/strange error printout in the Cobertura Maven Plugin comes from the underlying Cobertura framework printing some logging statements to the standard error stream. This is something which simply should be changed/fixed in Cobertura. 2014-11-11 13:35 GMT+01:00 Dennis Lundberg denn...@apache.org: Thanks Kristian, Yes, the output is going to stderr. I've confirmed that via some debugging statements in the plugin. I haven't used native JUL before, but I'll investigate it. Any pointers are much appreciated. Here is a snippet of the code that does the logging in Cobertura: import java.util.logging.Level; import java.util.logging.Logger; private static Logger logger = Logger.getLogger(CoverageDataFileHandler.class.getCanonicalName()); logger.log(Level.INFO, Cobertura: Loaded information on + projectData.getNumberOfClasses() + classes.); On Tue, Nov 11, 2014 at 9:19 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: It would appear to me that this output is coming to stderr, which is why it's being logged to ERROR. Any way to make JUL not go to stderr ? Kristian 2014-11-11 8:48 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, I'm working on the Cobertura Maven Plugin over at Mojo, and have run into a problem that I cannot solve. This plugin wraps an external tool, Cobertura, which logs stuff either by System.out.println() or by using Java Util Logging (JUL). The printing to standard out/err is not a problem and the output ends up where expected. The problem is with JUL. Here's an output example when using Cobertura's own command line inteface: Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file 2014-nov-11 08:18:03 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. Report time: 231ms The first line is using stdout and the last 2 lines are a log message using JUL. Now here's what the output form the plugin looks like, after being handled by CommandLineUtils.executeCommanLine() from plexus-utils: [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] 2014-nov-11 08:24:29 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. As you can see the first line is OK, but the second line is not. Somewhere the logging output from JUL is interpreted as being an error on the Maven side of things. Is there any way to tell plexus-utils to treat JUL as being on INFO level, or better yet to wrap JUL inside a Mojo logger? -- 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
Re: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
Dennis: Would(n't) the work Mark Struberg did at [1] be of use here? HTH, Matt [1] http://svn.apache.org/viewvc/commons/proper/weaver/trunk/maven-plugin/src/main/java/org/apache/commons/weaver/maven/JavaLoggingToMojoLoggingRedirector.java?revision=HEADview=markup On Nov 11, 2014 1:50 AM, Dennis Lundberg denn...@apache.org wrote: Hi, I'm working on the Cobertura Maven Plugin over at Mojo, and have run into a problem that I cannot solve. This plugin wraps an external tool, Cobertura, which logs stuff either by System.out.println() or by using Java Util Logging (JUL). The printing to standard out/err is not a problem and the output ends up where expected. The problem is with JUL. Here's an output example when using Cobertura's own command line inteface: Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file 2014-nov-11 08:18:03 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. Report time: 231ms The first line is using stdout and the last 2 lines are a log message using JUL. Now here's what the output form the plugin looks like, after being handled by CommandLineUtils.executeCommanLine() from plexus-utils: [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] 2014-nov-11 08:24:29 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. As you can see the first line is OK, but the second line is not. Somewhere the logging output from JUL is interpreted as being an error on the Maven side of things. Is there any way to tell plexus-utils to treat JUL as being on INFO level, or better yet to wrap JUL inside a Mojo logger? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: AW: Is there any documentation of the process of releasing an Apache project built with maven?
notice ASF parent pom is documented here: http://maven.apache.org/pom/asf/ which explains some magic regarding assembly Regards, Hervé Le mardi 11 novembre 2014 10:31:52 Christofer Dutz a écrit : Yeah ... think this was what I was looking for. I know the maven release process quite well and therefore knew that probably the source-jar was not enough ... I didn't want to have to maintain an assembly config though but I was sort of surprised that the default config of the assembly plugin does exactly what I was looking for. I borrowed some plugin config from your project and I think I might be able to convince the others to start maven releases (Eventually even start converting some of the stuff to maven ;-) ) Chris Von: Richard Eckart de Castilho r...@apache.org Gesendet: Dienstag, 11. November 2014 10:33 An: Maven Developers List Betreff: Re: Is there any documentation of the process of releasing an Apache project built with maven? Hi Chris, there is a quite detailed explanation of what Apache understands as a release: http://www.apache.org/dev/release.html Uploading the source JARs to Maven Central is afaik not enough. What UIMA does is, we set up the build so that as part of the Maven build, a ZIP of the checked out sources is done starting from the root of the checkout. It's actually pretty straight. I believe this ZIP is augmented with some license files etc. As part of the release this source ZIP and a corresponding ZIP containing a compiled distribution are uploaded to the Apache mirror system. If you would like to take Apache UIMA as a role model, check out our release guidelines: http://uima.apache.org/release.html And of course our Maven-based build setup which helps us in doing the releases is in the Apache SVN. Cheers, -- Richard On 11.11.2014, at 10:23, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, at the Flex project there are some parts being built with Maven. Now we would like to release some of them and currently there is a bit of a discussion about how to do this. Currently most people are insisting on a rather manual process they have been using for releasing the Ant built stuff. Now I think maven could make life a lot easier for us, but I don't quite know how to comply to the Apache release rules. I think simply releasing the auto-generated source jars isn't what Apache understands as Source release. I guess you on this list have a lot of experience with releasing Maven built Apache projects. Would be glad for some pointers. Searching the Maven Confluence page doesn't guide me to release documentations dealing with the requirements of the ASF and even mentioning apache maven and release swamps me with maven-release-plugin documentation ;-) Would be grateful for some links or clarification. Chris - 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: releasing maven-toolchains-plugin
Hi, I suppose that splitting later won't give much problems: just explanations for upgrade. Then IMHO it's better not to split early: keep it simple as long as possible But that a pure opinion based on personal principles, not on experience from this precise case: I never wrote a toolchain before writing this IT :) Regards, Hervé Le mardi 11 novembre 2014 07:16:08 Mirko Friedenhagen a écrit : Hello Hervé, thanks for the writeup. One question: * is there anything wrong with using a plugin as an extension should more than one plugin use the provided toolchain, i.e. is it worth to split early? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sun, Nov 9, 2014 at 3:01 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: a complete IT has been added with custom toolchain, and documentation http://maven.eu.apache.org/plugins-archives/maven-toolchains-plugin-LATEST /toolchains/custom.html I intend to do the release in a few days: please chime in if you see anything to do before releasing Regards, Hervé - 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: releasing maven-toolchains-plugin
Hi Dennis, good idea: I'll do it thank you for the feedback Regards, Hervé Le mardi 11 novembre 2014 09:07:10 Dennis Lundberg a écrit : Hi Hervé, Perhaps add a menu item for your new page about Custom Toolchains :-) On Sun, Nov 9, 2014 at 3:01 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: a complete IT has been added with custom toolchain, and documentation http://maven.eu.apache.org/plugins-archives/maven-toolchains-plugin-LATEST /toolchains/custom.html I intend to do the release in a few days: please chime in if you see anything to do before releasing Regards, Hervé - 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: How to handle Java Util Logging from external tool in a Mojo using CommandLineUtils from plexus-utils?
Hello Matt, I'd say it is desirable to make Cobertura log with a single logging system, and - if the Cobertura community choose the JUL system - use something like Mark's approach within the cobertura-maven-plugin. The C-M-P implementation will need to redirect all Cobertura's logging output into the normal Maven's plugin log. 2014-11-11 18:29 GMT+01:00 Matt Benson gudnabr...@gmail.com: Dennis: Would(n't) the work Mark Struberg did at [1] be of use here? HTH, Matt [1] http://svn.apache.org/viewvc/commons/proper/weaver/trunk/maven-plugin/src/main/java/org/apache/commons/weaver/maven/JavaLoggingToMojoLoggingRedirector.java?revision=HEADview=markup On Nov 11, 2014 1:50 AM, Dennis Lundberg denn...@apache.org wrote: Hi, I'm working on the Cobertura Maven Plugin over at Mojo, and have run into a problem that I cannot solve. This plugin wraps an external tool, Cobertura, which logs stuff either by System.out.println() or by using Java Util Logging (JUL). The printing to standard out/err is not a problem and the output ends up where expected. The problem is with JUL. Here's an output example when using Cobertura's own command line inteface: Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file 2014-nov-11 08:18:03 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. Report time: 231ms The first line is using stdout and the last 2 lines are a log message using JUL. Now here's what the output form the plugin looks like, after being handled by CommandLineUtils.executeCommanLine() from plexus-utils: [INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [ERROR] 2014-nov-11 08:24:29 net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler loadCoverageData INFO: Cobertura: Loaded information on 5 classes. As you can see the first line is OK, but the second line is not. Somewhere the logging output from JUL is interpreted as being an error on the Maven side of things. Is there any way to tell plexus-utils to treat JUL as being on INFO level, or better yet to wrap JUL inside a Mojo logger? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
[VOTE] Release Apache Maven Toolchains Plugin version 1.1
Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12063styleName=Htmlversion=15920 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12063status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1096/ http://repository.apache.org/content/repositories/maven-1096/org/apache/maven/plugins/maven-toolchains-plugin/1.1/maven-toolchains-plugin-1.1-source-release.zip Source release checksum(s): maven-toolchains-plugin-1.1-source-release.zip sha1: 823bcd6be51eebe063c0771dc9c20124028a0713 Staging site: http://maven.apache.org/plugins-archives/maven-toolchains-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-repository-builder 1.0
+1 I published the site, which was apparently built without -Preporting A better index page would be useful, or at least better description Regards, Hervé Le lundi 10 novembre 2014 21:39:47 Kristian Rosenvold a écrit : We solved 4 issues, including an enourmously irritating stacktrace this component has been logging with -X. http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=171 40 There are no issues left in JIRA. http://repository.apache.org/content/repositories/maven-1095/org/apache/mave n/shared/maven-repository-builder/1.0/maven-repository-builder-1.0-source-re lease.zip source checksum: 5b3e49626aa960d132286b51d55d4ec3d9317383 (sha1) Staging site: http://maven.apache.org/shared-archives/maven-repository-builder-LATEST/ Staging repository: http://repository.apache.org/content/repositories/maven-1095/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 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
[VOTE] Apache Maven Wagon 2.8
Hi, We fixed 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=20613 Staging repository: https://repository.apache.org/content/repositories/maven-1097/ Staged site: http://maven.apache.org/wagon-archives/wagon-LATEST/ Vote open for 72H [+1] [0] [-1] Cheers -- Olivier Lamy 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
