RE: [VFS] anonymous debug logging
Hi!
From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
I'm not a big fan of that.
Me too, any decent logging facility should allow to configure the logger on a
per package level, so no problem to make the logging silent for a given
package.
I'd prefer to switch to SLF4J and just replace
Everyone in commons land is using commons-logging, no?
There is no good reason to leave this path. Sure, for my work-projects I use
slf4j too, lately I even use the Java Logging API (which is worse), but always
by using a the commons-logging API (not the Impl, just the API)
Everyone wanting to use slf4j can easily do that by using the
slf4j-commons-logging adapter and removing the commons-logging jar. Not a big
deal.
There is no benefit in switching to slf4j at all for commons-vfs, or?
if (log.isDebugEnabled())
{
log.debug(putFile: + file.getName());
}
with
logger.entry(file.getName());
This is not the same, in the second example getName() gets evaluated every
time, regardless of the configured log-level. Depending on how complicated it
is to collect the message, this might become a performance problem. the if
(log.isXXXEnabled()) prevents that.
I'd prefer to keep it the way it is.
Ciao,
Mario
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] anonymous debug logging
On Mar 25, 2009, at 11:49 PM, Mario Ivankovits wrote:
if (log.isDebugEnabled())
{
log.debug(putFile: + file.getName());
}
with
logger.entry(file.getName());
This is not the same, in the second example getName() gets evaluated
every time, regardless of the configured log-level. Depending on how
complicated it is to collect the message, this might become a
performance problem. the if (log.isXXXEnabled()) prevents that.
I'd prefer to keep it the way it is.
a) As I said in my original response, although I prefer SLF4J I
wouldn't switch from commons-logging without a lot of discussion.
There isn't a good reason to do it at this point.
b) You are correct that file.getName() gets evaluated every time.
Usually the call to getName() should be extremely cheap and will
actually be inconsequential to the time it takes to check whether
logging is enabled. If it was routinely doing some expensive String
construction then, yes it should be wrapped in if
(logger.isTraceEnabled()).
Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [g...@vmgump]: Project commons-configuration (in module apache-commons) failed
Hi Stefan, Stefan Bodewig wrote at Mittwoch, 25. März 2009 14:14: On 2009-03-25, Jörg Schaible joerg.schai...@gmx.de wrote: BTW: What is the difference in Gump's project descriptor between the optional and depend tags? If the project you depend on doesn't build in Gump, your project won't be built at all if you use depend and will still build if you use optional. For mvn projects we recommend using optional since you will either get the latest build from Gump or the one from the central repository. I think vfs is not using the groupId configuration is asking for right now. It seems combined forces are really necessary. Now, that I've learned that I can break the complete Gump run by removing a file :)) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of CreatingReleases by SiegfriedGoeschl
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The following page has been changed by SiegfriedGoeschl:
http://wiki.apache.org/commons/CreatingReleases
--
/properties
}}}
+ B.4 Update Your Download Page
+
+ The commons-build plugin generates a download page in {{{./src/site/xdoc/}}}
based on {{{commons.release.version}}}
+
+ {{{
+ mvn commons:download-page
+ }}}
+
B.3 Define Staging Site for Release Candidate
Also ensure that the {{{rc}}} profile will stage the site (rather than update
the Commons component website). See bottom of
[http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/pom.xml Commons
SCXML POM] as an example. See
[http://issues.apache.org/jira/browse/COMMONSSITE-26 COMMONSSITE-26] for
background.
@@ -119, +127 @@
If you are declaring/using your own assembly descriptors make sure that they
are not using ${version} but ${commons.release.version} - there seems to be an
odd bug which results in an incorrectly expanded version string, e.g.
{{{commons-exec-2.4.1-src}}}. If in doubt look at {{{./src/assembly/src.xml}}}
+ B.6 Commit Your Changes
+
+ When you followed the instructions you have modified a couple of files by now
- commit them now otherwise the release process will fail.
+
- B.6 Dry Run Your Maven Release
+ B.7 Dry Run Your Maven Release
Check that your poms will not lose content when they are rewritten during the
release process.
@@ -136, +148 @@
1. {{{mvn -Prc release:prepare}}}
1. {{{mvn -Prc release:perform}}}
-
- When the release plugin prompts for the tag name, choose the final name (for
example, {{{SCXML_0_9}}}).
-
- ''-- or --''
-
- i. Rev version number in pom manually.
-
- i. Tag the RC, do a clean checkout.
-
- i. {{{mvn -Prc deploy}}}
-
- i. {{{mvn -Prc site-deploy}}}
C.2 Remove SHA1 and MD5 Fingerprints of PGP Signatures
@@ -186, +186 @@
E.1 Copy to dist
- Copy distributions to the Commons {{{dist/}}} area which is located on
people.apache.org under /www/archive.apache.org/dist/commons
+ Copy distributions to the Commons {{{dist/}}} area which is located on
{{{people.apache.org}}} under {{{/www/www.apache.org/dist/commons}}}. The
content is also automatically copied to {{{archive.apache.org}}}
E.2 Copy Artifacts from Staging
@@ -200, +200 @@
-DtargetRepositoryId=apache.releases \
-Dversion=1.0
}}}
-
+
E.3 Deploy the Site
- Run {{{mvn site-deploy}}} to deploy the site - please note that you a
deploying the site of the next development snapshot.
+ Run {{{mvn site-deploy}}} to deploy the site - please note that you are
deploying the site of the next development snapshot.
=== F. Celebrate ===
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of CreatingReleases by SiegfriedGoeschl
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Commons Wiki for
change notification.
The following page has been changed by SiegfriedGoeschl:
http://wiki.apache.org/commons/CreatingReleases
--
=== F. Celebrate ===
+ F.1 Prepare Your Celebration
+
+ Make sure a couple of things
+
+ * check the project website (mirroring takes a while)
+ * check the projects download page and download your stuff
+ * check {{{http://www.apache.org/dist/commons}}} if your project shows up
+ * check {{{http://repo1.maven.org/maven2/}}} if your project artifacts are
available
+
- F.1 Send an Announcement
+ F.2 Send an Announcement
Send an announcement to the developer and user mailing list. Since you have
dutifully updated your {{{changes.xml}}} you can generate the announcement in
{{{./target/announcement/}}}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Patch for Compress-28
On 2009-03-26, Christian Grobmeier grobme...@gmail.com wrote: This should make sure that CPIO classes work like all the other classes. Thanks. I've moved the finish() call in close() inside the !closed branch since otherwise finish's ensureOpen would cause trouble for repeated calls to close (that the old code handled gracefully). Also I've moved the closeArchiveEntry method up to get a smaller diff. The tests didn't pass for me on Windows because of line-end differences (I guess), I've modified them to work for me and hopefully work on a system with a single character EOL, but I don't have such a system to confirm it right now. Could you please run the tests and close the issue after that? I intended to fix whitespace in CpioTestCase as a separate commit, but I saved the file while svn commit was running and it picked up my changes before I wanted it to (network isn't that fast at AC right now). Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Code history in NOTICE
Hi, The commons-compress NOTICE file currently contains the following entries: Original BZip2 classes contributed by Keiron Liddle kei...@aftexsw.com, Aftex Software to the Apache Ant project Original Tar classes from contributors of the Apache Ant project Original Zip classes from contributors of the Apache Ant project Original CPIO classes contributed by Markus Kuss and the jRPM project (jrpm.sourceforge.net) Since these are included in the NOTICE file, section 4.d of ALv2 requires that all downstream projects include a readable copy of that information. Is this something that we need to require, i.e. was this a requirement of the original contributions? If not, I'd rather move these notes to the README file. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Code history in NOTICE
On 2009-03-26, Jukka Zitting jukka.zitt...@gmail.com wrote: The commons-compress NOTICE file currently contains the following entries: Original BZip2 classes contributed by Keiron Liddle kei...@aftexsw.com, Aftex Software to the Apache Ant project Original Tar classes from contributors of the Apache Ant project Original Zip classes from contributors of the Apache Ant project Original CPIO classes contributed by Markus Kuss and the jRPM project (jrpm.sourceforge.net) Since these are included in the NOTICE file, section 4.d of ALv2 requires that all downstream projects include a readable copy of that information. Is this something that we need to require, i.e. was this a requirement of the original contributions? No explicit requirement from Keiron or his employer, something we did in Ant as a courtesy. There is no reason to keep the Ant references IMHO. I haven't been following the CPIO contribution close enough to know. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Successful use in Apache Tika
Hi, I just made a patch (see TIKA-204 [1]) to Apache Tika where I replaced our custom copies of the Ant classes with a proper dependency to commons-compress 1.0-SNAPSHOT. Everything works fine and I was even able to get rid of the extra customization we did for the bzip reader in Ant not wanting to see the first two bytes of the stream. So, apart from tweaking the NOTICE file (see my other message), from my perspective the current compress trunk is ready for release. :-) [1] https://issues.apache.org/jira/browse/TIKA-204 BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] potential bzip2 improvement
On Thu, Mar 26, 2009 at 12:36 PM, sebb seb...@gmail.com wrote: Would it be a silly idea to include both variants? I'd clearly tend to avoid that. It would likely cause confusion. On a related matter: Stefan, wouldn't it be possible for the others to start using compress? Jochen -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- (Bjarne Stroustrup, http://www.research.att.com/~bs/bs_faq.html#really-say-that My guess: Nokia E50) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Code history in NOTICE
On 26/03/2009, Stefan Bodewig bode...@apache.org wrote: On 2009-03-26, Jukka Zitting jukka.zitt...@gmail.com wrote: The commons-compress NOTICE file currently contains the following entries: Original BZip2 classes contributed by Keiron Liddle kei...@aftexsw.com, Aftex Software to the Apache Ant project Original Tar classes from contributors of the Apache Ant project Original Zip classes from contributors of the Apache Ant project Original CPIO classes contributed by Markus Kuss and the jRPM project (jrpm.sourceforge.net) Since these are included in the NOTICE file, section 4.d of ALv2 requires that all downstream projects include a readable copy of that information. Is this something that we need to require, i.e. was this a requirement of the original contributions? No explicit requirement from Keiron or his employer, something we did in Ant as a courtesy. There is no reason to keep the Ant references IMHO. +1 - one should not credit individual Apache projects. The file should be as short as possible, and it always mentions Apache anyway. I haven't been following the CPIO contribution close enough to know. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] potential bzip2 improvement
On 26/03/2009, Stefan Bodewig bode...@apache.org wrote: Hi folks, first of all I don't know enough about the bzip2 format to undestand the existing code, nor the one I'll be pointing at further down. The current code in compress is the one of Ant 1.7.1 and versions prior to 1.7.0. In Ant 1.7.0 Ant shipped with a completely rewritten version that was a lot faster https://issues.apache.org/bugzilla/show_bug.cgi?id=24798 Unfortunatly that version created corrupt archives under certain circumstances https://issues.apache.org/bugzilla/show_bug.cgi?id=41596 and the change was reverted in Ant 1.7.1. The Hadoop folks have been using the version of Ant 1.7.0, ran into the same corruption but had somebody around who actually understood the code and fixed it. So Ant's Bugzilla now contains a patch to BZip2OutputStream that has the potential to be a lot faster, isn't really any less understandable than the existing code (which is impossible anyway) and is claimed to be tested by Hadoop. Do we want to use Hadoop's code (provided it passes the existing unit tests) for the 1.0 release or do we want to stick to the current code and try an upgrade after the release? Since I understand neither code base, I don't really have any preference. Would it be a silly idea to include both variants? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] potential bzip2 improvement
On 26/03/2009, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Thu, Mar 26, 2009 at 12:36 PM, sebb seb...@gmail.com wrote: Would it be a silly idea to include both variants? I'd clearly tend to avoid that. It would likely cause confusion. Surely that depends on how well it is documented and on the API? I've not looked into it, but perhaps the implementation can be chosen at construction-time via a parameter. On a related matter: Stefan, wouldn't it be possible for the others to start using compress? Jochen -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- (Bjarne Stroustrup, http://www.research.att.com/~bs/bs_faq.html#really-say-that My guess: Nokia E50) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Compress] CpioConstants sort?
The definitions for the C_Ixxx constants are not fully sorted numerically (or alphabetically). Alphasorting is available in IDEs, so I'd like to sort on numerical value, as that makes it easier to check for omissions and duplicates. The current list is mainly in reverse numerical order, so I propose keeping that, but moving the few entries that are out of order. Any objections? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] potential bzip2 improvement
If the code has been tested by the folks at hadoop I trust it very much. (They do extensive testing!) and would be all for replacing the current code base. But IMO that's no blocker. In the end the algorithm should be a black box for everyone using compress. So changing this in a later release should be no problem. I would strongly argue against shipping two code bases for the same algorithm. It would cause more confusion than it would help IMO. On Thu, Mar 26, 2009 at 12:47, sebb seb...@gmail.com wrote: On 26/03/2009, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Thu, Mar 26, 2009 at 12:36 PM, sebb seb...@gmail.com wrote: Would it be a silly idea to include both variants? I'd clearly tend to avoid that. It would likely cause confusion. Surely that depends on how well it is documented and on the API? I've not looked into it, but perhaps the implementation can be chosen at construction-time via a parameter. On a related matter: Stefan, wouldn't it be possible for the others to start using compress? Jochen -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- (Bjarne Stroustrup, http://www.research.att.com/~bs/bs_faq.html#really-say-that My guess: Nokia E50) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] potential bzip2 improvement
On a related matter: Stefan, wouldn't it be possible for the others to start using compress? Not sure who the others may be. As for Ant, I don't expect it to move away from its own classes. Creating jars is a core requirement for a build tool for Java and the Ant community probably won't want to depend on an external library to do that (I know that I don't). I so don't get why you guys don't look into something like jarjar/minijar ...but that's a different story :) cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Successful use in Apache Tika
Awesome! That's good to hear! :) On Thu, Mar 26, 2009 at 12:09, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, I just made a patch (see TIKA-204 [1]) to Apache Tika where I replaced our custom copies of the Ant classes with a proper dependency to commons-compress 1.0-SNAPSHOT. Everything works fine and I was even able to get rid of the extra customization we did for the bzip reader in Ant not wanting to see the first two bytes of the stream. So, apart from tweaking the NOTICE file (see my other message), from my perspective the current compress trunk is ready for release. :-) [1] https://issues.apache.org/jira/browse/TIKA-204 BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Code history in NOTICE
I think the only requirement was to give credit ...somehow somewhere. On Thu, Mar 26, 2009 at 12:43, sebb seb...@gmail.com wrote: On 26/03/2009, Stefan Bodewig bode...@apache.org wrote: On 2009-03-26, Jukka Zitting jukka.zitt...@gmail.com wrote: The commons-compress NOTICE file currently contains the following entries: Original BZip2 classes contributed by Keiron Liddle kei...@aftexsw.com, Aftex Software to the Apache Ant project Original Tar classes from contributors of the Apache Ant project Original Zip classes from contributors of the Apache Ant project Original CPIO classes contributed by Markus Kuss and the jRPM project (jrpm.sourceforge.net) Since these are included in the NOTICE file, section 4.d of ALv2 requires that all downstream projects include a readable copy of that information. Is this something that we need to require, i.e. was this a requirement of the original contributions? No explicit requirement from Keiron or his employer, something we did in Ant as a courtesy. There is no reason to keep the Ant references IMHO. +1 - one should not credit individual Apache projects. The file should be as short as possible, and it always mentions Apache anyway. I haven't been following the CPIO contribution close enough to know. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Code history in NOTICE
I think the only requirement was to give credit ...somehow somewhere. This is true for CPIO. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Successful use in Apache Tika
Cool! On Thu, Mar 26, 2009 at 12:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, I just made a patch (see TIKA-204 [1]) to Apache Tika where I replaced our custom copies of the Ant classes with a proper dependency to commons-compress 1.0-SNAPSHOT. Everything works fine and I was even able to get rid of the extra customization we did for the bzip reader in Ant not wanting to see the first two bytes of the stream. So, apart from tweaking the NOTICE file (see my other message), from my perspective the current compress trunk is ready for release. :-) [1] https://issues.apache.org/jira/browse/TIKA-204 BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANN] commons-exec 1.0 released
The commons-exec-team is pleased to announce the commons-exec-1.0 release!
A library to reliably execute external processes from within the JVM
Changes in this version include:
New features:
-
o Added one additional test : DefaultExecutorTest.testExecuteWithFancyArg
Issue: EXEC-26. Thanks to Benjamin Bentmann.
o Added convinience method to add two parameters to the CommandLine
using one method invocation.
o Added test scripts for OpenVMS - he seems to be the last human having
access to an OpenVMS box ... :-)
o With the help of the Apache Commons community I added the first results
of cross-OS testing. Thanks to Simone Gianni, Bindul Bhowmik,
Niall Pemberton, Sebastian Bazley.
o The regression tests now also works on Windows - so it should
work now on Linux, Windows and Mac OS X
o Added DebugUtils to improve cross-platform testing.
o Made DefaultExecutor.launch() protected to enable mocking.
Issue: SANDBOX-62. Thanks to Jeremy Lacoste.
o Made ProcessDestroyer optional and pluggable when using Executor.
Issue: SANDBOX-107. Thanks to Niklas Gustavsson.
o CommandLine can now expand the given command line by a user-suppied
map. This allows to execute something like ${JAVA_HOME}/bin/java -jar
${myapp}
o Added methods to provide pre-quoted arguments.
Issue: SANDBOX-192. Thanks to Reinhold Fuereder.
o Exposing a ExecuteWatchdog.destroy() to kill an asynchrounous process
manually. This formalizes a workaround described in the JIRA
Issue: SANDBOX-193. Thanks to Reinhold Fuereder.
o Extending exit value handling to support applications returning an error
code. Issue: SANDBOX-203.
o Added a few regression tests for the watchdog since they were missing.
Issue: SANDBOX-204.
Fixed Bugs:
-
o Removed useless synchronized statement in
OpenVmsProcessingEnvironment.createProcEnvironment
Issue: EXEC-37. Thanks to Sebastien Bazley.
o Using System.in for child process will actually hang your application -
see JIRA for more details. Since there is no easy fix an
IllegalRuntimeException is thrown when System.in is passed.
Issue: EXEC-33.
o Fixing a few findbugs issues. Issue: EXEC-35. Thanks to Luc Maisonobe.
o Handle null streams consistently. Issue: EXEC-32. Thanks to Marco
Ferrante.
o After a long discussion we decided to stick to following groupId
org.apache.commons instead of commons-exec.
o The Ant build now works even when junit is not on the classpath
Thanks to Kevin Jackson.
o Fixed broken groupId from org.apache.commons to commons-exec
o Renamed EnvironmentUtil to EnvironmentUtils to align with other classes
in this project and commons in general. Please note that this change
could break existing clients (but would be rather unlikely).
Issue: EXEC-27. Thanks to Benjamin Bentmann.
o Make environment variables respect casing rules of platforms. Under
Windows
PATH, Path and path would access the same environment variable
whereas
the real name is Path. Issue: EXEC-30. Thanks to Benjamin Bentmann.
o Invoking DefaultExecutor.execute(CommandLine command, Map environment)
using
a 'null' Map results in inheriting all environment variables of the current
process while passing an empty map implies starting the new process
with no
environment variables. In short 'null' is not the same as an empty map.
Issue: EXEC-31. Thanks to Benjamin Bentmann.
o Using variable substitution within CommandLine broke the regression tests
under Windows. Found also another bug when calling
CommandLine.getExecutable()
the result was not substituted at all. As a general rule we do variable
substitution and file separator fixing on the command line executable and
variable substitution but NO file separator fixing for the command line
arguments. Issue: EXEC-25.
o Implemented better regression test for OpenVMS affecting also
the Executor and CommandLauncher interface.
o Cleaned up the source code to get rid of javadoc errors and
unused imports. Issue: SANDBOX-204.
Removed:
o Removed commons-logging integration
Have fun!
-commons-exec-team
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANN] commons-exec 1.0 released - Part 2
Hi Gary,
Source and binary distributions can be downloaded from the
corresponding directories in an Apache Software Foundation mirror at:
http://www.apache.org/dyn/closer.cgi/commons/exec
See also the download page at:
http://commons.apache.org/exec
Cheers,
Siegfried Goeschl
Gary Gregory wrote:
You should include links to the site and download area...
Gary
-Original Message-
From: Siegfried Goeschl [mailto:siegfried.goes...@it20one.at]
Sent: Thursday, March 26, 2009 11:35 AM
To: Jakarta Commons Developers List; Jakarta Commons Users List
Subject: [ANN] commons-exec 1.0 released
The commons-exec-team is pleased to announce the commons-exec-1.0 release!
A library to reliably execute external processes from within the JVM
Changes in this version include:
New features:
--
---
o Added one additional test : DefaultExecutorTest.testExecuteWithFancyArg
Issue: EXEC-26. Thanks to Benjamin Bentmann.
o Added convinience method to add two parameters to the CommandLine
using one method invocation.
o Added test scripts for OpenVMS - he seems to be the last human having
access to an OpenVMS box ... :-)
o With the help of the Apache Commons community I added the first results
of cross-OS testing. Thanks to Simone Gianni, Bindul Bhowmik,
Niall Pemberton, Sebastian Bazley.
o The regression tests now also works on Windows - so it should
work now on Linux, Windows and Mac OS X
o Added DebugUtils to improve cross-platform testing.
o Made DefaultExecutor.launch() protected to enable mocking.
Issue: SANDBOX-62. Thanks to Jeremy Lacoste.
o Made ProcessDestroyer optional and pluggable when using Executor.
Issue: SANDBOX-107. Thanks to Niklas Gustavsson.
o CommandLine can now expand the given command line by a user-suppied
map. This allows to execute something like ${JAVA_HOME}/bin/java -jar
${myapp}
o Added methods to provide pre-quoted arguments.
Issue: SANDBOX-192. Thanks to Reinhold Fuereder.
o Exposing a ExecuteWatchdog.destroy() to kill an asynchrounous process
manually. This formalizes a workaround described in the JIRA
Issue: SANDBOX-193. Thanks to Reinhold Fuereder.
o Extending exit value handling to support applications returning an error
code. Issue: SANDBOX-203.
o Added a few regression tests for the watchdog since they were missing.
Issue: SANDBOX-204.
Fixed Bugs:
--
---
o Removed useless synchronized statement in
OpenVmsProcessingEnvironment.createProcEnvironment
Issue: EXEC-37. Thanks to Sebastien Bazley.
o Using System.in for child process will actually hang your application -
see JIRA for more details. Since there is no easy fix an
IllegalRuntimeException is thrown when System.in is passed.
Issue: EXEC-33.
o Fixing a few findbugs issues. Issue: EXEC-35. Thanks to Luc Maisonobe.
o Handle null streams consistently. Issue: EXEC-32. Thanks to Marco
Ferrante.
o After a long discussion we decided to stick to following groupId
org.apache.commons instead of commons-exec.
o The Ant build now works even when junit is not on the classpath
Thanks to Kevin Jackson.
o Fixed broken groupId from org.apache.commons to commons-exec
o Renamed EnvironmentUtil to EnvironmentUtils to align with other classes
in this project and commons in general. Please note that this change
could break existing clients (but would be rather unlikely).
Issue: EXEC-27. Thanks to Benjamin Bentmann.
o Make environment variables respect casing rules of platforms. Under
Windows
PATH, Path and path would access the same environment variable
whereas
the real name is Path. Issue: EXEC-30. Thanks to Benjamin Bentmann.
o Invoking DefaultExecutor.execute(CommandLine command, Map environment)
using
a 'null' Map results in inheriting all environment variables of the
current
process while passing an empty map implies starting the new process
with no
environment variables. In short 'null' is not the same as an empty map.
Issue: EXEC-31. Thanks to Benjamin Bentmann.
o Using variable substitution within CommandLine broke the regression
tests
under Windows. Found also another bug when calling
CommandLine.getExecutable()
the result was not substituted at all. As a general rule we do variable
substitution and file separator fixing on the command line executable
and
variable substitution but NO file separator fixing for the command line
arguments. Issue: EXEC-25.
o Implemented better regression test for OpenVMS affecting also
the Executor and CommandLauncher interface.
o Cleaned up the source code to get rid of javadoc errors and
unused imports. Issue: SANDBOX-204.
Removed:
o Removed commons-logging integration
Have fun!
-commons-exec-team
-
To unsubscribe,
[Commons Wiki] Update of CommonsOsgi by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on Commons Wiki for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/commons/CommonsOsgi -- || cli || 1.1 || 1.2 || || || codec || 1.3 || || || || collections || 3.2 || 3.2.1|| [http://svn.apache.org/repos/asf/felix/trunk/commons/commons-collections/pom.xml Felix Bundle] doesn't import org.apache.commons.collections.* - asked on [http://felix.markmail.org/message/paqqbwyfcfhxz22f d...@felix] || + || compress|| - || || || || configuration || 1.5 || 1.6 || [http://svn.apache.org/repos/asf/felix/trunk/commons/commons-configuration/pom.xml Felix Bundle] uses alot of dynamic import || || daemon || 1.0.1 || || || || dbcp|| 1.2.2 || || || @@ -31, +32 @@ || discovery || 0.4 || || || || el || 1.0 || || || || email || 1.1 || || || + || exec|| - || 1.0 || || || fileupload || 1.2 || 1.2.1|| [http://felix.markmail.org/message/tgm45au3rpmpmfnf javax.portlet]|| || io || 1.3.2 || 1.4 || || || jci || 1.0 || || || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r758896 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/zip/
On 2009-03-26, bode...@apache.org wrote: support as much as possible of ZipFile as a stream can do in ZipArchiveInputStream, COMPRESS-47 This is Harmony's ZipInputStream combined with compress's parsing of the local file header - so we do get encoding support in ZipArchiveInputStream. I need to clean up the code a little but wanted to commit what I already have. Harmony's code would thrown an exception in closeEntry if an entry's checksum didn't match the specified one - I've skipped that since ZipFile doesn't verify it either. Even if we added the checks it would mean the exception was thrown when you try to read the entry after the broken one. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] Dependency on VFS
I fixed this. Please rebuild your VFS and give it another try. Ralph On Mar 25, 2009, at 2:19 PM, Oliver Heger wrote: Ralph Goers schrieb: On Mar 23, 2009, at 2:34 PM, Oliver Heger wrote: Hey, this really looks interesting! Unfortunately, I am pretty busy ATM and will need some time to grasp the concepts. However, I have now a build problem: Maven complains that it cannot find the vfs snapshot jar (see below). Do we need to add the snapshot repository to the pom? Yeah. I'm not crazy about adding the snapshot repo to the pom. It would only need to be there until the next release. At the moment VFS hasn't been published to the SNAPSHOT repo. I've been doing a mvn install of VFS on my local box before working on configuration. But until VFS has a release I guess the only decent option is to put the snapshot repo in the pom and publish the VFS snapshot. BTW - I haven't tried publishing anything to the snapshot repo before. Should I expect to have the necessary karma to do that? Also, I still have to add doc to the user guide. Hopefully, once I do that it will be a little easier to understand. Well, as a temporary solution we probably have to include the snapshot repository. Otherwise everybody who tries to build [configuration] from the sources will get a build error. I haven't published a jar to the snapshot repository either, so don't know about karma. I have now installed the vfs snapshot in my local repository. Compiling works fine, but I get a test failure: testNewFileReloading (org.apache.commons.configuration.reloading.TestVFSFileMon itorReloadingStrategy) The following exception is thrown: org.apache.commons.vfs.FileSystemException: URI D:\data\projects \OpenSource\commons-configuration\target is not an absolute file name. at org .apache .commons .vfs .provider .local .WindowsFileNameParser .extractWindowsRootPrefix(WindowsFileNameParser.java:81) at org .apache .commons .vfs .provider .local .WindowsFileNameParser.extractRootPrefix(WindowsFileNameParser.java: 39) at org .apache .commons .vfs .provider .local.LocalFileNameParser.parseUri(LocalFileNameParser.java:78) at org .apache .commons .vfs .provider.AbstractFileProvider.parseUri(AbstractFileProvider.java:170) at org .apache .commons .vfs .impl .DefaultFileSystemManager.resolveURI(DefaultFileSystemManager.java: 802) at org .apache .commons.configuration.VFSFileSystem.getPath(VFSFileSystem.java:197) at org .apache .commons .configuration .reloading .VFSFileMonitorReloadingStrategy .init(VFSFileMonitorReloadingStrategy.java:135) at org .apache .commons .configuration .AbstractFileConfiguration .setReloadingStrategy(AbstractFileConfiguration.java:765) at org .apache .commons .configuration .reloading .TestVFSFileMonitorReloadingStrategy .testNewFileReloading(TestVFSFileMonitorReloadingStrategy.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org .eclipse .jdt .internal .junit .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org .eclipse .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org .eclipse .jdt .internal .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org .eclipse .jdt .internal .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org .eclipse .jdt .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org .eclipse .jdt .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java: 196) I suspect this is a Windows-specific issue. Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
