Re: [pool] RC time

[Eric Bresie]

Which indicates:

"This document is meant as a step-by-step recipe to achieve the release of
the Commons RNG component. Note that more general instructions valid
for all components, including [rng], are available on the Apache Commons
main site: at *"https://commons.apache.org/releases/prepare.html
<https://commons.apache.org/releases/prepare.html>"* and
*"https://commons.apache.org/releases/release.html
<https://commons.apache.org/releases/release.html>"*


Eric Bresie
ebre...@gmail.com


On Sat, Sep 16, 2023 at 7:32 PM Gilles Sadowski 
wrote:

> Le sam. 16 sept. 2023 à 23:54, Phil Steitz  a
> écrit :
> >
> > It has been quite a few years since I cut a Commons release, but I would
> > like to step up for pool 2.12.  I think the code in the 2_X branch is
> > ready.  All of my soak tests and tests with my own apps and dbcp
> passed.  I
> > am sure a lot has changed since I last did this.  Is there a checklist or
> > instructions somewhere?
>
>
> https://github.com/apache/commons-rng/blob/master/doc/release/release.howto.txt
>
> >
> > Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] contribution proposal for multivariate functions optimization (2)

[Eric Bresie]

Would fork/cloning from the following and raise a PR work to provide the
code?

https://github.com/apache/commons-math

Although there does appear to be a few PRs waiting to be merged there
presently.

Eric

On Tue, Dec 27, 2022 at 5:02 PM Gilles Sadowski 
wrote:

> Hi.
>
> Le mar. 27 déc. 2022 à 23:30, François Laferrière
>  a écrit :
> >
> >  Hello,
> > I am finally done with a draft version of multivariate optimizers
> (gradient descent, Newton-Raphson, BFGS) that fits the legacy API design
> and class hierarchy.
>
> Thanks!
>
> > The new code is compliant with checkstyle rule.
> > My question is : "what's next?".
>
> Post the code somewhere so that it can be reviewed. :-)
>
> > I suppose that I should have access to a specific git branch so that I
> can submit my code as a pull request?
>
> Is there a reason not to use the "master" branch?
>
> > Or is there another specific process?
>
> Providing a patch through JIRA is also possible (cf. below).
>
> > By the way, I have not been able to create a JIRA account.
>
> Instructions are here:
> https://infra.apache.org/jira-guidelines.html#who
>
> Best,
> Gilles
>
> >>> [...]
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> --
Eric Bresie
ebre...@gmail.com

Re: Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Eric Bresie]

I’ve not used it so not sure but would this help any in migrating the namespace?

https://github.com/apache/tomcat-jakartaee-migration

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla  (mailto:rich...@zowalla.com)> wrote:
> Sure. Sounds like a plan :)
>
> Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory 
> mailto:garydgreg...@gmail.com)>:
> > I think we should wait for a little while: I'd want to release current code
> > from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
> > all is well, then see about going to DBCP 3, on Java 8 for now but
> > considering Java 11 maybe. Do consider that the Commons community is small
> > and I would not want to support concurrent support and releases on bothe
> > DBCP 2 and 3.
> >
> > Gary
> >
> > Gary
> >
> > On Sat, Dec 17, 2022, 14:12 Richard Zowalla  > (mailto:r...@apache.org)> wrote:
> >
> > > For DBCP, it basically boils down to
> > >
> > > BasicManagedDataSource.java
> > > DataSourceXAConnectionFactory.java
> > > LocalXAConnectionFactory.java
> > > SynchronizationAdapter.java
> > > TransactionContext.java
> > > TransactionRegistry.java
> > >
> > > Looking at these classes, the move to jakarta definitley affects binary
> > > compatibility as we have changes in return types / arguments of public
> > > methods. Given that it breaks binary compatibility, we could even
> > > increase the java level to 11 and drop deprecated things in a potential
> > > dbcp 3.
> > >
> > > In the end, I am happy with everything, which brings DBCP into the
> > > Jakarta world ;)
> > >
> > > If we have consensus for a route, I am happy to work on it / make it
> > > happen via related PRs but would need some guideance on the best way to
> > > move forward.
> > >
> > > Gruß
> > > Richard
> > >
> > > Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > > > If not done in new classes (both can live in the same lib
> > > > technically),
> > > > sadly yes.
> > > >
> > > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  > > > (mailto:rich...@zowalla.com)> a
> > > > écrit :
> > > >
> > > > > Thanks for your replies.
> > > > >
> > > > > I guess, that switching the namespace leads to binary
> > > > > incompatibility (If
> > > > > I take the definition from [1]). I cannot drop it in a running JVM
> > > > > / app
> > > > > and expect no issues with it as the related APIs are breaking
> > > > > namespace
> > > > > changes (at least at runtime if they aren't present) :-)
> > > > >
> > > > > Aside from that fact, method signatures might also change from
> > > > > javax ->
> > > > > jakarta, which would require a short investigation and usage of the
> > > > > existing tooling to see if this happens.
> > > > >
> > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > right?
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > >
> > > > > [1]
> > > > >
> > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > >
> > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > mailto:ma...@apache.org)>:
> > > > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > > > Thank you Richard for starting this thread.
> > > > > > >
> > > > > > > My view is simpler perhaps: I would not make this about the
> > > > > > > javax vs
> > > > > > > Jakarta namespaces.
> > > > > > >
> > > > > > > I don't want to double the numbers of jars we produce from the
> > > > > > > same
> > > > > branch
> > > > > > > for affected components as one of the scheme proposed. It feels
> > > > > > > like a
> > > > > > > burden to maintenance moving forward and a very brittle process
> > > > > > > with
> > > > > some
> > > > > > > unforeseen side effects.
> > > > > > &g

(RestJiraDownloader) Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC1

[Eric Bresie]

C1
> >
> > 2) Check Apache licenses
> >
> > This step is not required if the site includes a RAT report page which
> > you then must check.
> >
> > mvn apache-rat:check
> >
> > 3) Check binary compatibility
> >
> > Older components still use Apache Clirr:
> >
> > This step is not required if the site includes a Clirr report page
> > which you then must check.
> >
> > mvn clirr:check
> >
> > Newer components use JApiCmp with the japicmp Maven Profile:
> >
> > This step is not required if the site includes a JApiCmp report page
> > which you then must check.
> >
> > mvn install -DskipTests -P japicmp japicmp:cmp
> >
> > 4) Build the package
> >
> > mvn -V clean package
> >
> > You can record the Maven and Java version produced by -V in your VOTE
> reply.
> > To gather OS information from a command line:
> > Windows: ver
> > Linux: uname -a
> >
> > 5) Build the site for a single module project
> >
> > Note: Some plugins require the components to be installed instead of
> packaged.
> >
> > mvn site
> > Check the site reports in:
> > - Windows: target\site\index.html
> > - Linux: target/site/index.html
> >
> > -the end-
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> --
Eric Bresie
ebre...@gmail.com

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

https://www.apache.org/security/

Get Outlook for iOS

From: Roman Wagner 
Sent: Monday, October 10, 2022 4:44:58 PM
To: dev@commons.apache.org 
Subject: RE: Re: [jxpath] reported CVE and path forward

Hi all,

I am working for Code Intelligence and we did our best to find a maintainer
for the oss-fuzz project Unfortunately, we've have failed and got no
feedback until now, but It seems to be an unmaintained project except for
some typo fixes since some years. I am not sure yet to which mailing list
the bug report was send to, but I will check that information with the team.

However, I am really happy that there is some interest in fixing the RCE. I
have verified the vulnerability and for me it seems to be a valid
RCE. @Mark Thomas should we continue to discuss further details via
secur...@apache.org? We would like to support the fix process.

Best regards
Roman

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

Or is that this 
https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Eric Bresie 
Sent: Monday, October 10, 2022 4:22:42 PM
To: Commons Developers List 
Subject: Re: [jxpath] reported CVE and path forward

So then discussed here (1) (which assume is what’s being done here) and bugs 
raised here (2)?  Has (2) been done yet?

  1.  https://commons.apache.org/proper/commons-jxpath/mail-lists.html
  2.  https://commons.apache.org/proper/commons-jxpath/issue-tracking.html


Get Outlook for iOS<https://aka.ms/o0ukef>

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 4:15:03 PM
To: Commons Developers List 
Subject: Re: [jxpath] reported CVE and path forward

Hi Eric,

For my understanding, is oss-fuzz an open source project that is maintained
> and managed by Google (and is not an Apache project) but is for “fuzz
> testing” with portion focused on Apache common products?
>

That's my understanding too, although I am not sure if it is maintained and
managed solely by Google. But you are correct in that oss-fuzz is not an
Apache project. It is an external service similar to GitHub Actions,
Dependabot, Codecov, etc.

So am I correct in saying run oss-fuzz against Apache-common, which may
> find problems in commons.  So any findings would be identified as a bug and
> fix as applicable?
>

That sounds correct to me.

There is an apache-commons oss-fuzz project created in the oss-fuzz GitHub
repository. That becomes a project in the oss-fuzz web system which I and
other ASF members have access to - anyone from ASF can request access:
https://oss-fuzz.com

It was created some time ago, and Commons Imaging was one of the first
included. We (ASF Commons) were involved in setting up that project, so
that someone from ASF would receive notifications (by being CC'ed in
oss-fuzz notifications). We decided against using the dev-list, so only
those that volunteered at the time receive emails.

I checked the GitHub repository today, and found other Commons Components,
that are not part of the apache-commons project, and that have the
notifications configured to emails of a security company. So in this case
the findings in Commons repositories would be identified as a bug and
report to that company, without - as far as I can tell - involvement of ASF
Commons devs.

Hope that clarifies,

Bruno


On Tue, 11 Oct 2022 at 10:06, Eric Bresie  wrote:

> For my understanding, is oss-fuzz an open source project that is
> maintained and managed by Google (and is not an Apache project) but is for
> “fuzz testing” with portion focused on Apache common products?
>
> So am I correct in saying run oss-fuzz against Apache-common, which may
> find problems in commons.  So any findings would be identified as a bug and
> fix as applicable?
>
>
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 3:51:30 PM
> To: Commons Developers List 
> Subject: Re: Re: [jxpath] reported CVE and path forward
>
> Hi Matt,
>
> I am also subscribed to oss-fuzz for Imaging.
>
> Looks like someone added jxpath to oss-fuzz here:
> https://github.com/google/oss-fuzz/pull/7582
>
> The initial oss-fuzz for ASF was, if I recall correctly, all put under a
> single project:
> https://github.com/google/oss-fuzz/tree/master/projects/apache-commons
>
> If you go one level higher in that repository link, you will see there are
> now other projects in oss-fuzz for other Commons components.
>
> The apache-commons project (that contains Imaging, Compress, and Geometry)
> had a custom policy, agreed in the mailing list and later with someone that
> maintained oss-fuzz, where ASF issues were not disclosed in 90 days, but
> instead gave us more time to align the issues with our ASF process.
>
> I am not sure if these other projects follow similar policy, nor if the ASF
> developers are aware of the integration (I only keep an eye on
> compress/imaging/geometry notifications from the apache-commons project).
> Also not sure whether it's better to have everything in a single project in
> oss-fuzz or in separate projects. I'm happy with Imaging being a single
> oss-fuzz project if needed, but I prefer to keep the policy of giving a
> longer time to review the issues. I try to review important issues quickly,
> but the ones that I know are very low priority or won't be fixed (e.g. OOM)
> I leave for later.
>
> Cheers
> Bruno
>
> On Tue, 11 Oct 2022 at 09:01, Matt Sicker  wrote:
>
> > I get emails about some of the Commons fuzzing things, but I was only
> > aware of it being enabled for compress and imaging.
> >
> > On Mon, Oct 10, 2022 at 1:37 PM 

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

So then discussed here (1) (which assume is what’s being done here) and bugs 
raised here (2)?  Has (2) been done yet?

  1.  https://commons.apache.org/proper/commons-jxpath/mail-lists.html
  2.  https://commons.apache.org/proper/commons-jxpath/issue-tracking.html


Get Outlook for iOS<https://aka.ms/o0ukef>

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 4:15:03 PM
To: Commons Developers List 
Subject: Re: [jxpath] reported CVE and path forward

Hi Eric,

For my understanding, is oss-fuzz an open source project that is maintained
> and managed by Google (and is not an Apache project) but is for “fuzz
> testing” with portion focused on Apache common products?
>

That's my understanding too, although I am not sure if it is maintained and
managed solely by Google. But you are correct in that oss-fuzz is not an
Apache project. It is an external service similar to GitHub Actions,
Dependabot, Codecov, etc.

So am I correct in saying run oss-fuzz against Apache-common, which may
> find problems in commons.  So any findings would be identified as a bug and
> fix as applicable?
>

That sounds correct to me.

There is an apache-commons oss-fuzz project created in the oss-fuzz GitHub
repository. That becomes a project in the oss-fuzz web system which I and
other ASF members have access to - anyone from ASF can request access:
https://oss-fuzz.com

It was created some time ago, and Commons Imaging was one of the first
included. We (ASF Commons) were involved in setting up that project, so
that someone from ASF would receive notifications (by being CC'ed in
oss-fuzz notifications). We decided against using the dev-list, so only
those that volunteered at the time receive emails.

I checked the GitHub repository today, and found other Commons Components,
that are not part of the apache-commons project, and that have the
notifications configured to emails of a security company. So in this case
the findings in Commons repositories would be identified as a bug and
report to that company, without - as far as I can tell - involvement of ASF
Commons devs.

Hope that clarifies,

Bruno


On Tue, 11 Oct 2022 at 10:06, Eric Bresie  wrote:

> For my understanding, is oss-fuzz an open source project that is
> maintained and managed by Google (and is not an Apache project) but is for
> “fuzz testing” with portion focused on Apache common products?
>
> So am I correct in saying run oss-fuzz against Apache-common, which may
> find problems in commons.  So any findings would be identified as a bug and
> fix as applicable?
>
>
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 3:51:30 PM
> To: Commons Developers List 
> Subject: Re: Re: [jxpath] reported CVE and path forward
>
> Hi Matt,
>
> I am also subscribed to oss-fuzz for Imaging.
>
> Looks like someone added jxpath to oss-fuzz here:
> https://github.com/google/oss-fuzz/pull/7582
>
> The initial oss-fuzz for ASF was, if I recall correctly, all put under a
> single project:
> https://github.com/google/oss-fuzz/tree/master/projects/apache-commons
>
> If you go one level higher in that repository link, you will see there are
> now other projects in oss-fuzz for other Commons components.
>
> The apache-commons project (that contains Imaging, Compress, and Geometry)
> had a custom policy, agreed in the mailing list and later with someone that
> maintained oss-fuzz, where ASF issues were not disclosed in 90 days, but
> instead gave us more time to align the issues with our ASF process.
>
> I am not sure if these other projects follow similar policy, nor if the ASF
> developers are aware of the integration (I only keep an eye on
> compress/imaging/geometry notifications from the apache-commons project).
> Also not sure whether it's better to have everything in a single project in
> oss-fuzz or in separate projects. I'm happy with Imaging being a single
> oss-fuzz project if needed, but I prefer to keep the policy of giving a
> longer time to review the issues. I try to review important issues quickly,
> but the ones that I know are very low priority or won't be fixed (e.g. OOM)
> I leave for later.
>
> Cheers
> Bruno
>
> On Tue, 11 Oct 2022 at 09:01, Matt Sicker  wrote:
>
> > I get emails about some of the Commons fuzzing things, but I was only
> > aware of it being enabled for compress and imaging.
> >
> > On Mon, Oct 10, 2022 at 1:37 PM Roman Wagner
> >  wrote:
> > >
> > > Hi all,
> > >
> > > I am working for Code Intelligence we did our best to find a maintainer
> > for
> > > the oss-fuzz project. Unfortunately we've got no feedback until now,
> but
> > It
> > > seems to be a

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

For my understanding, is oss-fuzz an open source project that is maintained and 
managed by Google (and is not an Apache project) but is for “fuzz testing” with 
portion focused on Apache common products?

So am I correct in saying run oss-fuzz against Apache-common, which may find 
problems in commons.  So any findings would be identified as a bug and fix as 
applicable?


Get Outlook for iOS

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 3:51:30 PM
To: Commons Developers List 
Subject: Re: Re: [jxpath] reported CVE and path forward

Hi Matt,

I am also subscribed to oss-fuzz for Imaging.

Looks like someone added jxpath to oss-fuzz here:
https://github.com/google/oss-fuzz/pull/7582

The initial oss-fuzz for ASF was, if I recall correctly, all put under a
single project:
https://github.com/google/oss-fuzz/tree/master/projects/apache-commons

If you go one level higher in that repository link, you will see there are
now other projects in oss-fuzz for other Commons components.

The apache-commons project (that contains Imaging, Compress, and Geometry)
had a custom policy, agreed in the mailing list and later with someone that
maintained oss-fuzz, where ASF issues were not disclosed in 90 days, but
instead gave us more time to align the issues with our ASF process.

I am not sure if these other projects follow similar policy, nor if the ASF
developers are aware of the integration (I only keep an eye on
compress/imaging/geometry notifications from the apache-commons project).
Also not sure whether it's better to have everything in a single project in
oss-fuzz or in separate projects. I'm happy with Imaging being a single
oss-fuzz project if needed, but I prefer to keep the policy of giving a
longer time to review the issues. I try to review important issues quickly,
but the ones that I know are very low priority or won't be fixed (e.g. OOM)
I leave for later.

Cheers
Bruno

On Tue, 11 Oct 2022 at 09:01, Matt Sicker  wrote:

> I get emails about some of the Commons fuzzing things, but I was only
> aware of it being enabled for compress and imaging.
>
> On Mon, Oct 10, 2022 at 1:37 PM Roman Wagner
>  wrote:
> >
> > Hi all,
> >
> > I am working for Code Intelligence we did our best to find a maintainer
> for
> > the oss-fuzz project. Unfortunately we've got no feedback until now, but
> It
> > seems to be an unmaintained project except for some typo fixes since some
> > years. I am not sure yet to which mailing list the bug report was send
> to,
> > but I will check that information with the team.
> >
> > However, I am really happy that there is some interest in fixing the
> RCE. I
> > have verified the vulnerability and for me it seems to be a valid
> > RCE. @Mark Thomas should we continue to discuss further details via
> > secur...@apache.org?
> >
> > Best regards
> > Roman
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)

[Eric Bresie]

Does any of this help?
(1) https://commons.apache.org/releases/index.html
(2) https://infra.apache.org/release-publishing.html

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On July 17, 2022 at 2:59:26 PM CDT, Gary Gregory  (mailto:garydgreg...@gmail.com)> wrote:
> Yeah, there is code that looks odd for 2022, like a custom Closeable
> interface instead of reusing the JRE's. I'll take a look.
>
> Gary
>
> On Sun, Jul 17, 2022 at 2:32 PM Matt Juntunen  (mailto:matt.a.juntu...@gmail.com)> wrote:
> >
> > Sounds good. Do you know of anything else that needs to be done? I'm
> > guessing we can hold off on a full 1.x migration guide until the full
> > 2.0.0 version.
> >
> > -Matt J
> >
> > On Sun, Jul 17, 2022 at 2:13 PM Gary Gregory  > (mailto:garydgreg...@gmail.com)> wrote:
> > >
> > > We should at least remove deprecated elements.
> > >
> > > Gary
> > >
> > > On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen
> > > mailto:matt.a.juntu...@gmail.com)> wrote:
> > > >
> > > > I am going to put the 2.0.0-beta1 release on my TODO list. I am
> > > > currently working toward a release of commons-text, so I can't be sure
> > > > on a timeline. If anyone has questions or time to pick this up, please
> > > > let me know.
> > > >
> > > > Regards,
> > > > Matt J
> > > >
> > > > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen
> > > > mailto:matt.a.juntu...@gmail.com)> wrote:
> > > > >
> > > > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does
> > > > > anyone have availability to lead the release?
> > > > >
> > > > > Regards,
> > > > > Matt J
> > > > >
> > > > > On Wed, Jul 13, 2022 at 9:35 AM sebb  > > > > (mailto:seb...@gmail.com)> wrote:
> > > > > >
> > > > > > It looks like Commons does not have the concept of Alpha releases.
> > > > > >
> > > > > > https://commons.apache.org/releases/versioning.html
> > > > > >
> > > > > > Sorry, I must have been thinking of a different project.
> > > > > >
> > > > > > Sebb
> > > > > >
> > > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory  > > > > > (mailto:garydgreg...@gmail.com)> wrote:
> > > > > > >
> > > > > > > A beta is a good idea IMO.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen 
> > > > > > > mailto:matt.a.juntu...@gmail.com)> 
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Based on what I'm hearing, I'm thinking a beta release might be
> > > > > > > > appropriate. That would give consumers a chance to move away 
> > > > > > > > from the
> > > > > > > > previous version while giving us a chance to test and fine-tune 
> > > > > > > > the
> > > > > > > > API. Thoughts?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Matt J
> > > > > > > >
> > > > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger 
> > > > > > > > mailto:f...@grueninger.de)>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Publishing a first release candidate might help. Currently 
> > > > > > > > > there is no
> > > > > > > > > indication for anybody to invest in testing FileUpload.
> > > > > > > > >
> > > > > > > > > In doubt: release early, release often. People are using 
> > > > > > > > > FileUpload
> > > > > > > > > together with vulnerable dependencies!
> > > > > > > > >
> > > > > > > > > Bye
> > > > > > > > > Christoph
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

Re: [commons-text] branch master updated: Bump checkstyle from 9.3 to 10.2

[Eric Bresie]

So at what point do we consider updating to new required Java version?

From: Gary Gregory 
Sent: Saturday, May 21, 2022 8:48 AM
To: Commons Developers List 
Subject: Re: [commons-text] branch master updated: Bump checkstyle from 9.3 to 
10.2

-1

Please stop updating checkstyle to 10.2 because it breaks the build as
10.2 requires Java 11.

Gary

On Fri, May 20, 2022 at 7:04 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> kinow pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-text.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 2450b5bf Bump checkstyle from 9.3 to 10.2
> 2450b5bf is described below
>
> commit 2450b5bfc0460e22e86e33e517f4944ade33573b
> Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
> AuthorDate: Fri May 20 20:03:05 2022 +
>
> Bump checkstyle from 9.3 to 10.2
>
> Bumps [checkstyle](https://github.com/checkstyle/checkstyle) from 9.3 to 
> 10.2.
> - [Release notes](https://github.com/checkstyle/checkstyle/releases)
> - 
> [Commits](https://github.com/checkstyle/checkstyle/compare/checkstyle-9.3...checkstyle-10.2)
>
> ---
> updated-dependencies:
> - dependency-name: com.puppycrawl.tools:checkstyle
>   dependency-type: direct:production
>   update-type: version-update:semver-major
> ...
>
> Signed-off-by: dependabot[bot] 
> ---
>  pom.xml | 2 +-
>  src/changes/changes.xml | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/pom.xml b/pom.xml
> index 24a06cef..ed92f57b 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -48,7 +48,7 @@
>  
> site-content
>
>  3.1.2
> -9.3
> +10.2
>
>  
> 4.6.0.0
>  4.7.0
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index eca43f0a..3d53e762 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -79,7 +79,7 @@ The  type attribute can be add,update,fix,remove.
>   due-to="Dependabot">Bump actions/checkout from v1 to 3 #138, #146, #165, 
> #183, #274, #279, #304.
>   due-to="Dependabot">Bump actions/cache from v2 to v2.1.6 #205 #217 
> #234.
>   due-to="Dependabot">Bump github/codeql-action from 1 to 2 #319.
> - due-to="Dependabot">Bump checkstyle from 8.34 to 9.3, #141, #168, #182, #188, 
> #193, #201, #208, #211, #228, #235, #245, #253, #255, #262, #270, #280, #287, 
> #299, #315, #321.
> + due-to="Dependabot">Bump checkstyle from 8.34 to 10.2, #141, #168, #182, 
> #188, #193, #201, #208, #211, #228, #235, #245, #253, #255, #262, #270, #280, 
> #287, #299, #315, #321, #327.
>  Bump spotbugs-maven-plugin from 4.0.0 to 4.6.0.0, #144, 
> #150, #167, #176, #194, #210, #223, #250, #268, #273, #277, #278, #286, #293, 
> #303, #320.
>   due-to="Dependabot">Bump mockito-inline from 3.4.4 to 4.5.1, #143, #148, 
> #149, #152, #153, #154, #158, #159, #166, #177, #180, #187, #195, #197, #207, 
> #216, #231, #236, #237, #243, #258, #259, #260, #261, #272, #285, #291, #305, 
> #317.
>   due-to="Dependabot">Bump junit-jupiter from 5.6.2 to 5.8.2 #163, #204, #232, 
> #265, #269, #288.
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: New component proposal: commons-plugins

[Eric Bresie]

It sounds like embedded in this discussion are some use cases / requirements. 
Would quantifying these some with a high level list of features that this 
plugin architecture is to provide?

What would the basic functionality and/or interfaces be…something like:
- Register Plugin/Services
- Plugin/Service Configuration
- Lookup Plugin/Service
- Invoke Plugin/Service
- Annotation for Plugin/Services
- Service/Adapter Interface for use with External module systems (i.e. doing 
generically in common-plugin to make calls to external module system)?

What kind of test cases would be applicable to buy into acceptance?

Would common-plugin be similar to maven where there is the basic core 
functionality with addition plugin’s providing new “goal”/functionality to 
provide additional compatibility (i.e. import plugin.osgi, import 
plugin.spring, etc.). and/or provide a wrapper/adapter between module systems? 
So assume the above would provide the core and the subsequent “adapter” layer 
or plugin for each could be implemented separately (either internal or external 
to the project).

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)
> On April 12, 2022 at 5:10:25 PM CDT, Thomas  (mailto:t...@online.de)> wrote:
>
> > > > Users should be required to do as little as possible to adapt the
> > > > plugin system to the environment it is running in*but plugins shouldn’t 
> > > > know or care anything about how they are located and loaded.* Plugins 
> > > > are also to the
> > > > application or framework that will be using them. They essentially 
> > > > define what
> > > > the valid plugin types are and where they can be used.
> > > This is impossible. The bare minimum, any system or artifact has to do, 
> > > to be recognized as a plugin, is advertising itself as one. That would be 
> > > true, even if your service locator is crawling through every class of the 
> > > classloader it can get hold of to determine, whether it is a candidate to 
> > > consider.
> > >
> > > - OSGI does this by parsing the MANIFEST and OSGI-INF
> > >
> > > - Spring uses a combination of XML and crawling annotations and packages
> > >
> > > Every other CDI framework does it similar to these two, most of them 
> > > heavily reliying on XML- or property based configuration too. With one 
> > > notable exception: the dreaded ServiceLoader mechanism, which fixes this 
> > > during compile time in the module-info, if you use JPMS, else mapping it 
> > > in META-INF/services with simple plain text files, that require no 
> > > parsing other then getting the line breaks right - no reflection / 
> > > premature loading required. (Which btw, I think is the slickest solution 
> > > so far, as it does make service discovery very cheap for small systems, 
> > > with few class path entries. Complication is inevitably the result of 
> > > large classpaths, that require plugin arbitration to resolve ambiguities 
> > > and filtering)
> > >
> > > So no: at the very least, a plugin has to know, by what plugin system it 
> > > is going to be loaded. And - a different hyperbole: because of this, 
> > > apache commons has started to introduce the attributes required by OSGi 
> > > into the MANIFESTs of many of its components, just to bridge the gap, and 
> > > to aleviate the need to for OSGi-Users to introduce wrappers.
> > >
> > > For me, this will be all well and fine, as long as none of the current or 
> > > future apache commons artefacts will become unusable unless I also put 
> > > commons-plugin or some arcane configuration parser into the class path.
> > I never said a plugin shouldn’t know it is a plugin. Providing the manifest 
> > entries required to make a component usable in an OSGi environment doesn’t 
> > mean the Plugin has to know it is being used in a an OSGi environment. 
> > Likewise, providing a module-info.java doesn’t mean the plugin will be used 
> > as part of a module on a module path. Using Log4j as an example once again, 
> > its Plugins know that they are a Filter, Appender, Lookup, Layout, or 
> > whatever. But they have no knowledge of how they were loaded. They DO know 
> > that they are being used by Log4j for a specific purpose and what contract 
> > they have to implement for that, but that is exactly what plugins are for.
> >
> > So I guess Log4j is doing the impossible?
> >
> ... only if your Log4J plugins would be automagically recognised as
> regular plugins by other frameworks, ranging from OSGi, to Spring, CDI,
> Jakarta, Plexus, Avalon, Netbeans, JMeter, ANT, Gradl

Re: [ALL] components still using Travis

[Eric Bresie]

Not sure if this is applicable here but is there a concern about limits of 
amount of usage on GItHub activities (and/or Travis) for a given organization 
across all of the Apache / Common projects/repositories?

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On March 29, 2022 at 6:21:53 AM CDT, sebb  (mailto:seb...@gmail.com)> wrote:
> It looks like there is a general move to switch from Travis to GitHub Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
> jobs: notificati...@commons.apache.org 
> (mailto:notificati...@commons.apache.org)
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> (mailto:dev-unsubscr...@commons.apache.org)
> For additional commands, e-mail: dev-h...@commons.apache.org 
> (mailto:dev-h...@commons.apache.org)
>

Re: Re: [geometry] PointMap and PointSet

[Eric Bresie]

>
> On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen 
> mailto:matt.a.juntu...@gmail.com)> wrote:
>
> > I'm a little bit confused: Isn't it always the case that
> getEntry(p).getKey()
> will return the originally inserted (i.e. "canonical") point (i.e. not "p")?
>
> Map does not contain a "getEntry" method. If it did, that would indeed
> be preferable.

Would Java’s Map.entrySet provide the “getEntry” type method needed?

https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet--

Or would this provide all entry’s and still need to find the specific entry so 
maybe a forEach variation to filter for a specific entry?
https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer-

> > Unless I'm missing a standard use-case, the specialized methods
> "closestFirst" and "farthestFirst" don't seem useful (and wasteful
> of computing resources: If iterating over the whole set, why would
> one want to start from some particular point?).

Eric Bresie
ebre...@gmail.com
>

Re: Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2

[Eric Bresie]

Would it be worth starting with a list of commit one liners then release 
manager (or whom even) edits for more readability?

Is a ticket to track resolution of the time issue needed if not already raised 
to ensure this does get resolved at some point in the future whether it be 
environment or build changes or documentation changes?

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On January 17, 2022 at 8:39:31 AM CST, Thomas Vandahl  (mailto:t...@apache.org)> wrote:
> Hi Gilles,
>
> > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski  > (mailto:gillese...@gmail.com)>:
> >
> > No; the remark is for making the reviewer's life easier, i.e just copy/paste
> > the command and see the build succeed. Without the environment variable,
> > the "javadoc" step fails IIRC.
>
> Ok, thanks for the hint. I didn’t know this.
>
> > It's not the procedure. I simply stress FTR that the release notes
> > become less and less what they should be, that is a summary for
> > human consumption that attracts the user's attention on functional
> > changes. [The full set of changes is always accessible through the
> > commits log.]
> > To ensure clarity for users, changes that cannot affect them should
> > not be listed in "changes.xml".
> Yes. For the sake of clarity for the user, I find the manual maintenance of 
> changes.xml much better than other measures like commit logs or JIRA-Ticket 
> reports.
> However, I’m a bit hesitant to change entries made by other committers. I 
> guess that would require consent between all committers of a project on how 
> to maintain the changes list.
>
> > > > There are a few changes marked incompatible. Is it expected in a minor 
> > > > release?
> > > The japicmp report recommends a 0.1.0 release which it is.
> >
> > I don't understand why, but OK then…
> Actually, it took several changes to be reverted just to get to this state.
>
> > > > > > [ ] +1 Release these artifacts
> > > > > > [ ] +0 OK, but...
> > > > > > [ ] -0 OK, but really should fix...
> > > > > > [ ] -1 I oppose this release because…
> > >
> > > Would you please consider voting?
> >
> > +1
> >
> > [There are no technical issues, only communication issues that are
> > common problems with all the releases.]
>
> Thanks, Gilles.
>
> Bye, Thomas
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> (mailto:dev-unsubscr...@commons.apache.org)
> For additional commands, e-mail: dev-h...@commons.apache.org 
> (mailto:dev-h...@commons.apache.org)
>

Re: Re: can we get rid of dependabot?

[Eric Bresie]

Noticed on recent dependabot PR the below being added to the PR.

Would using any of these options (i.e. like @dependabot close which prevent
some of the repeats notifications) help?

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

   - @dependabot rebase will rebase this PR
   - @dependabot recreate will recreate this PR, overwriting any edits that
   have been made to it
   - @dependabot merge will merge this PR after your CI passes on it
   - @dependabot squash and merge will squash and merge this PR after your
   CI passes on it
   - @dependabot cancel merge will cancel a previously requested merge and
   block automerging
   - @dependabot reopen will reopen this PR if it is closed
   - *@dependabot close will close this PR and stop Dependabot recreating
   it. You can achieve the same result by closing it manually*
   - @dependabot ignore this major version will close this PR and stop
   Dependabot creating any more for this major version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this minor version will close this PR and stop
   Dependabot creating any more for this minor version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this dependency will close this PR and stop
   Dependabot creating any more for this dependency (unless you reopen the PR
   or upgrade to it yourself)


On Sun, Jan 2, 2022 at 9:36 AM Eric Bresie  wrote:

> Late to the discussion but I think what is being said and with a few
> follow up questions is…
>
> The problem discussed is when a dependabot check occurs following a
> commit, it highlights out of date dependencies (possibly security related)
> which notifies folks via an automated email sent to multiple mailing list
> with the frequency of such resulting in giving mailing list overwhelmed by
> the frequent checks for dependencies updates.  Is this correct?
>
> It sounds like what is being proposed (and in work) is for the dependabot
> configuration to change the frequency, trigger, and/or destination for the
> emails…is this correct?
>
> From dependency perspective, is the behavior, it notifies for the need for
> an update or does it create an automated updated via a generates “PR” to
> address direct and indirect dependency updates?  Assume for PR case a
> “person in the loop” is still required to review and merge in the PR…right?
>
> From a higher level, is it correct to say, this attempts to reduce the
> risk of security or out of date dependency issues by automating the version
> dependencies checks/updates in a given build and reduce the amount of time
> and manual involvement to reduce security (and other dependency) updates?
>
> I hope this would be considered sooner in the pipeline and maybe for
> another thread, but…if someone has an upstream dependency of some type, and
> a “bad actors” corrupts and updates a given upstream dependency, would this
> potentially “automate the spread” of a “bad actors” dependency update?
> Assume the “person in the loop” would hopefully reduce the risk but just
> thinking worse case scenario here.
>
>
> Eric Bresie
> ebre...@gmail.com
>
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins 
> wrote:
> I believe that we already have begun to do this. -Rob
>
> On Dec 30, 2021, at 6:16 PM, sebb  wrote:
>
> Those of you who want to keep the robot, please use the instructions
> to reduce the spam.
>
> On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
>
>
> There are tons of options to configure. The defaults are handy for
> smaller projects, but they are clearly spammy for larger ones like this.
>
>
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> <
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
>
>
>
> +1
>
> --
> Matt Sicker
>
> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:37 PM, sebb  mailto:seb...@gmail.com >> wrote:
>
>
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  mailto:chtom...@gmail.com >> wrote:
>
>
> Guys. The fundamental argument underpinng all this is whether it’s better
> to have robot eyes on the code and human eyes on the code. Stop arguing one
> side or the other. We need to find a way to do both successfully.
>
>
> The issue is *not* about robot or no robot.
>
> It is about this particular robot that causes so much noise.
>
>
> Yes! That’s right so we need to figure out how to use the robot correctly!
>
>
>

Re: Re: can we get rid of dependabot?

[Eric Bresie]

Late to the discussion but I think what is being said and with a few follow up 
questions is…

The problem discussed is when a dependabot check occurs following a commit, it 
highlights out of date dependencies (possibly security related) which notifies 
folks via an automated email sent to multiple mailing list with the frequency 
of such resulting in giving mailing list overwhelmed by the frequent checks for 
dependencies updates. Is this correct?

It sounds like what is being proposed (and in work) is for the dependabot 
configuration to change the frequency, trigger, and/or destination for the 
emails…is this correct?

From dependency perspective, is the behavior, it notifies for the need for an 
update or does it create an automated updated via a generates “PR” to address 
direct and indirect dependency updates? Assume for PR case a “person in the 
loop” is still required to review and merge in the PR…right?

From a higher level, is it correct to say, this attempts to reduce the risk of 
security or out of date dependency issues by automating the version 
dependencies checks/updates in a given build and reduce the amount of time and 
manual involvement to reduce security (and other dependency) updates?

I hope this would be considered sooner in the pipeline and maybe for another 
thread, but…if someone has an upstream dependency of some type, and a “bad 
actors” corrupts and updates a given upstream dependency, would this 
potentially “automate the spread” of a “bad actors” dependency update? Assume 
the “person in the loop” would hopefully reduce the risk but just thinking 
worse case scenario here.

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins  (mailto:chtom...@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb  > (mailto:seb...@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  > > (mailto:chtom...@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker  > > > > (mailto:boa...@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for 
> > > > smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> > > >  
> > > > <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb  > > > > > > (mailto:seb...@gmail.com) <mailto:seb...@gmail.com>> wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com) <mailto:chtom...@gmail.com>> wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether 
> > > > > > > it’s better to have robot eyes on the code and human eyes on the 
> > > > > > > code. Stop arguing one side or the other. We need to find a way 
> > > > > > > to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot 
> > > > > correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz 
> > > > > > > > > mailto:phil.ste...@gmail.com) 
> > > > > > > > > <mailto:phil.ste...@gmail.com>> wrote:
> > > > > > > >
> > > > > > > > 
> > > > > > &

Re: [Compress] Pack200Exceptions on Old packed files

[Eric Bresie]

Where in the current implementation might one look for these sorts of
things?

In the quoted code seems to focus on the SegmentHeader related details
would something around this be needed?
I see some of the major/minor may be based on read code and relate to the
Codec in use.

While looking for SegmentHeader code read code which keys on different
possible codec.  For newer iterations has the codec changed would some new
codec need to be added?  Since this was an older package I wouldn’t have
thought so.

I find the following which maybe would be helpful but not sure yet.
https://docs.oracle.com/javase/7/docs/technotes/guides/pack200/pack-spec.html


Eric Bresie
ebre...@gmail.com


On Sun, Oct 31, 2021 at 4:44 PM Gary Gregory  wrote:

> Some sample pack200 files should also be part of tests.
>
> Gary
>
> On Thu, Oct 28, 2021, 10:16 Gary Gregory  wrote:
>
> > You'll have to figure out the implementation details but I will be happy
> > to review PRs on GitHub.
> >
> > Gary
> >
> > On Thu, Oct 28, 2021, 08:32 Eric Bresie  wrote:
> >
> >> In this particular case, there were packed modules which had major /
> minor
> >> versions not equal to the Major version 7 or minor version 150 supported
> >> in
> >> the code.
> >>
> >> This results in the exception, preventing it from unpacking.  The need
> is
> >> to be able to unpack an older packed file.
> >>
> >> As I understand it, some of this has to do with each version may handle
> >> things a bit differently which may result in limited compatibility.  Not
> >> sure if it’s keys on byte code level details or compression algorithms
> in
> >> use or what.
> >>
> >> How would the code need to be modified to support this?
> >>
> >> Eric
> >>
> >> On Tue, Oct 26, 2021 at 1:12 PM Gary Gregory 
> >> wrote:
> >>
> >> > There is not. The intent of the current code is simply to provide
> >> > functionality that was dropped from the JRE.
> >> >
> >> > What newer versions and how are they different?
> >> >
> >> > Gary
> >> >
> >> >
> >> > On Tue, Oct 26, 2021, 13:49 Eric Bresie  wrote:
> >> >
> >> > > While trying to unpack an older generated pack file, it was noted
> that
> >> > > Pack200Exceptions were getting raised due to the Major/Minor Version
> >> in
> >> > > used which seems to be I this area.
> >> > >
> >> > >
> >> > >
> >> >
> >>
> https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/harmony/unpack200/SegmentHeader.java#L131-L155
> >> > >
> >> > > Is there an work to support newer versions?
> >> > >
> >> > > Eric Bresie
> >> > > ebre...@gmail.com
> >> >
> >> --
> >> Eric Bresie
> >> ebre...@gmail.com
> >>
> >
>
-- 
Eric Bresie
ebre...@gmail.com

Re: [Compress] Pack200Exceptions on Old packed files

[Eric Bresie]

In this particular case, there were packed modules which had major / minor
versions not equal to the Major version 7 or minor version 150 supported in
the code.

This results in the exception, preventing it from unpacking.  The need is
to be able to unpack an older packed file.

As I understand it, some of this has to do with each version may handle
things a bit differently which may result in limited compatibility.  Not
sure if it’s keys on byte code level details or compression algorithms in
use or what.

How would the code need to be modified to support this?

Eric

On Tue, Oct 26, 2021 at 1:12 PM Gary Gregory  wrote:

> There is not. The intent of the current code is simply to provide
> functionality that was dropped from the JRE.
>
> What newer versions and how are they different?
>
> Gary
>
>
> On Tue, Oct 26, 2021, 13:49 Eric Bresie  wrote:
>
> > While trying to unpack an older generated pack file, it was noted that
> > Pack200Exceptions were getting raised due to the Major/Minor Version in
> > used which seems to be I this area.
> >
> >
> >
> https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/harmony/unpack200/SegmentHeader.java#L131-L155
> >
> > Is there an work to support newer versions?
> >
> > Eric Bresie
> > ebre...@gmail.com
>
-- 
Eric Bresie
ebre...@gmail.com

[Compress] Pack200Exceptions on Old packed files

[Eric Bresie]

While trying to unpack an older generated pack file, it was noted that 
Pack200Exceptions were getting raised due to the Major/Minor Version in used 
which seems to be I this area.

https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/harmony/unpack200/SegmentHeader.java#L131-L155

Is there an work to support newer versions?

Eric Bresie
ebre...@gmail.com