gmane.comp.jakarta.commons.devel

Re: [GUMP< at >vmgump]: Project commons-compress (in module commons-sandbox) failed

sebb — 2008-10-08T00:15:58

Given that compress is in the sandox, it seems strange that it affects so many projects. Do they really all depend on compress? Or maybe some of the dependencies are optional, but the descriptors are wrong...

[GUMP< at >vmgump]: Project commons-configuration-test (in module apache-commons) failed

Gump — 2008-10-06T10:03:09

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 general< at >gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 40 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspa

[GUMP< at >vmgump]: Project commons-compress (in module commons-sandbox) failed

commons-compress development — 2008-10-06T09:23:56

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 general< at >gump.apache.org. Project commons-compress has an issue affecting its community integration. This issue affects 31 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-contrib : Useful little Ant tasks - ant-contrib-test : Useful little Ant tasks - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - cddlm : Configuration and Deployment of Grid Applications and System... - commons-compress : Commons Compression Package - commons-vfs : Apache Commons - commons-vfs-sandbox : Apache Commons - excalibur-fortress-bean : Repository of reusable components.

Re: [JEXL] - 1.1.1 release?

sebb — 2008-10-07T14:27:01

No patch seen here. Please create a JIRA issue and attach the patch(es) to that. Patches to mailing lists may get overlooked - or lost, as has apparently happened here On 07/10/2008, Vishal Goenka apache.org> wrote:

Re: [GUMP< at >vmgump]: Project commons-compress (in module commons-sandbox) failed

Stefan Bodewig — 2008-10-07T08:53:56

Gump still tried to use a Maven 1.x build, but that doesn't work anymore. I've switched the descriptor to use Maven 2 instead, expect a few more nags until we have the correct file name of the generated jar (unfortunately Gump cannot enforce this in mvn anymore) and I am satisified with the dependencies downloaded from Gump's Maven proxy. Stefan

Re: [improvement] - FILEUPLOAD-168

Paul Rivera — 2008-10-07T07:08:55

Hi guys! Sorry for being so persistent. My previous email seems to have gone unnoticed. Here it is again if someone could be kind enough to take a look at FILEUPLOAD-168. :) Best Regards, Paul Rivera On Fri, Oct 3, 2008 at 2:09 PM, Paul Rivera gmail.com> wrote:

[GUMP< at >vmgump]: Project commons-compress (in module commons-sandbox) failed

commons-compress development — 2008-10-05T16:24:59

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 general< at >gump.apache.org. Project commons-compress has an issue affecting its community integration. This issue affects 31 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-contrib : Useful little Ant tasks - ant-contrib-test : Useful little Ant tasks - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - cddlm : Configuration and Deployment of Grid Applications and System... - commons-compress : Commons Compression Package - commons-vfs : Apache Commons - commons-vfs-sandbox : Apache Commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-im

RE: [JEXL] - 1.1.1 release?

Vishal Goenka — 2008-10-07T06:30:57

Please find a patch for the ASTBlock statement bug. I will follow up with jUnit test case as well as a patch for the other issue I identified earlier as time permits. Thanks. - Vishal -----Original Message----- From: Rahul Akolkar [mailto:rahul.akolkar< at >gmail.com] Sent: Thursday, September 11, 2008 1:38 PM To: Commons Developers List; vgoenka< at >apache.org Subject: Re: [JEXL] - 1.1.1 release? On Thu, Sep 11, 2008 at 1:00 PM, Vishal Goenka apache.org> wrote: for soon. Nothing has been discussed on the list. The last activity we've seen is some enhancements from dIon a couple of weeks ago, and there have been enough changes to warrant a new release IMO. So, it may depend on how much interest you (and others) have in seeing a release and getting the odds and ends in to help out. I glanced at that email again. Can you please provide a real patch? The copying two lines part wouldn't generally be a problem, but its been a busy month so far. A JUnit test case to match would be super.

[GUMP< at >vmgump]: Project commons-configuration-test (in module apache-commons) failed

Gump — 2008-10-05T09:07:28

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 general< at >gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 37 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspa

[GUMP< at >vmgump]: Project commons-compress (in module commons-sandbox) failed

commons-compress development — 2008-10-05T08:30:18

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 general< at >gump.apache.org. Project commons-compress has an issue affecting its community integration. This issue affects 31 projects, and has been outstanding for 37 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-contrib : Useful little Ant tasks - ant-contrib-test : Useful little Ant tasks - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - cddlm : Configuration and Deployment of Grid Applications and System... - commons-compress : Commons Compression Package - commons-vfs : Apache Commons - commons-vfs-sandbox : Apache Commons - excalibur-fortress-bean : Repository of reusable components

[continuum] BUILD FAILURE: Commons - Commons Compress (Sandbox) -

2008-10-06T22:36:14

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=118558&projectId=176 Build statistics: State: Failed Previous State: Ok Started at: Mon 6 Oct 2008 15:35:47 -0700 Finished at: Mon 6 Oct 2008 15:36:05 -0700 Total time: 17s Build Trigger: Schedule Build Number: 17 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: "unix" **************************************************************************** SCM Changes: **************************************************************************** Changed: tcurdt < at > Mon 6 Oct 2008 14:52:13 -0700 Comm

Re: [compress] making the redesign branch trunk

Torsten Curdt — 2008-10-06T21:47:19

Cool ... I take that as a "yes" ... switching cheers -- Torsten

Re: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?

Torsten Curdt — 2008-10-06T00:08:37

I guess we could also just get rid of the reflection. What do you think? cheers -- Torsten

[GUMP< at >vmgump]: Project commons-configuration-test (in module apache-commons) failed

Gump — 2008-10-04T09:03:17

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 general< at >gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 34 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspa

Re: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?

Timothy James Pinet — 2008-10-05T22:44:21

Reflection does handle checked exceptions for Constructor.newInstance() and this is handled appropriately for: public ArchiveInputStream createArchiveInputStream( final String archiverName, final InputStream out ) throws ArchiveException {...} However, the other method: public ArchiveInputStream createArchiveInputStream( final InputStream input ) throws IOException {...} is not implemented to handle checked constructor exceptions since all Exception catches are not handled. It looks as though this method was not completed. I will fix it up and suggest a patch to bring it to a workable state. Thanks, Tim -------------------------------------------------- From: "Torsten Curdt" apache.org> Sent: Sunday, October 05, 2008 10:27 AM To: "Commons Developers List" commons.apache.org> Subject: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?

Re: [compress] making the redesign branch trunk

Christian Grobmeier — 2008-10-05T14:51:15

that would be wonderful. Cheers On Sun, Oct 5, 2008 at 4:10 PM, Torsten Curdt apache.org> wrote:

Re: [compress] making the redesign branch trunk

Emmanuel Bourg — 2008-10-05T14:46:44

+1 on switching the branches Torsten Curdt a écrit :

[compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?

Torsten Curdt — 2008-10-05T14:27:10

Hey there I think the idea that it makes "dropping in" a new implementation easier. But I agree with you. As the registerArchive*Stream methods need to be called to register the implementation this becomes a moo point. I would change the factory to public ArchiveInputStream createArchiveInputStream( final String archiverName, final InputStream stream ) throws ArchiveException { if ("ar".equals(archiverName)) { return new ArAchiveInputStream(stream) } .. return null; } and then instead of registering a new implementation you just extend the factory and overload the create*Stream methods to add your custom impl ...and of course delegate to the super class. Hm ... I thought that would be indeed possible: http://java.sun.com/docs/books/tutorial/reflect/member/ctorTrouble.html cheers -- Torsten

Re: [compress] making the redesign branch trunk

Timothy James Pinet — 2008-10-05T14:19:02

Agreed. I was personally confused and lost many hours working on a non-valid branch. Tim -------------------------------------------------- From: "Torsten Curdt" apache.org> Sent: Sunday, October 05, 2008 10:10 AM To: "Commons Developers List" commons.apache.org> Subject: [compress] making the redesign branch trunk

[compress] making the redesign branch trunk

Torsten Curdt — 2008-10-05T14:10:29

Any objections to move trunk over to an "old design" branch and then switch the new design branch to be trunk? This has already caused some confusion. We need finally need to make some progress here. cheers -- Torsten

COMPRESS-REDESIGN: What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?

Timothy James Pinet — 2008-10-05T14:05:59

Good morning, Out of curiosity why must reflection be used for the create*Stream() methods in the ArchiveStreamFactory and CompressorStreamFactory? There is a cast at the end of each method to a corresponding interface anyway (ex ArchiveInputStream, ArchiveOutputStream, etc) so why cant we use this knowledge ahead of time and execute on the interface? The current implementation makes it next to impossible to capture errors being thrown by the constructors of new implementations since the reflective methods discard any Exceptions and simply return null. I would like to know why this design decision was made just in case I am missing something. Regards, Tim