[GitHub] [commons-csv] coveralls edited a comment on issue #65: Improve Format Coverage to 99percent
coveralls edited a comment on issue #65: Improve Format Coverage to 99percent URL: https://github.com/apache/commons-csv/pull/65#issuecomment-607571859 [](https://coveralls.io/builds/29785344) Coverage increased (+1.09%) to 97.512% when pulling **2ef6f8d9208ee3dc2bbfa5813e205074bcf6b247 on dota17:ImproveFormatCoverage** into **cab61c53f12a5cef50c25397a2946b303582193c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] coveralls commented on issue #65: Improve Format Coverage to 99percent
coveralls commented on issue #65: Improve Format Coverage to 99percent URL: https://github.com/apache/commons-csv/pull/65#issuecomment-607571859 [](https://coveralls.io/builds/29785004) Coverage increased (+1.09%) to 97.512% when pulling **b0751c6571ce7c52372b89c1221b38cd5e4b6d9f on dota17:ImproveFormatCoverage** into **cab61c53f12a5cef50c25397a2946b303582193c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] dota17 opened a new pull request #65: Improve Format Coverage to 99percent
dota17 opened a new pull request #65: Improve Format Coverage to 99percent URL: https://github.com/apache/commons-csv/pull/65 Improve Format Coverage to 99percent This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073115#comment-17073115
]
AD_LB edited comment on COMPRESS-508 at 4/1/20, 8:29 PM:
-
OK how can I make the ZipArchiveInputStream skip to the important part then, to
get information about all entries?
There are multiple reasons for why I ask about InputStream :
# Android is becoming more restricted about File and file path, as Google
pushes to use SAF API. This means I might need to use Uri (which can produce an
InputStream whenever I wish) of file (or any other content source).
# According to Google, InputStream is the recommended way to handle content,
and that libraries of all types should have prefered it anyway, instead of a
limited file-path (because you can, for example, read from the Internet or from
another app, and InputStream is the only one that is common between them).
Assuming you have the ability to create the InputStream of the file whenever
you wish (and the file doesn't change, of course), you should be able to reach
all of its data however you wish. This means that it doesn't technically matter
if you use ZipFile or ZipArchiveInputStream - both should be able to get the
entries sizes.
How can I use ZipArchiveInputStream and still get the important data? I could
create my own collection of entries-like classes, that include the names and
sizes.
I could create 2 (or more) InputStream if you wish, of the same file.
And theoratically, I could give you a certain amount of RAM, so that you could
store the entire file into it (unless too large).
In any case, what I say is that no matter which way you use to get the bytes,
it's still the same bytes. It should be possible to get to any byte you need,
and if I tell you that I can create the InputStream whenever you wish, you
should be able to read anything you want from it.
was (Author: androiddeveloperlb):
OK how can I make the ZipArchiveInputStream skip to the important part then, to
get information about all entries?
There are multiple reasons for why I ask about InputStream :
# Android is becoming more restricted about File and file path, as Google
pushes to use SAF API. This means I might need to use Uri (which can produce an
InputStream whenever I wish) of file (or any other content source).
# According to Google, InputStream is the recommended way to handle content,
and that libraries of all types should have prefered it anyway, instead of a
limited file-path (because you can, for example, read from the Internet or from
another app, and InputStream is the only one that is common between them).
Assuming you have the ability to create the InputStream of the file whenever
you wish (and the file doesn't change, of course), you should be able to reach
all of its data however you wish. This means that it doesn't technically matter
if you use ZipFile or ZipArchiveInputStream - both should be able to get the
entries sizes.
How can I use ZipArchiveInputStream and still get the important data? I could
create my own collection of entries-like classes, that include the names and
sizes.
I could create 2 (or more) InputStream if you wish, of the same file.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code
[jira] [Comment Edited] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073115#comment-17073115
]
AD_LB edited comment on COMPRESS-508 at 4/1/20, 7:20 PM:
-
OK how can I make the ZipArchiveInputStream skip to the important part then, to
get information about all entries?
There are multiple reasons for why I ask about InputStream :
# Android is becoming more restricted about File and file path, as Google
pushes to use SAF API. This means I might need to use Uri (which can produce an
InputStream whenever I wish) of file (or any other content source).
# According to Google, InputStream is the recommended way to handle content,
and that libraries of all types should have prefered it anyway, instead of a
limited file-path (because you can, for example, read from the Internet or from
another app, and InputStream is the only one that is common between them).
Assuming you have the ability to create the InputStream of the file whenever
you wish (and the file doesn't change, of course), you should be able to reach
all of its data however you wish. This means that it doesn't technically matter
if you use ZipFile or ZipArchiveInputStream - both should be able to get the
entries sizes.
How can I use ZipArchiveInputStream and still get the important data? I could
create my own collection of entries-like classes, that include the names and
sizes.
I could create 2 (or more) InputStream if you wish, of the same file.
was (Author: androiddeveloperlb):
OK how can I make the ZipArchiveInputStream skip to the important part then, to
get information about all entries?
There are multiple reasons for why I ask about InputStream :
# Android is becoming more restricted about File and file path, as Google
pushes to use SAF API. This means I might need to use Uri (which can produce an
InputStream whenever I wish) of file (or any other content source).
# According to Google, InputStream is the recommended way to handle content.
Assuming you have the ability to create the InputStream of the file whenever
you wish (and the file doesn't change, of course), you should be able to reach
all of its data however you wish. This means that it doesn't technically matter
if you use ZipFile or ZipArchiveInputStream - both should be able to get the
entries sizes.
How can I use ZipArchiveInputStream and still get the important data? I could
create my own collection of entries-like classes, that include the names and
sizes.
I could create 2 (or more) InputStream if you wish, of the same file.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassia
[jira] [Commented] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073115#comment-17073115
]
AD_LB commented on COMPRESS-508:
OK how can I make the ZipArchiveInputStream skip to the important part then, to
get information about all entries?
There are multiple reasons for why I ask about InputStream :
# Android is becoming more restricted about File and file path, as Google
pushes to use SAF API. This means I might need to use Uri (which can produce an
InputStream whenever I wish) of file (or any other content source).
# According to Google, InputStream is the recommended way to handle content.
Assuming you have the ability to create the InputStream of the file whenever
you wish (and the file doesn't change, of course), you should be able to reach
all of its data however you wish. This means that it doesn't technically matter
if you use ZipFile or ZipArchiveInputStream - both should be able to get the
entries sizes.
How can I use ZipArchiveInputStream and still get the important data? I could
create my own collection of entries-like classes, that include the names and
sizes.
I could create 2 (or more) InputStream if you wish, of the same file.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CRYPTO-146) Create new release to major repositories
Geoffrey Blake created CRYPTO-146: - Summary: Create new release to major repositories Key: CRYPTO-146 URL: https://issues.apache.org/jira/browse/CRYPTO-146 Project: Commons Crypto Issue Type: Task Affects Versions: 1.1.0 Reporter: Geoffrey Blake The most recent version that is contained on [https://mvnrepository.com/artifact/org.apache.commons/commons-crypto] in v1.0.0 which is over 4 years ago. A new release is warranted for the support for OpenSSL 1.1.1, and update the native libraries that are supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-csv] coveralls commented on issue #64: Removed invalid Javadoc markup for CSVFormat EXCEL
coveralls commented on issue #64: Removed invalid Javadoc markup for CSVFormat EXCEL URL: https://github.com/apache/commons-csv/pull/64#issuecomment-607411662 [](https://coveralls.io/builds/29777108) Coverage remained the same at 96.418% when pulling **1e3117021306ee721d61245731fb94cf38560c02 on a4ff7810:doc-CSVFormat-EXCEL** into **cab61c53f12a5cef50c25397a2946b303582193c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] a4ff7810 opened a new pull request #64: Removed invalid Javadoc markup for CSVFormat EXCEL
a4ff7810 opened a new pull request #64: Removed invalid Javadoc markup for CSVFormat EXCEL URL: https://github.com/apache/commons-csv/pull/64 (doc) Removed `@link`s in `@code` blocks for `CSVFormat EXCEL` Javadoc. Cf. https://javadoc.io/doc/org.apache.commons/commons-csv/1.8/org/apache/commons/csv/CSVFormat.html#EXCEL (or https://javadoc.io/doc/org.apache.commons/commons-csv/1.7/org/apache/commons/csv/CSVFormat.html#EXCEL) for render of currently broken version, for example. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072959#comment-17072959
]
Stefan Bodewig commented on COMPRESS-508:
-
what I forgot to say: this is not a bug, this - unfortunately - is the expected
and documented behaviour
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072956#comment-17072956
]
Stefan Bodewig commented on COMPRESS-508:
-
Unfortunately this is due to how data descriptors in zip archives work. You
will get the sizes of you use {{ZipFile}} for the same reason that you do get
them with {{7z}} or {{WinZIP}}.
Basically the zip format has a list of "some metadata + file content +
potential data descriptor" sequences per entry followed by "all metadata for
all entries". When you use {{ZipArchiveInputStream}} you get "some metadata"
inside of {{ZipArchiveEntry}} before you start reading the entry. An entry that
uses the data descriptor does not store the entry's size inside of the "some
metadata" part, this is why you get an unknown size. Once you have read the
entry's contents, the data descriptor (which holds the size information) will
be read and {{ZipArchiveEntry}} suddenly knows its size.
{{ZipFile}} and the other tools working on files "simply" jump to the "all
metadata" part and do read sizes from there.
You are facing the "may return unknown sizes" part of
[http://commons.apache.org/proper/commons-compress/zip.html#ZipArchiveInputStream_vs_ZipFile]
and there isn't really much you can do about it. You can access the size of
the previous entry once you have called {{getNextZipEntry}} - but of course the
stream will no longer be positioned to read this previous entry.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (JEXL-329) Uberspect may loose its Classloader
[ https://issues.apache.org/jira/browse/JEXL-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-329. Resolution: Not A Problem The soft reference may only be cleared if the class loader becomes softly referenced which implies that no instance of any class loaded through it is strongly referenced. See ClassCreatorTest.testMany(). Beside the theory, I've (unfortunately) seen OOM occur -in production- but *never* seen JEXL loose its class loader. :-) > Uberspect may loose its Classloader > --- > > Key: JEXL-329 > URL: https://issues.apache.org/jira/browse/JEXL-329 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Major > > In the current implementation Uberspect keeps references to its Introspector > and ClassLoader via SoftReference. This means that when memory is short it > can loose not only Introspector reference, which is OK, but also ClassLoader > that was specified for resolving constructors, which looks like a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (JEXL-329) Uberspect may loose its Classloader
Dmitri Blinov created JEXL-329: -- Summary: Uberspect may loose its Classloader Key: JEXL-329 URL: https://issues.apache.org/jira/browse/JEXL-329 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.1 Reporter: Dmitri Blinov In the current implementation Uberspect keeps references to its Introspector and ClassLoader via SoftReference. This means that when memory is short it can loose not only Introspector reference, which is OK, but also ClassLoader that was specified for resolving constructors, which looks like a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AD_LB updated COMPRESS-508:
---
Description:
I'm trying to use ZipArchiveInputStream to iterate over the items of a zip file
(which may or may not be a real file on the file-system, which is why I use a
stream), optionally creating a stream from specific entries.
One of the operations I need is to get the size of the files within.
For some reason, it fails to do so. Not only that, but it throws an exception
when I'm done with it:
{code:java}
Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
Unsupported feature data descriptor used in entry ...
{code}
I've attached here 3 files:sample project, the problematic zip file (remember
that you need to put it in the correct path and grant storage permission), and
a screenshot of the issue.
Note that if I open the file using a third party PC app (such as
[7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
size inside.
Files:
!2020-03-31_20-53-36.png![^test.zip]
[^ZipTest.zip]
Here's the relevant code (kotlin) :
{code:java}
thread {
try {
val file = File("/storage/emulated/0/test.zip")
ZipArchiveInputStream(FileInputStream(file)).use {
while (true) {
val entry = it.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
}
}
Log.d("AppLog", "got archive ")
} catch (e: Exception) {
Log.d("AppLog", "Error:$e")
e.printStackTrace()
}
}
{code}
was:
I'm trying to use ZipArchiveInputStream to iterate over the items of a zip file
(which may or may not be a real file on the file-system, which is why I use a
stream), optionally creating a stream from specific entries.
One of the operations I need is to get the size of the files within.
For some reason, it fails to do so. Not only that, but it throws an exception
when I'm done with it:
{code:java}
Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
Unsupported feature data descriptor used in entry ...
{code}
I've attached here 3 files:sample project, the problematic zip file (remember
that you need to put it in the correct path and grant storage permission), and
a screenshot of the issue.
Note that if I open the file using a third party PC app (such as
[7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
size inside.
Here's the relevant code (kotlin) :
{code:java}
thread {
try {
val file = File("/storage/emulated/0/test.zip")
ZipArchiveInputStream(FileInputStream(file)).use {
while (true) {
val entry = it.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
}
}
Log.d("AppLog", "got archive ")
} catch (e: Exception) {
Log.d("AppLog", "Error:$e")
e.printStackTrace()
}
}
{code}
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Files:
> !2020-03-31_20-53-36.png![^test.zip]
> [^ZipTest.zip]
> Here's the relevant code (kotlin) :
>
> {code:java}
>
[jira] [Updated] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AD_LB updated COMPRESS-508:
---
Attachment: 2020-04-01_18-28-19.mp4
ZipTest2.zip
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072870#comment-17072870
]
AD_LB edited comment on COMPRESS-508 at 4/1/20, 3:31 PM:
-
[~peterlee]
Hello,
Nice to see that you answered so quickly. Thank you for that.
Kotlin is very similar to Java, and the IDE even helps converting (still
usually needs some adjustments).
I used "UTF8" instead of `ZipEncodingHelper.UTF8` because it's not public. I
hope it's ok.
Sadly, even after using your code, it doesn't return me the size of the entry:
{code:java}
ZipArchiveInputStream(FileInputStream(file), "UTF8", true, true).use {
inputStream ->
while (true) {
val entry = inputStream.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size}")
}
}{code}
It says the size is -1 (minus one).
How come you use the same code and it worked for you?
See attached files.
[^ZipTest2.zip]
[^2020-04-01_18-28-19.mp4]
was (Author: androiddeveloperlb):
[~peterlee]
Hello,
Nice to see that you answered so quickly. Thank you for that.
Kotlin is very similar to Java, and the IDE even helps converting (still
usually needs some adjustments).
I used "UTF8" instead of `ZipEncodingHelper.UTF8` because it's not public. I
hope it's ok.
Sadly, even after using your code, it doesn't return me the size of the entry:
{code:java}
ZipArchiveInputStream(FileInputStream(file), "UTF8", true, true).use {
inputStream ->
while (true) {
val entry = inputStream.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size}")
}
}{code}
It says the size is -1 (minus one).
How come you use the same code and it worked for you?
See attached files.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, 2020-04-01_18-28-19.mp4,
> ZipTest.zip, ZipTest2.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072870#comment-17072870
]
AD_LB edited comment on COMPRESS-508 at 4/1/20, 3:30 PM:
-
[~peterlee]
Hello,
Nice to see that you answered so quickly. Thank you for that.
Kotlin is very similar to Java, and the IDE even helps converting (still
usually needs some adjustments).
I used "UTF8" instead of `ZipEncodingHelper.UTF8` because it's not public. I
hope it's ok.
Sadly, even after using your code, it doesn't return me the size of the entry:
{code:java}
ZipArchiveInputStream(FileInputStream(file), "UTF8", true, true).use {
inputStream ->
while (true) {
val entry = inputStream.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size}")
}
}{code}
It says the size is -1 (minus one).
How come you use the same code and it worked for you?
See attached files.
was (Author: androiddeveloperlb):
[~peterlee]
Hello,
Nice to see that you answered so quickly. Thank you for that.
Kotlin is very similar to Java, and the IDE even helps converting (still
usually needs some adjustments).
I used "UTF8" instead of `ZipEncodingHelper.UTF8` because it's not public. I
hope it's ok.
Sadly, even after using your code, it doesn't return me the size of the entry:
```
ZipArchiveInputStream(FileInputStream(file), "UTF8", true,
true).use { inputStream ->
while (true) {
val entry = inputStream.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size}")
}
}
```
It says the size is -1 (minus one).
How come you use the same code and it worked for you?
See attached files.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, ZipTest.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-508) Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072870#comment-17072870
]
AD_LB commented on COMPRESS-508:
[~peterlee]
Hello,
Nice to see that you answered so quickly. Thank you for that.
Kotlin is very similar to Java, and the IDE even helps converting (still
usually needs some adjustments).
I used "UTF8" instead of `ZipEncodingHelper.UTF8` because it's not public. I
hope it's ok.
Sadly, even after using your code, it doesn't return me the size of the entry:
```
ZipArchiveInputStream(FileInputStream(file), "UTF8", true,
true).use { inputStream ->
while (true) {
val entry = inputStream.nextEntry ?: break
Log.d("AppLog", "entry:${entry.name} ${entry.size}")
}
}
```
It says the size is -1 (minus one).
How come you use the same code and it worked for you?
See attached files.
> Bug: cannot get file size of ArchiveEntry using ZipArchiveInputStream
> -
>
> Key: COMPRESS-508
> URL: https://issues.apache.org/jira/browse/COMPRESS-508
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.20
> Environment: Android 9 and Android 10, on both emulator and real
> device .
>Reporter: AD_LB
>Priority: Major
> Attachments: 2020-03-31_20-53-36.png, ZipTest.zip, test.zip
>
>
> I'm trying to use ZipArchiveInputStream to iterate over the items of a zip
> file (which may or may not be a real file on the file-system, which is why I
> use a stream), optionally creating a stream from specific entries.
> One of the operations I need is to get the size of the files within.
> For some reason, it fails to do so. Not only that, but it throws an exception
> when I'm done with it:
> {code:java}
> Error:org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException:
> Unsupported feature data descriptor used in entry ...
> {code}
> I've attached here 3 files:sample project, the problematic zip file (remember
> that you need to put it in the correct path and grant storage permission),
> and a screenshot of the issue.
> Note that if I open the file using a third party PC app (such as
> [7-zip|https://www.7-zip.org/] ), it works fine, including showing the file
> size inside.
> Here's the relevant code (kotlin) :
>
> {code:java}
> thread {
> try {
> val file = File("/storage/emulated/0/test.zip")
> ZipArchiveInputStream(FileInputStream(file)).use {
> while (true) {
> val entry = it.nextEntry ?: break
> Log.d("AppLog", "entry:${entry.name} ${entry.size} ")
> }
> }
> Log.d("AppLog", "got archive ")
> } catch (e: Exception) {
> Log.d("AppLog", "Error:$e")
> e.printStackTrace()
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VFS-756) Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to 2.21.0
[ https://issues.apache.org/jira/browse/VFS-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072794#comment-17072794 ] Julian Reschke commented on VFS-756: Thanks, Woonsan. (Q: the attachments on this ticket are spam, right?) > Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to > 2.21.0 > --- > > Key: VFS-756 > URL: https://issues.apache.org/jira/browse/VFS-756 > Project: Commons VFS > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.7.0 > > Attachments: RECORD20200208203041.3gpp, Screenshot_20200208-194408.png > > > Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to > 2.21.0. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-756) Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to 2.21.0
[
https://issues.apache.org/jira/browse/VFS-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072758#comment-17072758
]
Woonsan Ko commented on VFS-756:
Hi [~ggregory],
(CC: [~julian.resc...@gmx.de])
Would you mind updating the {{jackrabbit2.version}} to 2.20.0 in the master
branch, instead of 2.21.0?
The even minor version numbers are for stable releases of Jackrabbit. [1] And
2.20.0 is the latest stable release now.
Thanks in advance,
Woonsan
[1]
https://jackrabbit.apache.org/jcr/jackrabbit-roadmap.html#Unstablestable_release_model
> Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to
> 2.21.0
> ---
>
> Key: VFS-756
> URL: https://issues.apache.org/jira/browse/VFS-756
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.7.0
>
> Attachments: RECORD20200208203041.3gpp, Screenshot_20200208-194408.png
>
>
> Update org.apache.jackrabbit:jackrabbit-standalone-components from 2.19.6 to
> 2.21.0.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NUMBERS-25) Check list for first release
[
https://issues.apache.org/jira/browse/NUMBERS-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated NUMBERS-25:
---
Description:
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (/) JIRA
** (/) Surefire
** (/) RAT
** (/) Jacoco
** (/) SpotBugs
** (/) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit
tests when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted
(MATH-1416).
* (x) User guide
* (x) Rename licence files (NUMBERS-146)
* (/)
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.org/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
* (/) Remove "@since" Javadoc tags
* (/) Code coverage (Jacoco)
was:
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (/) JIRA
** (/) Surefire
** (/) RAT
** (/) Jacoco
** (/) SpotBugs
** (/) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit
tests when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted
(MATH-1416).
* (x) User guide
* (/)
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.org/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
* (/) Remove "@since" Javadoc tags
* (/) Code coverage (Jacoco)
> Check list for first release
>
>
> Key: NUMBERS-25
> URL: https://issues.apache.org/jira/browse/NUMBERS-25
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: release, tasks
> Fix For: 1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> List of tasks to complete before considering a first release.
> * (x) Review public API
> * Ensure clean project reports
> ** (/) JIRA
> ** (/) Surefire
> ** (/) RAT
> ** (/) Jacoco
> ** (/) SpotBugs
> ** (/) Checkstyle
> ** (x) PMD
> ** (x) CPD
> * Ensure that "Commons Math" ("master" branch) compiles and pass all unit
> tests when
> ** (x) dependencies to "Commons Numbers" modules are added and
> ** (x) all classes that have an equivalent in "Commons Numbers" are deleted
> (MATH-1416).
> * (x) User guide
> * (x) Rename licence files (NUMBERS-146)
> * (/)
> [Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
> * (/) [Web site|http://commons.apache.org/numbers]
> * (/) [GitHub|https://github.com/apache/commons-numbers]
> * (/) [Travis|https://travis-ci.org/apache/commons-numbers]
> * (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
> * (/) Remove "@since" Javadoc tags
> * (/) Code coverage (Jacoco)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NUMBERS-146) Rename "LICENCE.txt" and "NOTICE.txt"
Gilles Sadowski created NUMBERS-146:
---
Summary: Rename "LICENCE.txt" and "NOTICE.txt"
Key: NUMBERS-146
URL: https://issues.apache.org/jira/browse/NUMBERS-146
Project: Commons Numbers
Issue Type: Sub-task
Components: arrays, combinatorics, complex, core, field, fraction,
gamma, primes, quaternion
Reporter: Gilles Sadowski
Fix For: 1.0
* Files {{LICENCE.txt}} should be renamed {{LICENCE}}.
* Files {{NOTICE.txt}} should be renamed {{NOTICE}}.
See [here|https://infra.apache.org/apply-license.html#license-file-name] and
[here|http://www.apache.org/dev/licensing-howto.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (COMMONSSITE-46) Multi-module projects fail when using the "rc" profile in commons-parent
[
https://issues.apache.org/jira/browse/COMMONSSITE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
WuShouXing updated COMMONSSITE-46:
--
Comment: was deleted
(was: How can I take this task
)
> Multi-module projects fail when using the "rc" profile in commons-parent
>
>
> Key: COMMONSSITE-46
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-46
> Project: Apache Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Niall Pemberton
>Priority: Major
> Attachments: commons-parent-pom.patch
>
>
> The "rc" profile doesn't current work with multi-module projects (when the
> project has not been previously installed in your local repo for the current
> version)
> For example running the following command on JCI
> {code}
> mvn -Prc clean install
> {code}
> fails with the following error:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Missing:
> --
> 1) org.apache.commons:commons-jci-core:jar:1.1-SNAPSHOT
> ...
> {code}
> I found this is caused by trying to run the site plugin in the "rc" profile:
> {code}
>
> maven-site-plugin
>
>
>
> site
>
> package
>
>
>
> {code}
> The intention of the above was so that when the assembly plugin ran to create
> the binary distros then the site would be available to include in the distro.
> AFAIK we are now only shipping javadocs in the binary distros and not any
> component sites. So I plan to remove the site plugin from the "rc" profile
> and add a "javadoc" goal in the javadoc plugin in the "rc" profile. This
> resolves the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMMONSSITE-46) Multi-module projects fail when using the "rc" profile in commons-parent
[
https://issues.apache.org/jira/browse/COMMONSSITE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072658#comment-17072658
]
WuShouXing commented on COMMONSSITE-46:
---
How can I take this task
> Multi-module projects fail when using the "rc" profile in commons-parent
>
>
> Key: COMMONSSITE-46
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-46
> Project: Apache Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Niall Pemberton
>Priority: Major
> Attachments: commons-parent-pom.patch
>
>
> The "rc" profile doesn't current work with multi-module projects (when the
> project has not been previously installed in your local repo for the current
> version)
> For example running the following command on JCI
> {code}
> mvn -Prc clean install
> {code}
> fails with the following error:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Missing:
> --
> 1) org.apache.commons:commons-jci-core:jar:1.1-SNAPSHOT
> ...
> {code}
> I found this is caused by trying to run the site plugin in the "rc" profile:
> {code}
>
> maven-site-plugin
>
>
>
> site
>
> package
>
>
>
> {code}
> The intention of the above was so that when the assembly plugin ran to create
> the binary distros then the site would be available to include in the distro.
> AFAIK we are now only shipping javadocs in the binary distros and not any
> component sites. So I plan to remove the site plugin from the "rc" profile
> and add a "javadoc" goal in the javadoc plugin in the "rc" profile. This
> resolves the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COMMONSRDF-83) apache
alen123 created COMMONSRDF-83: - Summary: apache Key: COMMONSRDF-83 URL: https://issues.apache.org/jira/browse/COMMONSRDF-83 Project: Apache Commons RDF Issue Type: Improvement Components: build Affects Versions: 0.3.0 Reporter: alen123 Fix For: 0.6.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] coveralls commented on issue #118: Fixed the typo and deal the NPE with Objects.requireNonNull
coveralls commented on issue #118: Fixed the typo and deal the NPE with Objects.requireNonNull URL: https://github.com/apache/commons-collections/pull/118#issuecomment-607092265 [](https://coveralls.io/builds/29762026) Coverage increased (+0.03%) to 90.007% when pulling **4c1560bf29d9b745ac0f4f6aa51a70c5dafc772c on dota17:TypoAbstractLinkedList** into **a6d53a7649dcc82c44738a517b44422b61696b1d on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
