[jira] [Created] (VALIDATOR-340) Add new TLDs
Ken Montgomery created VALIDATOR-340:
Summary: Add new TLDs
Key: VALIDATOR-340
URL: https://issues.apache.org/jira/browse/VALIDATOR-340
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.4.0 Release
Environment: Live
Reporter: Ken Montgomery
Fix For: 1.4.1
The current commons-validator-1.4.0.jar does not include any domains released
after 2012.
org.apache.commons.validator.routines.EmailValidator;
Then on to the method isValidGenericTld(tld)
Which uses the list
private static final String[] GENERIC_TLDS = new String[] {
aero, // air transport industry
asia, // Pan-Asia/Asia Pacific
biz, // businesses
cat, // Catalan linguistic/cultural community
com, // commercial enterprises
coop, // cooperative associations
info, // informational sites
jobs, // Human Resource managers
mobi, // mobile products and services
museum, // museums, surprisingly enough
name, // individuals' sites
net, // internet support infrastructure/business
org, // noncommercial organizations
pro, // credentialed professionals and entities
tel, // contact data for businesses and individuals
travel, // entities in the travel industry
gov, // United States Government
edu, // accredited postsecondary US education entities
mil, // United States Military
int // organizations established by international treaty
};
This list does not include any of the new domains. They are therefore seen as
invalid.
See New Domains (about 300)
http://newgtlds.icann.org/en/program-status/delegated-strings
From http://commons.apache.org/proper/commons-validator/changes-report.html
I can see that version 1.4.0 is the current version even though it was released
on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-269) Specialize useless throws Exception
[
https://issues.apache.org/jira/browse/POOL-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101958#comment-14101958
]
Michael Osipov commented on POOL-269:
-
Looks actually good. About source compat, this can be changed with 2.3 (minor).
What do you think?
Specialize useless throws Exception
---
Key: POOL-269
URL: https://issues.apache.org/jira/browse/POOL-269
Project: Commons Pool
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Michael Osipov
Too many methods say {{throws Exception}} in their signature. This is neither
helpful nor good API design. You never know what the exception is and where
it came from.
An exception translation pattern has to be applied to make code usable, e.g.,
like the Spring project does or Maven with {{BuildException}}.
Unfortunately, this ugly practive has prevailed in several Apache projects
like Lucene.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101989#comment-14101989 ] Michael Osipov commented on POOL-266: - JDK logger is the same crap as Commons Logging. You gain nothing by using the JDK logger. Common Pool does not use log api Key: POOL-266 URL: https://issues.apache.org/jira/browse/POOL-266 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.2 Reporter: Anthony Communier Common pool does not use log api (logback,slf4j, log4j, log4j2, commons logging,...). Errors are printed directly with System.out or System.err. So it's difficult to have information in the same log file as other application log file. Is there any reason to not use log api ? If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102031#comment-14102031 ] Mark Thomas commented on POOL-266: -- This is not the place to re-hash the which logging framework is better debate. I would also add that points made in a civil tone are far more likely to be listened to than those in a hostile tone. A quick code review shows one use of stderr which looks entirely appropriate. In an OOME situation writing directly to stderr is more likely to succeed than writing via a framework. The only use of stdout is for the abandonded logging which is covered by POOL-267. +1 to everything Phil said. Absent a good reason to add a dependency (and I haven't seen one so far) this issue is going to get resolved as WONTFIX. Common Pool does not use log api Key: POOL-266 URL: https://issues.apache.org/jira/browse/POOL-266 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.2 Reporter: Anthony Communier Common pool does not use log api (logback,slf4j, log4j, log4j2, commons logging,...). Errors are printed directly with System.out or System.err. So it's difficult to have information in the same log file as other application log file. Is there any reason to not use log api ? If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102286#comment-14102286
]
Sebb commented on VALIDATOR-340:
It might make sense to provide the TLDs as a resource file, rather than
embedding the strings as constants.
[Likewise for the country codes, though these change less frequently]
This could allow users to replace the file if necessary without needing to
download a new version of the code.
A crude way to do this would be to replace the resource file in the jar.
It would be better if the user could provide a resource file with any required
additions.
Not sure if there is a use-case for dropping TLDs.
Note that EmailValidator now uses DomainValidator to check the domain string.
Add new TLDs
Key: VALIDATOR-340
URL: https://issues.apache.org/jira/browse/VALIDATOR-340
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.4.0 Release
Environment: Live
Reporter: Ken Montgomery
Labels: TLD, domains, email
Fix For: 1.4.1
Original Estimate: 24h
Remaining Estimate: 24h
The current commons-validator-1.4.0.jar does not include any domains released
after 2012.
org.apache.commons.validator.routines.EmailValidator;
Then on to the method isValidGenericTld(tld)
Which uses the list
private static final String[] GENERIC_TLDS = new String[] {
aero, // air transport industry
asia, // Pan-Asia/Asia Pacific
biz, // businesses
cat, // Catalan linguistic/cultural community
com, // commercial enterprises
coop, // cooperative associations
info, // informational sites
jobs, // Human Resource managers
mobi, // mobile products and services
museum, // museums, surprisingly enough
name, // individuals' sites
net, // internet support infrastructure/business
org, // noncommercial organizations
pro, // credentialed professionals and entities
tel, // contact data for businesses and individuals
travel, // entities in the travel industry
gov, // United States Government
edu, // accredited postsecondary US education entities
mil, // United States Military
int // organizations established by international treaty
};
This list does not include any of the new domains. They are therefore seen as
invalid.
See New Domains (about 300)
http://newgtlds.icann.org/en/program-status/delegated-strings
From http://commons.apache.org/proper/commons-validator/changes-report.html
I can see that version 1.4.0 is the current version even though it was
released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102299#comment-14102299 ] Michael Osipov commented on POOL-266: - bq. This is not the place to re-hash the which logging framework is better debate. I agree on that. Maybe everyone could live with a log chute like Velocity uses. Common Pool does not use log api Key: POOL-266 URL: https://issues.apache.org/jira/browse/POOL-266 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.2 Reporter: Anthony Communier Common pool does not use log api (logback,slf4j, log4j, log4j2, commons logging,...). Errors are printed directly with System.out or System.err. So it's difficult to have information in the same log file as other application log file. Is there any reason to not use log api ? If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102294#comment-14102294
]
Ken Montgomery commented on VALIDATOR-340:
--
Thank you for your email.
I will be out of the office on Wednesday 20/08/2014 returning on Thursday
21/08/2014.
If you require a more immediate response please email
dlhqapdmapplicationsupp...@auspost.com.au
Regards
Ken Montgomery
Application Support Manager
Australia Post Digital Mailbox
Level 1/136 Exhibition Street, Melbourne VIC 3000
Add new TLDs
Key: VALIDATOR-340
URL: https://issues.apache.org/jira/browse/VALIDATOR-340
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.4.0 Release
Environment: Live
Reporter: Ken Montgomery
Labels: TLD, domains, email
Fix For: 1.4.1
Original Estimate: 24h
Remaining Estimate: 24h
The current commons-validator-1.4.0.jar does not include any domains released
after 2012.
org.apache.commons.validator.routines.EmailValidator;
Then on to the method isValidGenericTld(tld)
Which uses the list
private static final String[] GENERIC_TLDS = new String[] {
aero, // air transport industry
asia, // Pan-Asia/Asia Pacific
biz, // businesses
cat, // Catalan linguistic/cultural community
com, // commercial enterprises
coop, // cooperative associations
info, // informational sites
jobs, // Human Resource managers
mobi, // mobile products and services
museum, // museums, surprisingly enough
name, // individuals' sites
net, // internet support infrastructure/business
org, // noncommercial organizations
pro, // credentialed professionals and entities
tel, // contact data for businesses and individuals
travel, // entities in the travel industry
gov, // United States Government
edu, // accredited postsecondary US education entities
mil, // United States Military
int // organizations established by international treaty
};
This list does not include any of the new domains. They are therefore seen as
invalid.
See New Domains (about 300)
http://newgtlds.icann.org/en/program-status/delegated-strings
From http://commons.apache.org/proper/commons-validator/changes-report.html
I can see that version 1.4.0 is the current version even though it was
released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102299#comment-14102299 ] Michael Osipov edited comment on POOL-266 at 8/19/14 3:10 PM: -- bq. This is not the place to re-hash the which logging framework is better debate. I agree on that. Maybe everyone could live with a log chute like Velocity does. was (Author: michael-o): bq. This is not the place to re-hash the which logging framework is better debate. I agree on that. Maybe everyone could live with a log chute like Velocity uses. Common Pool does not use log api Key: POOL-266 URL: https://issues.apache.org/jira/browse/POOL-266 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.2 Reporter: Anthony Communier Common pool does not use log api (logback,slf4j, log4j, log4j2, commons logging,...). Errors are printed directly with System.out or System.err. So it's difficult to have information in the same log file as other application log file. Is there any reason to not use log api ? If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102351#comment-14102351
]
Adrian Crum commented on VALIDATOR-340:
---
A suggestion I made in one of the (many) duplicate issues is to make TLD
validation optional. As one reporter commented, a perfectly valid local domain
will fail validation.
Add new TLDs
Key: VALIDATOR-340
URL: https://issues.apache.org/jira/browse/VALIDATOR-340
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.4.0 Release
Environment: Live
Reporter: Ken Montgomery
Labels: TLD, domains, email
Fix For: 1.4.1
Original Estimate: 24h
Remaining Estimate: 24h
The current commons-validator-1.4.0.jar does not include any domains released
after 2012.
org.apache.commons.validator.routines.EmailValidator;
Then on to the method isValidGenericTld(tld)
Which uses the list
private static final String[] GENERIC_TLDS = new String[] {
aero, // air transport industry
asia, // Pan-Asia/Asia Pacific
biz, // businesses
cat, // Catalan linguistic/cultural community
com, // commercial enterprises
coop, // cooperative associations
info, // informational sites
jobs, // Human Resource managers
mobi, // mobile products and services
museum, // museums, surprisingly enough
name, // individuals' sites
net, // internet support infrastructure/business
org, // noncommercial organizations
pro, // credentialed professionals and entities
tel, // contact data for businesses and individuals
travel, // entities in the travel industry
gov, // United States Government
edu, // accredited postsecondary US education entities
mil, // United States Military
int // organizations established by international treaty
};
This list does not include any of the new domains. They are therefore seen as
invalid.
See New Domains (about 300)
http://newgtlds.icann.org/en/program-status/delegated-strings
From http://commons.apache.org/proper/commons-validator/changes-report.html
I can see that version 1.4.0 is the current version even though it was
released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-965) FieldUtils methods leak accessible flags
[ https://issues.apache.org/jira/browse/LANG-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre Diermann updated LANG-965: Attachment: commons-lang-965.patch The attached patch tries so solve the mentioned accessibility leak by restoring the original accessibility of a particular field in case it has been modified by readField/writeField. FieldUtils methods leak accessible flags Key: LANG-965 URL: https://issues.apache.org/jira/browse/LANG-965 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Affects Versions: 3.1, 3.2.1 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\Java\apache-maven-3.1.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Assignee: Gary Gregory Fix For: Patch Needed Attachments: commons-lang-965.patch When various FieldUtils methods are called the accessible is set to true but never reset to false. This is side-effect should be cleaned up. This makes a mess of the object model which represents the class meta data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-116) CompositeCacheManager is thread-hostile
[ https://issues.apache.org/jira/browse/JCS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-116: --- Fix Version/s: jcs-2.0.0 CompositeCacheManager is thread-hostile --- Key: JCS-116 URL: https://issues.apache.org/jira/browse/JCS-116 Project: Commons JCS Issue Type: Bug Reporter: Sebb Priority: Blocker Fix For: jcs-2.0.0 The CompositeCacheManager class is a singleton. However it is not immutable, so is inherently thread-hostile. The class does take some steps to prevent reconfiguration, but it still allows changes to variables such as defaultCacheAttr that affect instance methods such as getCache(String) This makes it very easy to accidentally affect other threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-133: --- Fix Version/s: jcs-2.0.0 RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly Key: JCS-133 URL: https://issues.apache.org/jira/browse/JCS-133 Project: Commons JCS Issue Type: Bug Reporter: Sebb Fix For: jcs-2.0.0 The RemoteUtils.getNamingURL method does the following concatenation to produce the result: // + registryHost + : + registryPort + / + serviceName; This works fine for host names and IPv4, but does not work for literal IPv6 addresses which have to be enclosed in [ and ] A crude way to fix this would be to look for : in the registryHost string. If present, the zone index identifier (%2 or %eth0) needs to be encoded because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-132) EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6
[ https://issues.apache.org/jira/browse/JCS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-132: --- Fix Version/s: jcs-2.0.0 EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6 -- Key: JCS-132 URL: https://issues.apache.org/jira/browse/JCS-132 Project: Commons JCS Issue Type: Bug Reporter: Sebb Fix For: jcs-2.0.0 EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6 because it tries to load javax.cache.annotation.BeanProvider.class Unfortunately the jar in which is is contained appears to have been built for Java 1.7 (unlike the rest of the javax jars). Some possible workrounds: - use a different class if there is another that is suitable - get the providers to release a version that works for Java 1.6 - catch the failure, and convert it to a warning on Java 1.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-122: --- Fix Version/s: jcs-2.0.0 rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-119) replace synchronized blocks by java locks or concurrenhashmap
[ https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-119: --- Fix Version/s: jcs-2.0.0 replace synchronized blocks by java locks or concurrenhashmap - Key: JCS-119 URL: https://issues.apache.org/jira/browse/JCS-119 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 A cache is typically used in a concurrent environment. Since Java 6 using a ReentrantLock is faster than synchronized so can be interesting to replace synchronized blocks by a lock. Places i'm thinking about: * CompositeCache * AbstractDoubleLinkedListMemoryCache * LHMLRUMemoryCache * DoubleLinkedList * LRUMap * SingleLinkedList * SortedPreferentialArray Some places where replacing a HashMap by a ConcurrentHashMap can allow to get rid of synchronized without needing a lock: * CacheEventQueue * AbstractDiskCache * CacheWatchRepairable There are other places but this is the main I saw. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102619#comment-14102619 ] Thomas Vandahl commented on JCS-133: An alternative would be to try to resolve the address and see if it is a IPv6 address. That, however, might trigger DNS timeouts (30 sec), which should be avoided IMO. I'm fine with the fix. RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly Key: JCS-133 URL: https://issues.apache.org/jira/browse/JCS-133 Project: Commons JCS Issue Type: Bug Reporter: Sebb Fix For: jcs-2.0.0 The RemoteUtils.getNamingURL method does the following concatenation to produce the result: // + registryHost + : + registryPort + / + serviceName; This works fine for host names and IPv4, but does not work for literal IPv6 addresses which have to be enclosed in [ and ] A crude way to fix this would be to look for : in the registryHost string. If present, the zone index identifier (%2 or %eth0) needs to be encoded because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-133. Resolution: Fixed Assignee: Thomas Vandahl Fixed by Sebb in SVN. Thanks for the fix. RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly Key: JCS-133 URL: https://issues.apache.org/jira/browse/JCS-133 Project: Commons JCS Issue Type: Bug Reporter: Sebb Assignee: Thomas Vandahl Fix For: jcs-2.0.0 The RemoteUtils.getNamingURL method does the following concatenation to produce the result: // + registryHost + : + registryPort + / + serviceName; This works fine for host names and IPv4, but does not work for literal IPv6 addresses which have to be enclosed in [ and ] A crude way to fix this would be to look for : in the registryHost string. If present, the zone index identifier (%2 or %eth0) needs to be encoded because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103379#comment-14103379 ] Yogesh Rao commented on JCS-122: Any particular reason SLF4J wouldnt work in tomee ? Hope i am not missing anything. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COMPRESS-286) Error while expanding 7z java.io.EOFException
[ https://issues.apache.org/jira/browse/COMPRESS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103406#comment-14103406 ] Stefan Bodewig commented on COMPRESS-286: - Thanks to Lasse Collin I now know where the problem is (for LZMA streams we need to pass the uncompressed size to the constructor). We'll need to modify some internal APIs, but it at least we now know how to fix it. Error while expanding 7z java.io.EOFException - Key: COMPRESS-286 URL: https://issues.apache.org/jira/browse/COMPRESS-286 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8, 1.8.1 Environment: Windows8, Java6 Reporter: Greg Domjan Labels: 7z, XZ, ant, maven2, newbie Fix For: 1.9 Using 7zip (9.2) able to extract these downloaded files http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_Dev.7z http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_ReleaseDLL.7z Commons-compress 1.6 had issues with these files that seemed related to COMPRESS-257 so tried to use 1.8 as identified fixed in version. Some issues where fixed. Using maven + antrun plugin artifactIdmaven-antrun-plugin/artifactId version1.7/version dependencies dependency groupIdant-contrib/groupId artifactIdant-contrib/artifactId version1.0b3/version exclusions exclusion groupIdant/groupId artifactIdant/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.ant/groupId artifactIdant-nodeps/artifactId version1.8.1/version /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-compress/artifactId version1.8/version /dependency dependency groupIdorg.apache.ant/groupId artifactIdant-compress/artifactId version1.4/version /dependency /dependencies Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant BuildException has occured: Error while expanding Z:\download\wxMSW-3.0.0_vc120_Dev.7z java.io.EOFException around Ant part ...un7z dest=C:\target/x86 overwrite=false sr c=z:\download/wxMSW-3.0.0_vc120_Dev.7z/... @ 26:237 in C:\target\antrun\build-download.xml at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:355) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: c:\target\antrun\build-download.xml:26: Error while expand ing c:\download\wxMSW-3.0.0_vc120_Dev.7z java.io.EOFException at org.apache.ant.compress.taskdefs.Un7z.expandFile(Un7z.java:92) at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:132) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
[jira] [Updated] (COMPRESS-286) Error while expanding 7z java.io.EOFException
[ https://issues.apache.org/jira/browse/COMPRESS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-286: Fix Version/s: 1.9 Error while expanding 7z java.io.EOFException - Key: COMPRESS-286 URL: https://issues.apache.org/jira/browse/COMPRESS-286 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.8, 1.8.1 Environment: Windows8, Java6 Reporter: Greg Domjan Labels: 7z, XZ, ant, maven2, newbie Fix For: 1.9 Using 7zip (9.2) able to extract these downloaded files http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_Dev.7z http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_ReleaseDLL.7z Commons-compress 1.6 had issues with these files that seemed related to COMPRESS-257 so tried to use 1.8 as identified fixed in version. Some issues where fixed. Using maven + antrun plugin artifactIdmaven-antrun-plugin/artifactId version1.7/version dependencies dependency groupIdant-contrib/groupId artifactIdant-contrib/artifactId version1.0b3/version exclusions exclusion groupIdant/groupId artifactIdant/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.ant/groupId artifactIdant-nodeps/artifactId version1.8.1/version /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-compress/artifactId version1.8/version /dependency dependency groupIdorg.apache.ant/groupId artifactIdant-compress/artifactId version1.4/version /dependency /dependencies Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant BuildException has occured: Error while expanding Z:\download\wxMSW-3.0.0_vc120_Dev.7z java.io.EOFException around Ant part ...un7z dest=C:\target/x86 overwrite=false sr c=z:\download/wxMSW-3.0.0_vc120_Dev.7z/... @ 26:237 in C:\target\antrun\build-download.xml at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:355) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: c:\target\antrun\build-download.xml:26: Error while expand ing c:\download\wxMSW-3.0.0_vc120_Dev.7z java.io.EOFException at org.apache.ant.compress.taskdefs.Un7z.expandFile(Un7z.java:92) at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:132) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at
