Re: Re: Re: [compress] Draft 8
The grants has been received by Jim. I've merged the changes from Chris into my working copy of compress ...any objections to do a svn commit ? :-) Ok I will go ahead and commit it then :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great :-) I am eager to do this delete stuff on top of this. - - Chris Torsten Curdt wrote: The grants has been received by Jim. I've merged the changes from Chris into my working copy of compress ...any objections to do a svn commit ? :-) Ok I will go ahead and commit it then :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzeLgkv8rKBUE/T4RAn8HAJ9u6kYi06o47y8EvYX7nTvkugepyQCfYU89 h22qHIZ93+9vAYGpKu3nVjw= =ERsT -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection
On 7/29/06, Oliver Zeigermann oliver.zeigermann at gmail.com wrote: Finally there is the third release candidate at http://people.apache.org/~ozeigermann/tx-1.2rc3/ From a functionality POV it works for me. Regarding JDK 1.3 ([1]): How did you solve the problem with the J2EE/Geronimo jars? Did you recompile them? Rahul Akolkar rahul.akolkar at gmail.com writes: * Why are the dependencies (the lib folder) included in both distros? I'd prefer that they aren't, is there any particular reason why [transaction] does that? The main build process uses ant which requires these libraries. snip/ I'm not in favor of distributing deps along with Commons libraries' distributions. * Its straightforward to provide an ant target to download the deps. In contrast to this I prefer to deliver the dependencies as well. There are rumours about companies that don't provide direct access to the internet from the employee's PCs, but only via a terminal server (Unfortunately, I'm working for such a company). The problem is simply that those people can't use such download tasks or Maven. If you don't deliver the dependencies they have to run after each single jar. Even for Apache Cocoon (which has a huge list of dependencies) we will provide a distribution including the dependencies. * Distribution of (potentially) 3rd party binaries (as an example, JUnit, in this case) means we have to understand their licenses (by refering to the ASF legal docs), determine reciprocity requirements as needed etc. No bang for the buck here. It has worked for years. Why shouldn't it work further on? * The source distro contains the jar -- which I wouldn't expect to be there. Yes, this is superfluous IMO as well. And as a minor nit, there are 7 odd Javadoc warnings. I recently fixed some of them: [2]. When I did this I did not find any worth to be fixed. Cheers, Jörg [1] http://thread.gmane.org/gmane.comp.jakarta.commons.devel/86451/focus=86451 [2] http://svn.apache.org/viewvc?view=revrevision=47 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection
2006/7/31, Joerg Heinicke [EMAIL PROTECTED]: On 7/29/06, Oliver Zeigermann oliver.zeigermann at gmail.com wrote: Finally there is the third release candidate at http://people.apache.org/~ozeigermann/tx-1.2rc3/ From a functionality POV it works for me. Regarding JDK 1.3 ([1]): How did you solve the problem with the J2EE/Geronimo jars? Did you recompile them? I compiled against Suns J2EE jar which was compiled using JDK 1.3. I still include Geronimo jars as Suns jars are not license compatible. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Net] FTPFile.getTimestamp() returns incorrect year
Hi, this is forwarded from user list. Does anybody know how to solve this problem? Regards, Lukas -- Forwarded message -- Hi, I found that FTPFile.getTimestamp() returns incorrect year. I have a file which was created on 2006-07-28 but getTimestamp() method returns 2005-07-28. Does anybody know any workaround? Is there fixed version available yet? Thanks, Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-31072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-31072006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-31072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-31072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-31072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-31072006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[Jakarta-commons Wiki] Update of FrontPage by ChristianGrobmeier
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by ChristianGrobmeier: http://wiki.apache.org/jakarta-commons/FrontPage -- * [:Id] - Generators for identifiers * [:CommonsCsv] - Proposed new component * [:Metadata] - Proposed new component which provides a class metadata API similar to that of JDK5 + * [:Compress] - Defines an API for working with tar, zip and bzip2 files - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Trivial Update of Compress by ChristianGrobmeier
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by ChristianGrobmeier: http://wiki.apache.org/jakarta-commons/Compress New page: ##language:en = Component Overview = Compress is an API for working with tar, zip and bzip2 files. = External Resources = ||Do you have a good example, add it here!|| = FAQ = ||Add your questions/answers here.|| = TODO = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Trivial Update of Compress by ChristianGrobmeier
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki
for change notification.
The following page has been changed by ChristianGrobmeier:
http://wiki.apache.org/jakarta-commons/Compress
The comment on the change is:
formatted code snippets
--
To pack an archive, you have to get an archiver via the ArchiverFactory. At
the moment it's possible to get a zip or a tar archiver. Add your files to
the archiver and call save to store the archive.
=== Packing a ZIP-File ===
- Archive archiver = ArchiverFactory.getInstance(zip);
+ {{{Archive archiver = ArchiverFactory.getInstance(zip);
archiver.add( new File(C:\\Temp\\1.html));
archiver.add( new File(C:\\Temp\\1.html.bz2));
- archiver.save( new File(C:\\Temp\\ZIPTEST.zip));
+ archiver.save( new File(C:\\Temp\\ZIPTEST.zip));}}}
=== Unpacking a ZIP-File ===
- Archive archiver = ArchiverFactory.getInstance(
+ {{{Archive archiver = ArchiverFactory.getInstance(
new File(C:\\Temp\\ZIPTEST.zip));
- archiver.unpack( new File(C:\\Temp\\unpacked\\));
+ archiver.unpack( new File(C:\\Temp\\unpacked\\));}}}
== Compressor ==
Same goes for Compressor. At the moment there is only bz2 support.
=== Compressing a file ===
- Compressor compressor;
+ {{{Compressor compressor;
compressor = CompressorFactory.getInstance(bz2);
- compressor.compressToHere( new File(C:\\Temp\\test.tar));
+ compressor.compressToHere( new File(C:\\Temp\\test.tar));}}}
=== Decompressing a file ===
- Compressor decompressor;
+ {{{Compressor decompressor;
decompressor = CompressorFactory.getInstance(bz2);
decompressor.decompressTo( new
File(C:\\Temp\\asf-logo-huge.tar.bz2),
- new
File(C:\\Temp\\asf-logo-huge.tar));
+ new
File(C:\\Temp\\asf-logo-huge.tar));}}}
= FAQ =
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Net] FTPFile.getTimestamp() returns incorrect year
Hi,
Let's elaborate this questions a little more. When I do the follwoing
then it works as expected:
#1) ==
Calendar cal = null;
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
parser.configure(UnixFTPEntryParser.NUMERIC_DATE_CONFIG);
try {
cal = parser.parseTimestamp(2006-07-03 22:52);
} catch (Throwable e) {
fail(e.getMessage());
}
System.out.println(cal.getTime());
Now the question is if this is exactly the same what will happen
behind the scene if I do the following:
#2) ==
FTPClient client = new
FTPClient();client.configure(UnixFTPEntryParser.NUMERIC_DATE_CONFIG);
FTPFile[] allFiles = client.listFiles(folder);
Because not the particualr FTPFiles.getTimestamp() would lead to 2005
year instead of 2006. Do I need to perform additional configuration
setting in the second case?
Regards,
Lukas
On 7/31/06, Lukas Vlcek [EMAIL PROTECTED] wrote:
Hi, this is forwarded from user list. Does anybody know how to solve
this problem?
Regards,
Lukas
-- Forwarded message --
Hi,
I found that FTPFile.getTimestamp() returns incorrect year.
I have a file which was created on 2006-07-28 but getTimestamp()
method returns 2005-07-28.
Does anybody know any workaround?
Is there fixed version available yet?
Thanks,
Lukas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][modeler] Promote 2.0 RC1 to 2.0 Final (was Re: [modeler] 2.0 RC1 ready for review)
My previous reply went direct to dims, instead of to this list. Here's my +1. --kevan On Jul 25, 2006, at 9:40 AM, Davanum Srinivas wrote: Thanks Rahul, will keep those in mind for the next time around. Team, Could i get some votes to promote the 2.0 RC1 to 2.0 Final? Here's my +1 to get the ball rolling. thanks, dims On 7/22/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/21/06, Davanum Srinivas [EMAIL PROTECTED] wrote: One more rev folks..Changed the version to 2.0 because of the incompatible api change. Also please note that the minimum jdk version is 1.3. http://people.apache.org/~dims/commons-modeler-2.0-RC1/ snip/ Looks good: * Sigs, md5s pan out * Source distro jars,sites,dists * jar/manifest looks ok Nits (not blockers, IMO): * POM and jar md5s not in recommended format * We should aim to have all component sites display docs for latest 3 (?) releases -Rahul thanks, dims snap/ -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427134 - in /jakarta/commons/proper/modeler/trunk: build.xml project.xml
Author: dims Date: Mon Jul 31 08:06:22 2006 New Revision: 427134 URL: http://svn.apache.org/viewvc?rev=427134view=rev Log: prepare for 2.0 final release Modified: jakarta/commons/proper/modeler/trunk/build.xml jakarta/commons/proper/modeler/trunk/project.xml Modified: jakarta/commons/proper/modeler/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/build.xml?rev=427134r1=427133r2=427134view=diff == --- jakarta/commons/proper/modeler/trunk/build.xml (original) +++ jakarta/commons/proper/modeler/trunk/build.xml Mon Jul 31 08:06:22 2006 @@ -53,7 +53,7 @@ property name=component.title value=Model MBeans Support Package/ !-- The current version number of this component -- - property name=component.version value=1.2-dev/ + property name=component.version value=2.0/ !-- The base directory for compilation targets -- property name=build.home value=target/ Modified: jakarta/commons/proper/modeler/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/project.xml?rev=427134r1=427133r2=427134view=diff == --- jakarta/commons/proper/modeler/trunk/project.xml (original) +++ jakarta/commons/proper/modeler/trunk/project.xml Mon Jul 31 08:06:22 2006 @@ -22,7 +22,7 @@ nameCommons Modeler/name groupIdcommons-modeler/groupId artifactIdcommons-modeler/artifactId - currentVersion2.0-RC1/currentVersion + currentVersion2.0/currentVersion inceptionYear2002/inceptionYear shortDescriptionCommons Modeler/shortDescription description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427136 - /jakarta/commons/proper/modeler/trunk/build.xml
Author: dims Date: Mon Jul 31 08:07:31 2006 New Revision: 427136 URL: http://svn.apache.org/viewvc?rev=427136view=rev Log: one more spot to update version # Modified: jakarta/commons/proper/modeler/trunk/build.xml Modified: jakarta/commons/proper/modeler/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/build.xml?rev=427136r1=427135r2=427136view=diff == --- jakarta/commons/proper/modeler/trunk/build.xml (original) +++ jakarta/commons/proper/modeler/trunk/build.xml Mon Jul 31 08:07:31 2006 @@ -316,8 +316,8 @@ !-- == Release Targets = -- target name=release description=Create the release -property name=ver value=1.2-dev / -property name=tag value=MODELER_1_2_DEV / +property name=ver value=2.0 / +property name=tag value=MODELER_2_0_DEV / delete dir=release / mkdir dir=release / cvs command=checkout - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Project restart ?
I'd be happy to donate a little time, if someone could give a report on what the current state of the project is and what needs to be done. Data conversion is a significant issue where I work. Kris Andres Almiray wrote: Hi, Is anyone interested in restarting the project ? Following https://issues.apache.org/jira/browse/LANG-274, Henri Yandell expressed interest in allowing multidimensional array conversions for ArrayUtils, we agreed that a patch fo ArrayUtils would be too large and that it would be best to try a restart on the commons-convert project. Please let me know what you think about it. --- Ing. Andres Almiray Jaramillo http://jroller.com/page/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. ___ Do You Yahoo!? La mejor conexión a Internet y b 2GB/b extra a tu correo por $100 al mes. http://net.yahoo.com.mx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426813 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/ test/org/apache/commons/configuration/
On 7/30/06, Oliver Heger [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 7/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: oheger Date: Sat Jul 29 07:52:31 2006 New Revision: 426813 URL: http://svn.apache.org/viewvc?rev=426813view=rev Log: Fixed some problems JDK 1.3 had with our classes snip/ Can you post the trace? (not that its guaranteed to help, but worth a shot -- if we can make any recommendation to JDK 1.3 users). -Rahul Okay, here is the exception trace: Testcase: testParse(org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader): Caused an ERROR null java.lang.NoSuchMethodError at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:329) at org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader.testParse(TestHierarchicalConfigurationXMLReader.java:58) Maybe it's just a problem with my setup. I did some digging, but was unable to solve the problem. For instance I tried newer versions of Xerces or xmlapis or checked the JDK1.3 directory structure for other included XML parsers - without success. snap/ The method in question apparently has existed ever since xalan2 came about (my guess would have been there is some version xalan1 in lib/ext, but you've tried all that). As a side note, xalan 2.6.0 - 2.7.0 is generally considered a bigger leap, so I've left [scxml] at 2.6.0 (its closer to what JDK 1.4 had built in, so the 1.4 user has less reason to need the endorsed standards override mechanism, and cause any errors therein) -- but since [configuration] has had atleast one prior release with a xalan 2.7.0 dep (are we using any 2.7.0 specific stuff?), maybe the xerces version also should be upgraded? (2.7.0 has been tested with xerces 2.7.1). *Sigh*, cross-JDK compatibilities for XML processing continues to be a pain point, IMO. -Rahul Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection
On 7/30/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: 2006/7/30, Rahul Akolkar [EMAIL PROTECTED]: snip/ IMO: * Its straightforward to provide an ant target to download the deps. Oh. I am ignorant. Did not know that. How does this work? That might be an option. snap/ The [scxml] (m1 generated) build.xml is an example, or any other m1 generated component ant build files too (build grabs deps from ibiblio). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection
On 7/31/06, Joerg Heinicke [EMAIL PROTECTED] wrote: snip/ Rahul Akolkar rahul.akolkar at gmail.com writes: snap/ I'm not in favor of distributing deps along with Commons libraries' distributions. * Its straightforward to provide an ant target to download the deps. In contrast to this I prefer to deliver the dependencies as well. There are rumours about companies that don't provide direct access to the internet from the employee's PCs, but only via a terminal server (Unfortunately, I'm working for such a company). The problem is simply that those people can't use such download tasks or Maven. If you don't deliver the dependencies they have to run after each single jar. Even for Apache Cocoon (which has a huge list of dependencies) we will provide a distribution including the dependencies. snip/ Yes, it is more effort for the end user (to download the deps individually), but I remain unconvinced this is the right way to proceed for Commons libraries (I'm aware a lot of frameworks do such a thing). * Distribution of (potentially) 3rd party binaries (as an example, JUnit, in this case) means we have to understand their licenses (by refering to the ASF legal docs), determine reciprocity requirements as needed etc. No bang for the buck here. It has worked for years. Why shouldn't it work further on? snap/ This is not about their use, rather their distribution in our release distros. Atleast I haven't seen such a modus operandi in the RCs I've looked at recently. Going one step ahead, it'd be nice IMO, if the lib directory in the [transaction] SVN repository also disappeared. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all][discovery] m1-ibiblio-rsync-repository
(moved from user list) On 7/31/06, Gilles Tabary [EMAIL PROTECTED] wrote: Hello. I am building an ear with Maven2. I need commons-discovery-0.2-dev.jar snip/ There is a http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-discovery/jars/commons-discovery-0.2-dev.jar but I am not sure at all that is the reference thingy to be used. snap/ Quick true or false question: Regardless of what has been done before, the m1-ibiblio-rsync-repository should not contain snapshots. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][modeler] Promote 2.0 RC1 to 2.0 Final (was Re: [modeler] 2.0 RC1 ready for review)
On 7/30/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Rahul, i am going to leave the build.xml.* around for this time...I use the maven1 properties (maven.compile.source and maven.compile.target) to set the jdk version to 1.3. I will fix the build.xml. snip/ Depending upon the transitive closure of 1.3 methods in [modeler], just that may or may not be sufficient. There have been some discussions on this, but unfortunately I can't locate them in the archives ATM (sorry!). Building the binaries with the minimum JDK that the component supports is probably considered safer (and I'm not sure how to do that with m1 -- which is why I asked). -Rahul thanks, dims On 7/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snap/ For my own understanding -- are you cutting RCs using ant or maven (for Java compilation)? If m1, how do you ensure JDK 1.3 compat? I know there is a bootclasspath setting in the m2 compiler plugin, but I haven't had the need to figure out the m1 bits yet. I tried to look at the [modeler] POM for clues. -Rahul snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][modeler] Promote 2.0 RC1 to 2.0 Final (was Re: [modeler] 2.0 RC1 ready for review)
Rahul, Let's do this now. If we find a problem, i can spin a 2.1 real quick. thanks, dims On 7/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/30/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Rahul, i am going to leave the build.xml.* around for this time...I use the maven1 properties (maven.compile.source and maven.compile.target) to set the jdk version to 1.3. I will fix the build.xml. snip/ Depending upon the transitive closure of 1.3 methods in [modeler], just that may or may not be sufficient. There have been some discussions on this, but unfortunately I can't locate them in the archives ATM (sorry!). Building the binaries with the minimum JDK that the component supports is probably considered safer (and I'm not sure how to do that with m1 -- which is why I asked). -Rahul thanks, dims On 7/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snap/ For my own understanding -- are you cutting RCs using ant or maven (for Java compilation)? If m1, how do you ensure JDK 1.3 compat? I know there is a bootclasspath setting in the m2 compiler plugin, but I haven't had the need to figure out the m1 bits yet. I tried to look at the [modeler] POM for clues. -Rahul snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][modeler] Promote 2.0 RC1 to 2.0 Final (was Re: [modeler] 2.0 RC1 ready for review)
On 7/31/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Rahul, Let's do this now. If we find a problem, i can spin a 2.1 real quick. snip/ I'm fine with that (since you're doing all the work on the [modeler] release -- thanks for that, BTW). -Rahul thanks, dims snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration]First release candidate for 1.3 release
On 7/30/06, Oliver Heger [EMAIL PROTECTED] wrote: The Commons Configuration team is pleased to announce the availability of the first release candidate of the upcoming 1.3 release. The files can be found for inspection at http://people.apache.org/~oheger/commons-configuration-1.3rc1/ snip/ Any feedback is welcome! snap/ Haven't looked at the RC in detail yet, but before I forget -- what about the groupId? Was there any conclusion to the maven relocation thread? Perhaps its best to revert to commons-configuration for 1.3. -Rahul Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427230 - /jakarta/commons/proper/modeler/tags/MODELER_2_0/
Author: dims Date: Mon Jul 31 12:39:27 2006 New Revision: 427230 URL: http://svn.apache.org/viewvc?rev=427230view=rev Log: tag Modeler 2.0 release. Added: jakarta/commons/proper/modeler/tags/MODELER_2_0/ - copied from r427229, jakarta/commons/proper/modeler/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][discovery] m1-ibiblio-rsync-repository
On 7/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: (moved from user list) On 7/31/06, Gilles Tabary [EMAIL PROTECTED] wrote: Hello. I am building an ear with Maven2. I need commons-discovery-0.2-dev.jar snip/ There is a http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-discovery/jars/commons-discovery-0.2-dev.jar but I am not sure at all that is the reference thingy to be used. snap/ Quick true or false question: Regardless of what has been done before, the m1-ibiblio-rsync-repository should not contain snapshots. True. I've a script that looks for such things, but haven't gotten around to hooking it up to notifying people of problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration]First release candidate for 1.3 release
Rahul Akolkar wrote: On 7/30/06, Oliver Heger [EMAIL PROTECTED] wrote: The Commons Configuration team is pleased to announce the availability of the first release candidate of the upcoming 1.3 release. The files can be found for inspection at http://people.apache.org/~oheger/commons-configuration-1.3rc1/ snip/ Any feedback is welcome! snap/ Haven't looked at the RC in detail yet, but before I forget -- what about the groupId? Was there any conclusion to the maven relocation thread? Perhaps its best to revert to commons-configuration for 1.3. -Rahul I've been busy over at the maven community, asking questions and trying to document [1] the proper procedure for doing this. So now it's just a matter of doing the work. Remaining steps: * Complete the changing of groupId in all project.xml files * Follow the procedure for relocation I'm available to help do this. My suggestion is that we start with one component and see that all goes well. Configuration might be the one. [1] http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Project restart ?
(and then I promptly picked up a stomach bug and my weekend was a waste of time). On 7/28/06, Henri Yandell [EMAIL PROTECTED] wrote: I'll send some thoughts at the w/e - I've been afk for most of the week at oscon. Hen On 7/28/06, Andres Almiray [EMAIL PROTECTED] wrote: Hi, Is anyone interested in restarting the project ? Following https://issues.apache.org/jira/browse/LANG-274, Henri Yandell expressed interest in allowing multidimensional array conversions for ArrayUtils, we agreed that a patch fo ArrayUtils would be too large and that it would be best to try a restart on the commons-convert project. Please let me know what you think about it. --- Ing. Andres Almiray Jaramillo http://jroller.com/page/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. ___ Do You Yahoo!? La mejor conexión a Internet y b 2GB/b extra a tu correo por $100 al mes. http://net.yahoo.com.mx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r426813 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/ test/org/apache/commons/configuration/
Rahul Akolkar wrote: snip/ snap/ The method in question apparently has existed ever since xalan2 came about (my guess would have been there is some version xalan1 in lib/ext, but you've tried all that). As a side note, xalan 2.6.0 - 2.7.0 is generally considered a bigger leap, so I've left [scxml] at 2.6.0 (its closer to what JDK 1.4 had built in, so the 1.4 user has less reason to need the endorsed standards override mechanism, and cause any errors therein) -- but since [configuration] has had atleast one prior release with a xalan 2.7.0 dep (are we using any 2.7.0 specific stuff?), maybe the xerces version also should be upgraded? (2.7.0 has been tested with xerces 2.7.1). *Sigh*, cross-JDK compatibilities for XML processing continues to be a pain point, IMO. -Rahul Hi Rahul, thanks for having a look at this. We do not use any specific features of xalan 2.7.0. There is one transform() call in XMLConfiguration for writing the DOM to a file, which works without problems. The two test classes that cause trouble try to transform a SAX source into a DOM. I can test other versions in the next few days. And yes: it is a pain! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration]First release candidate for 1.3 release
Dennis Lundberg wrote: Rahul Akolkar wrote: On 7/30/06, Oliver Heger [EMAIL PROTECTED] wrote: The Commons Configuration team is pleased to announce the availability of the first release candidate of the upcoming 1.3 release. The files can be found for inspection at http://people.apache.org/~oheger/commons-configuration-1.3rc1/ snip/ Any feedback is welcome! snap/ Haven't looked at the RC in detail yet, but before I forget -- what about the groupId? Was there any conclusion to the maven relocation thread? Perhaps its best to revert to commons-configuration for 1.3. -Rahul I've been busy over at the maven community, asking questions and trying to document [1] the proper procedure for doing this. So now it's just a matter of doing the work. Remaining steps: * Complete the changing of groupId in all project.xml files * Follow the procedure for relocation I'm available to help do this. My suggestion is that we start with one component and see that all goes well. Configuration might be the one. [1] http://maven.apache.org/guides/mini/guide-relocation.html I probably won't have too much time in the next days. But if you want to try some things out, just go ahead. Thanks Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][discovery] m1-ibiblio-rsync-repository
That commons-discovery-0.2-dev.jar looks like a snapshot to me On 7/31/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: (moved from user list) On 7/31/06, Gilles Tabary [EMAIL PROTECTED] wrote: Hello. I am building an ear with Maven2. I need commons-discovery-0.2-dev.jar snip/ There is a http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-discovery/jars/commons-discovery-0.2-dev.jar but I am not sure at all that is the reference thingy to be used. snap/ Quick true or false question: Regardless of what has been done before, the m1-ibiblio-rsync-repository should not contain snapshots. True. I've a script that looks for such things, but haven't gotten around to hooking it up to notifying people of problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On 7/28/06, James Carman [EMAIL PROTECTED] wrote: Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: I've been meaning to ask... is there really much reason for a JDK 1.4+ application/library to depend on commons-logging? Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking about 1.4 so we can drop the commons-logging dependencies? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] Project restart ?
Ugh! I hope you feel better by now. In the meantime I've been reshaping the original code from json-lib to be more friendly. There were too many array converters; now there are the 9 array converters only: 8 primitive and 1 generic (works with any converter). The last statement on the ObjectArrayConverter is not exactly true, it works on any converter that does not convert to an array class. The other 8 are needed because int[].class != Integer[].class, an so on. I've included the other Conversion/Convert components in the dormant repository. --- Henri Yandell [EMAIL PROTECTED] escribió: (and then I promptly picked up a stomach bug and my weekend was a waste of time). On 7/28/06, Henri Yandell [EMAIL PROTECTED] wrote: I'll send some thoughts at the w/e - I've been afk for most of the week at oscon. Hen On 7/28/06, Andres Almiray [EMAIL PROTECTED] wrote: Hi, Is anyone interested in restarting the project ? Following https://issues.apache.org/jira/browse/LANG-274, Henri Yandell expressed interest in allowing multidimensional array conversions for ArrayUtils, we agreed that a patch fo ArrayUtils would be too large and that it would be best to try a restart on the commons-convert project. Please let me know what you think about it. --- Ing. Andres Almiray Jaramillo http://jroller.com/page/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. ___ Do You Yahoo!? La mejor conexión a Internet y b 2GB/b extra a tu correo por $100 al mes. http://net.yahoo.com.mx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Ing. Andres Almiray Jaramillo http://jroller.com/page/aalmiray -- What goes up, must come down. Ask any system administrator. There are 10 types of people in the world: Those who understand binary, and those who don't. To understand recursion, we must first understand recursion. ___ Do You Yahoo!? La mejor conexión a Internet y b 2GB/b extra a tu correo por $100 al mes. http://net.yahoo.com.mx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Confluence and Jira client libraries
I made a couple libraries for manipulating Confluence and Jira via their XML-RPC front-ends. Currently, I have them sitting here: http://svn.codehaus.org/swizzle/trunk/swizzle-confluence/ http://svn.codehaus.org/swizzle/trunk/swizzle-jira/ Examples: http://docs.codehaus.org/display/SWIZZLE/Swizzle+Confluence http://docs.codehaus.org/display/SWIZZLE/Swizzle+Jira I created these libraries by generating them with perl based on the XML-RPC defs for the respective xml-rpc services. I'm thinking here might be a better home than my little project at Codehaus simply because at commons there'd be like 100+ people who'd have access to improve the library as opposed to just me. So anyway, is this something people would like? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons Modeler 2.0 Released
Folks, The Commons Modeler team is pleased to announce the final release of Commons Modeler 2.0. The Modeler component of the Jakarta Commons subproject offers convenient support for configuring and instantiating Model MBeans (management beans), as described in the JMX Specification. The binary distribution is available at: http://jakarta.apache.org/site/binindex.cgi and the source distribution is available at: http://jakarta.apache.org/site/sourceindex.cgi When downloading from a mirror site, please remember to verify the signatures of the distribution using the keys found on the main Apache web site: http://www.apache.org/dist/jakarta/commons/modeler/KEYS For more information on Commons Modeler, see the Modeler web site: http://jakarta.apache.org/commons/modeler/ API CHANGES: o In org.apache.commons.modeler.BaseModelMBean, getObjectName's method signature was as follows: public javax.management.ObjectName getObjectName() Now it has been changed to public String getObjectName() NOTE: This was not logged as a modeler bug. More information can be found at the Sun Bug Database: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909041 o In org.apache.commons.modeler.BaseModelMBean, Folks who need the ObjectName can now use the new method: public javax.management.ObjectName getJmxName() NOTE: This was not logged as a modeler bug. More information can be found at the Sun Bug Database: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909041 o In org.apache.commons.modeler.util.IntrospectionUtils, A new method clear has been added: public void clear() NOTE: This was done as part of fix for MODELER-15 BUG REPORTS ADDRESSED: = o MODELER-18 support for general descriptors o MODELER-17 [modeler] MbeansSource don't use args at mbeans and operations o MODELER-16 [modeler] download links broken o MODELER-15 [modeler] IntrospectionUtils memory leak o MODELER-14 After setting an Attribute the Notification Listener will not performed o MODELER-13 [modeler] BaseModelMBean class setModeledType method should be setModelerType o MODELER-12 [modeler] ManagedBean uses the wrong case for ObjectReference o MODELER-11 [modeler] Null Pointer Exception - Non-Singleton Registry o MODELER-10 [modeler] DTD violation when using simple wrapping o MODELER-9 [modeler] Registry.convertValue doesn't support longs o MODELER-8 [modeler] AttributeChangeNotification sent before attribute changes o MODELER-7 sendAttributeChangeNotification on setAttribute o MODELER-6 [modeler] wiki page is immutable and out-of-date o MODELER-5 [modeler] setServer stack overflow o MODELER-4 [modeler] Overloaded operations throw wrong number of parameters exception o MODELER-3 [modeler] maven build fails on os x with test failure. o MODELER-2 [modeler] Registry insufficiently synchronized o MODELER-1 ClassNotFoundException while using the Notification -- dims PS: Please wait a bit for the web site and mirrors to catch up :) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427287 - in /jakarta/commons/proper/modeler/trunk: build.xml project.xml
Author: dims Date: Mon Jul 31 14:28:04 2006 New Revision: 427287 URL: http://svn.apache.org/viewvc?rev=427287view=rev Log: updating versions after 2.0 final release Modified: jakarta/commons/proper/modeler/trunk/build.xml jakarta/commons/proper/modeler/trunk/project.xml Modified: jakarta/commons/proper/modeler/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/build.xml?rev=427287r1=427286r2=427287view=diff == --- jakarta/commons/proper/modeler/trunk/build.xml (original) +++ jakarta/commons/proper/modeler/trunk/build.xml Mon Jul 31 14:28:04 2006 @@ -53,7 +53,7 @@ property name=component.title value=Model MBeans Support Package/ !-- The current version number of this component -- - property name=component.version value=2.0/ + property name=component.version value=2.1-dev/ !-- The base directory for compilation targets -- property name=build.home value=target/ @@ -316,8 +316,8 @@ !-- == Release Targets = -- target name=release description=Create the release -property name=ver value=2.0 / -property name=tag value=MODELER_2_0_DEV / +property name=ver value=2.1-dev / +property name=tag value=MODELER_2_1_DEV / delete dir=release / mkdir dir=release / cvs command=checkout Modified: jakarta/commons/proper/modeler/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/project.xml?rev=427287r1=427286r2=427287view=diff == --- jakarta/commons/proper/modeler/trunk/project.xml (original) +++ jakarta/commons/proper/modeler/trunk/project.xml Mon Jul 31 14:28:04 2006 @@ -22,7 +22,7 @@ nameCommons Modeler/name groupIdcommons-modeler/groupId artifactIdcommons-modeler/artifactId - currentVersion2.0/currentVersion + currentVersion2.1-dev/currentVersion inceptionYear2002/inceptionYear shortDescriptionCommons Modeler/shortDescription description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Tapestry and JCL
On Mon, 2006-07-31 at 13:08 -0700, Henri Yandell wrote: On 7/28/06, James Carman [EMAIL PROTECTED] wrote: Tapestry is thinking of switching to SL4J instead of Jakarta Commons Logging: I've been meaning to ask... is there really much reason for a JDK 1.4+ application/library to depend on commons-logging? Sure you could argue that log4j is more powerful, but the same could be said of ORO. Increasingly people just aren't going to care. We're starting to talk about moving to 1.3 so we can get the regexp support without a dependency ([io] for example), when do we start talking about 1.4 so we can drop the commons-logging dependencies? If I were writing a 1.4+ library or app, I'd just use java.util.logging directly. Which reminds me: is the JULI implementation of the java.util.logging API (used in tomcat) available as an independent library? If not, maybe it is worth extracting it as a project of the logging.apache.org group? Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager
Improve relationship between ResourceManager and FileResourceManager Key: TRANSACTION-11 URL: http://issues.apache.org/jira/browse/TRANSACTION-11 Project: Commons Transaction Issue Type: Improvement Affects Versions: 1.1, 1.2 Reporter: Jeremy Fujimoto-Johnson Add the reset method to ResourceManager so that classes using a ResourceManager won't have to cast it to FileResourceManager to call this method. Add new constructors to FileResourceManager so that it can be constructed with the default timeout period for transactions already specified so that you don't have to cast to FileResourceManager to set it later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons SCXML 0.5 Released
The Apache Jakarta project would like to announce the release of Commons SCXML 0.5. This is the first release. State Chart XML (SCXML) is currently a Working Draft published by the World Wide Web Consortium (W3C). SCXML provides a generic state-machine based execution environment. Commons SCXML provides a Java implementation of the SCXML engine. Anything that can be represented as a UML state chart -- business process flows, view navigation bits, interaction or dialog management, and many more -- can leverage the Commons SCXML library. Commons SCXML is available in either binary or source form from the following download page - http://jakarta.apache.org/site/downloads/downloads_commons-scxml.cgi See the Release Notes link on the above page for information on API stability. -Rahul Akolkar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Confluence and Jira client libraries
I made a couple libraries for manipulating Confluence and Jira via their XML-RPC front-ends. Currently, I have them sitting here: http://svn.codehaus.org/swizzle/trunk/swizzle-confluence/ http://svn.codehaus.org/swizzle/trunk/swizzle-jira/ Examples: http://docs.codehaus.org/display/SWIZZLE/Swizzle+Confluence http://docs.codehaus.org/display/SWIZZLE/Swizzle+Jira I created these libraries by generating them with perl based on the XML-RPC defs for the respective xml-rpc services. I'm thinking here might be a better home than my little project at Codehaus simply because at commons there'd be like 100+ people who'd have access to improve the library as opposed to just me. So anyway, is this something people would like? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-compress has an issue affecting its community integration. This issue affects 12 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-compress-31072006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/gump_work/build_jakarta-commons-sandbox_commons-compress.html Work Name: build_jakarta-commons-sandbox_commons-compress (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:55: cannot find symbol symbol : variable CompressUtils location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor CompressUtils.copy( inputStream, outputBZStream ); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:57: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(File could not be found, e); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:59: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(An IO Exception occured, e); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:64: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(An IO Exception occured while closing the streams, e1); ^
[EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-compress has an issue affecting its community integration. This issue affects 12 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-compress-31072006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/gump_work/build_jakarta-commons-sandbox_commons-compress.html Work Name: build_jakarta-commons-sandbox_commons-compress (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:55: cannot find symbol symbol : variable CompressUtils location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor CompressUtils.copy( inputStream, outputBZStream ); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:57: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(File could not be found, e); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:59: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(An IO Exception occured, e); ^ /x1/gump/public/workspace/jakarta-commons-sandbox/compress/src/java/org/apache/commons/compress/compressors/bzip2/BZip2Compressor.java:64: cannot find symbol symbol : class CompressException location: class org.apache.commons.compress.compressors.bzip2.BZip2Compressor throw new CompressException(An IO Exception occured while closing the streams, e1); ^
[compress] Re: [EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
- commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. Bummer! ...I wasn't aware excalibur was already relying on that code! Now what? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427394 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Author: skitching
Date: Mon Jul 31 18:13:11 2006
New Revision: 427394
URL: http://svn.apache.org/viewvc?rev=427394view=rev
Log:
Allow libs for test to be discovered via the classpath as well as via system
properties.
This has been implemented to suppprt running tests via the maven surefire
plugin, but is
a general-purpose mechanism.
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java?rev=427394r1=427393r2=427394view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Mon Jul 31 18:13:11 2006
@@ -197,22 +197,66 @@
* classes.
*/
public void addLogicalLib(String logicalLib) {
+// first, check the system properties
String filename = System.getProperty(logicalLib);
-if (filename == null) {
-throw new UnknownError(
-Logical lib [ + logicalLib + ] is not defined
-+ as a System property.);
+if (filename != null) {
+try {
+URL libUrl = new File(filename).toURL();
+addURL(libUrl);
+return;
+} catch(java.net.MalformedURLException e) {
+throw new UnknownError(
+Invalid file [ + filename + ] for logical lib [ +
logicalLib + ]);
+}
}
-try {
-URL url = new File(filename).toURL();
-addURL(url);
-} catch(java.net.MalformedURLException e) {
-throw new UnknownError(
-Invalid file [ + filename + ] for logical lib [ +
logicalLib + ]);
+// now check the classpath for a similar-named lib
+URL libUrl = libFromClasspath(logicalLib);
+if (libUrl != null) {
+addURL(libUrl);
+return;
}
+
+// lib not found
+throw new UnknownError(
+Logical lib [ + logicalLib + ] is not defined
++ as a System property.);
+}
+
+private URL libFromClasspath(String logicalLib) {
+ClassLoader cl = this.getClass().getClassLoader();
+if (cl instanceof URLClassLoader == false) {
+return null;
+}
+
+URLClassLoader ucl = (URLClassLoader) cl;
+URL[] path = ucl.getURLs();
+for(int i=0; ipath.length; ++i) {
+URL u = path[i];
+
+// extract the filename bit on the end of the url
+String filename = u.toString();
+if (!filename.endsWith(.jar)) {
+// not a jarfile, ignore it
+continue;
+}
+
+int lastSlash = filename.lastIndexOf('/');
+if (lastSlash = 0) {
+filename = filename.substring(lastSlash+1);
+}
+
+if (filename.startsWith(logicalLib)) {
+System.out.println(found lib + logicalLib + at url + u);
+return u;
+} else {
+System.out.println(lib + logicalLib + does not match [ +
filename + ] at url + u);
+}
+}
+
+return null;
+
}
-
/**
* Override ClassLoader method.
* p
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427396 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
Author: skitching
Date: Mon Jul 31 18:16:02 2006
New Revision: 427396
URL: http://svn.apache.org/viewvc?rev=427396view=rev
Log:
Change test to be compatible with maven2 surefire; when using surefire, junit
is not loaded
via the system classpath.
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java?rev=427396r1=427395r2=427396view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
Mon Jul 31 18:16:02 2006
@@ -20,6 +20,8 @@
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Enumeration;
+import java.util.HashSet;
+import java.util.Set;
import junit.framework.Test;
import junit.framework.TestCase;
@@ -87,7 +89,22 @@
// and return our custom TestSuite class
return new PathableTestSuite(testClass, context);
}
-
+
+/**
+ * Utility method to return the set of all classloaders in the
+ * parent chain starting from the one that loaded the class for
+ * this object instance.
+ */
+private Set getAncestorCLs() {
+Set s = new HashSet();
+ClassLoader cl = this.getClass().getClassLoader();
+while (cl != null) {
+s.add(cl);
+cl = cl.getParent();
+}
+return s;
+}
+
/**
* Test that the classloader hierarchy is as expected, and that
* calling loadClass() on various classloaders works as expected.
@@ -133,11 +150,13 @@
PathableClassLoader.class.getName().equals(
systemLoader.getClass().getName()));
-// junit classes should be visible; their classloader is system.
-// this will of course throw an exception if not found.
+// junit classes should be visible; their classloader is not
+// in the hierarchy of parent classloaders for this class,
+// though it is accessable due to trickery in the PathableClassLoader.
Class junitTest = contextLoader.loadClass(junit.framework.Test);
-assertSame(Junit not loaded via systemloader,
-systemLoader, junitTest.getClassLoader());
+Set ancestorCLs = getAncestorCLs();
+assertFalse(Junit not loaded by ancestor classloader,
+ancestorCLs.contains(junitTest.getClassLoader()));
// jcl api classes should be visible only via the parent
Class logClass =
contextLoader.loadClass(org.apache.commons.logging.Log);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r427072 [1/5] - in /jakarta/commons/sandbox/compress/trunk: ./ src/examples/ src/examples/org/ src/examples/org/apache/ src/examples/org/apache/commons/ src/examples/org/apache/commons
Any particular reason for reversing out the change I made to remove compress's dependency on commons-build or was it a mistake? http://svn.apache.org/viewvc?view=revrevision=424724 Niall On 7/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: tcurdt Date: Mon Jul 31 03:55:10 2006 New Revision: 427072 URL: http://svn.apache.org/viewvc?rev=427072view=rev Log: draft 8 from C. Grobmeier, grant has been received, cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427417 - /jakarta/commons/proper/logging/trunk/pom.xml
Author: skitching
Date: Mon Jul 31 20:08:15 2006
New Revision: 427417
URL: http://svn.apache.org/viewvc?rev=427417view=rev
Log:
Copy resources into test jar. Also minor layout tidyups.
Modified:
jakarta/commons/proper/logging/trunk/pom.xml
Modified: jakarta/commons/proper/logging/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/pom.xml?rev=427417r1=427416r2=427417view=diff
==
--- jakarta/commons/proper/logging/trunk/pom.xml (original)
+++ jakarta/commons/proper/logging/trunk/pom.xml Mon Jul 31 20:08:15 2006
@@ -144,18 +144,29 @@
sourceDirectorysrc/java/sourceDirectory
testSourceDirectorysrc/test/testSourceDirectory
+testResources
+ testResource
+directorysrc/test/directory
+filteringfalse/filtering
+includes
+ include**/*.properties/include
+/includes
+ /testResource
+/testResources
+
plugins
-!--
- - The custom test framework requires the unit test code to be
- - in a jarfile so it can control its place in the classpath.
- --
+
+ !--
+- The custom test framework requires the unit test code to be
+- in a jarfile so it can control its place in the classpath.
+--
plugin
artifactIdmaven-jar-plugin/artifactId
- executions
-execution
- idtestjar/id
- phasepackage/phase
- goals
+executions
+ execution
+idtestjar/id
+phasepackage/phase
+goals
goaltest-jar/goal
/goals
configuration
@@ -260,6 +271,12 @@
include**/*TestCase.java/include
/includes
systemProperties
+!--
+property
+ nameorg.apache.commons.logging.diagnostics.dest/name
+ valueSTDOUT/value
+/property
+--
property
namecommons-logging/name
valuetarget/${project.build.finalName}.jar/value
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r427418 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
Author: skitching
Date: Mon Jul 31 20:10:13 2006
New Revision: 427418
URL: http://svn.apache.org/viewvc?rev=427418view=rev
Log:
Minor test tidyups (including fixing incorrect comment due to copy-and-paste).
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java?rev=427418r1=427417r2=427418view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
Mon Jul 31 20:10:13 2006
@@ -62,13 +62,9 @@
String thisClassPath = thisClass.getName().replace('.', '/') +
.class;
URL baseUrl = dummy.findResource(thisClassPath);
-// Now set up the desired classloader hierarchy. We'll put a config
-// file of priority=10 in the container path, and ones of both
-// no priority and priority=20 in the webapp path.
-//
-// A second properties file with priority=20 is also added,
-// so we can check that the first one in the classpath is
-// used.
+// Now set up the desired classloader hierarchy. We'll put JCL
+// in the container path, the testcase in a webapp path, and
+// both config files into the webapp path too.
PathableClassLoader containerLoader = new PathableClassLoader(null);
containerLoader.useExplicitLoader(junit.,
Test.class.getClassLoader());
containerLoader.addLogicalLib(commons-logging);
@@ -110,6 +106,19 @@
*/
public void testPriority() throws Exception {
LogFactory instance = LogFactory.getFactory();
+
+ClassLoader thisClassLoader = this.getClass().getClassLoader();
+ClassLoader lfClassLoader = instance.getClass().getClassLoader();
+ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
+
+// context classloader should be thisClassLoader
+assertEquals(thisClassLoader, contextClassLoader);
+
+// lfClassLoader should be parent of this classloader
+assertEquals(lfClassLoader, thisClassLoader.getParent());
+assertEquals(PathableClassLoader.class.getName(),
+lfClassLoader.getClass().getName());
+
String id = (String) instance.getAttribute(configId);
assertEquals(Correct config file loaded, priority20, id );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS][compress] Re: [EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
(added [vfs] to subject) On 7/31/06, Torsten Curdt [EMAIL PROTECTED] wrote: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. Bummer! ...I wasn't aware excalibur was already relying on that code! Now what? snip/ A quick look at the gump metadata seems to suggest that its a cascading effect of breaking [vfs]. compress - vfs - excalibur-sourceresolve - rest of the bunch Mario - Anything I can do to help get the next [vfs] RC out per your two-jar proposal? (might not be immediate help, but doesn't hurt to know) -Rahul cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
