[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035682#comment-16035682
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
The packageinfo files are in the source tree because they're source files,
and provide metadata for the package.
You can also use a package annotation on package-info.java, which puts a
Class Retention annotation on the packages package-info.class.

Examples:


https://github.com/apache/felix/blob/trunk/dependencymanager/org.apache.felix.dependencymanager.annotation/src/org/apache/felix/dm/annotation/api/packageinfo

https://github.com/apache/felix/blob/trunk/converter/
converter/src/main/java/org/apache/felix/converter/dto/package-info.java

(Requires provided / compileOnly dependency on the osgi annotation bundle).

On Fri, Jun 2, 2017 at 6:11 PM, Jörg Schaible 
wrote:

> Why are those packageinfo files in src/main/java instead of
> src/main/resources as it is common in Maven builds? Now you have to
> configure explicitly these files as resources. On top of it, I don't like
> the idea of modifying these files for each release manually. I'd look for 
a
> solution that generates these files automatically into
> target/generated-resources. Such a plugin should not be difficult.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035516#comment-16035516
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

Github user joehni commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Why are those packageinfo files in src/main/java instead of 
src/main/resources as it is common in Maven builds? Now you have to configure 
explicitly these files as resources. On top of it, I don't like the idea of 
modifying these files for each release manually. I'd look for a solution that 
generates these files automatically into target/generated-resources. Such a 
plugin should not be difficult.


> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (POOL-325) testOnReturn() available as asynchronous

[Jason Hill (JIRA)]

 [ 
https://issues.apache.org/jira/browse/POOL-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Hill updated POOL-325:

Description: 
I am using Pool2 as part of DBCP2 framework and I immediately found minor 
performance issues with using testOnBorrow/testOnCreate only because the 
waiting request is dependent on validation step to complete before the 
transaction can complete.

I opted instead for testWhileIdle and testOnReturn to reduce impact on live 
transactions. I assumed incorrectly that the testOnReturn would be asynchronous 
to prevent the transaction from further waiting on validation procedure. I 
cannot think of a case where testOnReturn is as or more valuable than 
testOnBorrow unless it provided an asynchronous advantage. I am interested to 
hear the intended value?

Either way, I am proposing that testOnReturn provide asynchronous behavior by 
default or allow a configurable flag to enable async behavior.

https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=blob;f=src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java;h=816c6cf54aad612805b9d48139a3f87b505c0bd8;hb=HEAD

CURRENT:
 548 if (getTestOnReturn()) {
 549 if (!factory.validateObject(p)) {
 550 try {
 551 destroy(p);
 552 } catch (final Exception e) {
 553 swallowException(e);
 554 }
 555 try {
 556 ensureIdle(1, false);
 557 } catch (final Exception e) {
 558 swallowException(e);
 559 }
 560 updateStatsReturn(activeTime);
 561 return;
 562 }
 563 }

  was:
I am using Pool2 as part of DBCP2 framework and I immediately found minor 
performance issues with using testOnBorrow/testOnCreate only because the 
waiting request is dependent on validation step to complete before the 
transaction can complete.

I opted instead for testWhileIdle and testOnReturn to reduce impact on live 
transactions. I assumed incorrectly that the testOnReturn would be asynchronous 
to prevent the transaction from further waiting on validation procedure. I 
cannot think of a case where testOnReturn is as or more valuable than 
testOnBorrow unless it provided an asynchronous advantage. I am interested to 
hear the intended value?

Either way, I am proposing that testOnBorrow provide asynchronous behavior by 
default or allow a configurable flag to enable async behavior.

https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=blob;f=src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java;h=816c6cf54aad612805b9d48139a3f87b505c0bd8;hb=HEAD
CURRENT:
 548 if (getTestOnReturn()) {
 549 if (!factory.validateObject(p)) {
 550 try {
 551 destroy(p);
 552 } catch (final Exception e) {
 553 swallowException(e);
 554 }
 555 try {
 556 ensureIdle(1, false);
 557 } catch (final Exception e) {
 558 swallowException(e);
 559 }
 560 updateStatsReturn(activeTime);
 561 return;
 562 }
 563 }


> testOnReturn() available as asynchronous
> 
>
> Key: POOL-325
> URL: https://issues.apache.org/jira/browse/POOL-325
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 2.4
>Reporter: Jason Hill
>Priority: Minor
>  Labels: performance
>
> I am using Pool2 as part of DBCP2 framework and I immediately found minor 
> performance issues with using testOnBorrow/testOnCreate only because the 
> waiting request is dependent on validation step to complete before the 
> transaction can complete.
> I opted instead for testWhileIdle and testOnReturn to reduce impact on live 
> transactions. I assumed incorrectly that the testOnReturn would be 
> asynchronous to prevent the transaction from further waiting on validation 
> procedure. I cannot think of a case where testOnReturn is as or more valuable 
> than testOnBorrow unless it provided an asynchronous advantage. I am 
> interested to hear the intended value?
> Either way, I am proposing that testOnReturn provide asynchronous behavior by 
> default or allow a configurable flag to enable async behavior.
> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=blob;f=src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java;h=816c6cf54aad612805b9d48139a3f87b505c0bd8;hb=HEAD
> CURRENT:
>  548 if (getTestOnReturn()) {
>  549 if (!factory.validateObject(p)) {
>  550 try {
>  551 destroy(p);
>  552 } catch (final Exception e) {
>  553 

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035372#comment-16035372
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
It's difficult to generalize, since the packageinfo files have to be put in
with the source code. Since a  export header parameter with an explicit
version overrides packageinfo and annotations, defaults can be problematic.

Adding the resource copy and rat excludes is good, as is keeping up with
the felix bundle versions.

Adding a bundle:baseline goal to the parent verify phase is a really,
really good idea if bundle headers are going to be generated. Package
versions MUST  follow semver (bundle versions also, but to a lesser
extent).


Maven versions theoretically ought to too, but dependencies are usually
point versions not ranges.

(Of course, there's always guava, where version is a major release, except
for bug fixes, which are minor.)

The real  work is getting the api and implementation(s) properly
modularized so that the api isn't always affected by implementation
changes.  At least jigsaw has gotten people to start thinking about
modules. Not always sensibly

On Jun 2, 2017 2:38 PM, "Gary Gregory"  wrote:

> Hi,
>
> Should any of this work also apply to commons-parent?
>
> Gary
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035210#comment-16035210
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

Github user garydgregory commented on the issue:

https://github.com/apache/commons-compress/pull/26
  
Hi,

Should any of this work also apply to commons-parent?

Gary


> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035115#comment-16035115
 ] 

Simon Spero commented on COMPRESS-399:
--

(plus a on-line commit to add **/packageinfo to the rat excludes.  Gets me 
EVERY SINGLE TIME! :)

> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035088#comment-16035088
 ] 

ASF GitHub Bot commented on COMPRESS-399:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/26

COMPRESS-399 OSGI package versions are overly pessimistic, except when 
they're overly optimisic

- Add packageinfo files for per-package version settings.
  - Initialize to 1.14
  - Copy packageinfo files in resource phase.

- Use latest bundle plugin.
  - Remove  headers from generate manifest.
  - Pretty-print the manifest.
  - Add bundle:baseline to the verify phase
  - Add bundle:baseline-report to the site phase
- To change the base version from default (i.e. previous release) set 
comparisonVersion property
- Change travis build to use verify instead of test 

Signed-off-by: Simon Spero 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-399

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/26.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #26






> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (VALIDATOR-426) Support MasterCards with new 2 Series BIN

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VALIDATOR-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved VALIDATOR-426.

Resolution: Duplicate

AFAIK this was fixed some while ago, and should be in version 1.6.
If not, please re-open with a simple test case

> Support MasterCards with new 2 Series BIN
> -
>
> Key: VALIDATOR-426
> URL: https://issues.apache.org/jira/browse/VALIDATOR-426
> Project: Commons Validator
>  Issue Type: Bug
>  Components: CreditCard
>Affects Versions: 1.6
>Reporter: Ian Springer
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BIN Range is 222100-272099 and went into effect as of June 2017.
> See http://www.merchantlink.com/ready-mastercard-2-series-bin/.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034816#comment-16034816
 ] 

Simon Spero commented on COMPRESS-399:
--

I ended up doing the third option, which probably needs a squashing. 

There's a tool to tell you when to bump... it's a different goal  (baseline) of 
the plugin you'e already using. 

It's already set up in all three branches, and will fail the build at the 
verify stage if the version numbers are mismatched. 

[For semantic versioning, major versions  are needed for any  breaking api 
changes.  Breaking apis is usually not a good thing, but it's better to make it 
obvious than to hide it.
 
 The good thing about osgi modularity is that internal changes to private 
packages don't count.  Also, when resolving a module, as long as there's some 
set of versions of every required dependency packages that are consistent with 
all package version constraints,  a bundle can be resolved.  So if my module 
needs to use packages from modules A and B, with the former requiring a package 
from Compress between 1.4 and 2, and the latter requiring one between 1.5 and 
2, the system will use package version 1.5.  This is fine, as long as only 
non-breaking changes happened.  

 The trouble with OSGI is that until you understand why it does things the way 
it does, it just seems ridiculously complicated, and until you learn about the 
bits that are there to take care of the complexity for you (e.g. Declarative 
Services), handling the dynamic of the environment is painful. 
I hated it until I started trying to work with Jigsaw early last year. The 
issues with jigsaw help explain a  lot of the design decisions in OSGI  ]

> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (VALIDATOR-426) Support MasterCards with new 2 Series BIN

[Ian Springer (JIRA)]

Ian Springer created VALIDATOR-426:
--

 Summary: Support MasterCards with new 2 Series BIN
 Key: VALIDATOR-426
 URL: https://issues.apache.org/jira/browse/VALIDATOR-426
 Project: Commons Validator
  Issue Type: Bug
  Components: CreditCard
Affects Versions: 1.6
Reporter: Ian Springer


The BIN Range is 222100-272099 and went into effect as of June 2017.

See http://www.merchantlink.com/ready-mastercard-2-series-bin/.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034768#comment-16034768
 ] 

Simon Spero commented on COMPRESS-390:
--

[~bodewig] - the XZ dependency was just the easiest hack. Annoyingly, it's an 
abstract class, not an interface.  SeekableChannels are probably where the 
actual answers lie :)

> Expose zip stream offset and size via API
> -
>
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Affects Versions: 1.13
>Reporter: Zbynek Vyskovsky
>  Labels: features, github-import, patch
> Fix For: 1.14
>
>
> In certain cases it may be useful to get information about where in the 
> archive the stream starts and ends. Typically when zip is used as resource 
> container and the resources are then mapped directly into memory, but not 
> only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make 
> sense to put this into basic interface - ArchiveEntry. But not necessarily 
> all of them have to support it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-401) Index out of bound when using FramedLZ4CompressorOutputStream or BlockLZ4CompressorOutputStream

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034457#comment-16034457
 ] 

Stefan Bodewig commented on COMPRESS-401:
-

This very likely depends on the input. Can you share the file that causes the 
exception?

It would be good if you could provide the stack trace of the exception you 
receive.

As for the examples, it would help if you could point out the errors a bit more 
explicitly ;-)

> Index out of bound when using FramedLZ4CompressorOutputStream or 
> BlockLZ4CompressorOutputStream
> ---
>
> Key: COMPRESS-401
> URL: https://issues.apache.org/jira/browse/COMPRESS-401
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.14
>Reporter: Manuel Pagliai
>
> The following java snippets fail with an index out of bound exception
> FileInputStream fis = new FileInputStream(new 
> File("P:\\Data\\orders_5m.csv"));
> FileOutputStream fos = new FileOutputStream(new 
> File("P:\\Data\\orders_5m.csv.lz4"));
> BufferedOutputStream out = new BufferedOutputStream(fos);
> FramedLZ4CompressorOutputStream lzOut = new 
> FramedLZ4CompressorOutputStream(out);
> 
> final byte[] buffer = new byte[1 * 1024 * 1024];
> int n = 0;
> while (-1 != (n = fis.read(buffer))) {
> lzOut.write(buffer, 0, n);
> }
> lzOut.close();
> fis.close();
> Also the Lz4 Example in 
> https://commons.apache.org/proper/commons-compress/examples.html contains 
> errors



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COMPRESS-401) Index out of bound when using FramedLZ4CompressorOutputStream or BlockLZ4CompressorOutputStream

[Manuel Pagliai (JIRA)]

Manuel Pagliai created COMPRESS-401:
---

 Summary: Index out of bound when using 
FramedLZ4CompressorOutputStream or BlockLZ4CompressorOutputStream
 Key: COMPRESS-401
 URL: https://issues.apache.org/jira/browse/COMPRESS-401
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.14
Reporter: Manuel Pagliai


The following java snippets fail with an index out of bound exception

FileInputStream fis = new FileInputStream(new 
File("P:\\Data\\orders_5m.csv"));
FileOutputStream fos = new FileOutputStream(new 
File("P:\\Data\\orders_5m.csv.lz4"));

BufferedOutputStream out = new BufferedOutputStream(fos);
FramedLZ4CompressorOutputStream lzOut = new 
FramedLZ4CompressorOutputStream(out);

final byte[] buffer = new byte[1 * 1024 * 1024];
int n = 0;
while (-1 != (n = fis.read(buffer))) {
lzOut.write(buffer, 0, n);
}
lzOut.close();
fis.close();


Also the Lz4 Example in 
https://commons.apache.org/proper/commons-compress/examples.html contains errors



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034302#comment-16034302
 ] 

Stefan Bodewig commented on COMPRESS-400:
-

Sounds like a good idea.

We could try to prevent people from setting headers that might be set by our 
output stream itself (path, linkpath, size, gid, mtime, uid, mode, 
SCHILY.devmajor and SCHILY.devminor as of 1.14) but I'm not sure this is worth 
the effort. If people really want to set those values themselves, they should 
get what they want IMHO.

> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034292#comment-16034292
 ] 

Stefan Bodewig commented on COMPRESS-399:
-

I must admit that OSGi has been a low priority for us, likely neither of the 
people working on Compress uses OSGi.

Personally I'd go with your third option. Is there some sort of tooling that 
would tell us we are changing a package in an incompatible way so we'd know 
when to bump anything? We do run japicmp 
http://commons.apache.org/proper/commons-compress/japicmp.html but I'm not sure 
it is reliable enough.

At first I was afraid using new major versions would cause trouble when/if we 
ever wanted to create a Compress 2.0, but then again we would change the base 
package to be org.apache.commons.compress2 for this release.

> OSGI package versions are overly pessimistic, except when they're overly 
> optimisic 
> ---
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly 
> generated.  OSGI relies on package version numbers following semantic version 
> properly for correct resolution.  
> Current version numbers have been generated from the maven version. This has 
> lead to new minor version increases for packages that have no API changed; it 
> has also concealed   major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the 
> package version. These are picked up by the bundle manifest generator, and 
> are used if no explicit version is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor 
> changes to 2.0.0.  This makes the bundle correct, but does not fix improper 
> import declarations made by users of earlier bundles.   
> One branch uses the version number  from the oldest version that has no 
> changes when compared to HEAD, and which has not had any breaking changes 
> since 1.0.0.  This will fail the build because version numbers should be 
> increasing, and may cause issues if an importing bundle uses a range that 
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be 
> version 1.14.0, and just bump major versions when required going forward. The 
> bulk of the major changes happened a good few versions back,  so it's not as 
> bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034289#comment-16034289
 ] 

Stefan Bodewig commented on COMPRESS-390:
-

[~sesuncedu] the changes to tar sound useful, although I'd be reluctant adding 
a dependency on XZ for Java for reading tars (right now XZ is optional unless 
you are really trying to use XZ or LZMA). That would be a separate issue, 
though. :-)

> Expose zip stream offset and size via API
> -
>
> Key: COMPRESS-390
> URL: https://issues.apache.org/jira/browse/COMPRESS-390
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Affects Versions: 1.13
>Reporter: Zbynek Vyskovsky
>  Labels: features, github-import, patch
> Fix For: 1.14
>
>
> In certain cases it may be useful to get information about where in the 
> archive the stream starts and ends. Typically when zip is used as resource 
> container and the resources are then mapped directly into memory, but not 
> only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make 
> sense to put this into basic interface - ArchiveEntry. But not necessarily 
> all of them have to support it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)