Bug 240448 - www/jmeter: Update to 5.1.1
Summary: www/jmeter: Update to 5.1.1
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Mikhail Teterin
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2019-09-09 15:52 UTC by Jens Grassel
Modified: 2023-06-20 17:42 UTC (History)
4 users (show)

See Also:
mi: maintainer-feedback-


Attachments
Update www/jmeter to 5.1.1 (24.47 KB, patch)
2019-09-09 15:52 UTC, Jens Grassel
koobs: maintainer-approval-
Details | Diff
Update www/jmeter to 5.4.1 (22.01 KB, patch)
2021-12-04 15:51 UTC, Chris Moerz
no flags Details | Diff
poudriere Log for FreeBSD 13.0, jmeter 5.4.1 (44.67 KB, text/plain)
2021-12-04 15:52 UTC, Chris Moerz
no flags Details
Update www/jmeter to 5.4.2 (22.38 KB, patch)
2021-12-25 20:04 UTC, Chris Moerz
freebsd: maintainer-approval?
Details | Diff
Poudriere Log for jmeter 5.4.2 (20.28 KB, text/plain)
2021-12-25 20:05 UTC, Chris Moerz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Grassel 2019-09-09 15:52:15 UTC
Created attachment 207328 [details]
Update www/jmeter to 5.1.1

Hi,

I've attached a patch to update www/jmeter from 2.11 to 5.1.1.

Kind regards,

Jens
Comment 1 Mikhail Teterin freebsd_committer freebsd_triage 2019-09-09 23:57:50 UTC
The change would switch the port back to using the bundled JARs -- a major no-no and a deal-breaker:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/bundled-libs.html

Thank you for the heads-up on the upstream version-bump, but this patch is no acceptable. If you care, please, rework it to avoid installing JARs already provided by other ports.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-10 01:53:58 UTC
^Triage: Maintainer (apparently?) provided feedback, which is maintainer-feedback +

Approval of patches (or non acceptance) is with maintainer-approval flag on attachments
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-10 01:54:52 UTC
@Mikhail Could you update your port MAINTAINER lines to match your bugzilla account email please, that way any issues created for ports you maintain can be automatically assigned to you. Thanks!
Comment 4 Mikhail Teterin freebsd_committer freebsd_triage 2019-09-10 02:23:39 UTC
(In reply to Kubilay Kocak from comment #3)
> provided feedback, which is maintainer-feedback +

Absolutely not - the feedback is negative, Kubilay - it was _you_, how set it to positive for some reason.

I do not know, how my initial response could be so misinterpreted, I explicitly wrote in comment #2:

> this patch is no[t] acceptable

> @Mikhail Could you update your port MAINTAINER lines to match your bugzilla account email please

For historical reasons, I have _two_ accounts - one of them matching the non-FreeBSD account I use - also for historical reasons - for ports.

So far I've had no problems with PRs against my ports being assigned to me - was this one an exception?
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-10 02:28:43 UTC
(In reply to Mikhail Teterin from comment #4)

The maintainer-*approval* flag on the patch was set to - to indicate non-acceptance.

maintainer-*feedback* was provided (ie: +), - is only used to indicate maintainer timeouts, which is not the case here.

On having maintainer lines match FreeBSD bugzilla account email addresses, it enabled auto-assignment of issues, and reduces the work triagers have to do (and noise on the mailing list when issues aren't assigned). We'd appreciate it if the emails matched, as we ask of everyone else

Thanks Mikhail
Comment 6 Jens Grassel 2019-09-10 16:26:06 UTC
Hi,

currently I'm pretty low on time but I will try to change the patch according to your requirements.

Should we leave the issue open or is it better to close it and let me open a new one once the patch is ready?

Regards,

Jens
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-16 11:46:57 UTC
^Triage: Assign to (real, committer) maintainer, pending updating of MAINTAINER lines to match

(In reply to Jens Grassel from comment #6)

Leaving the issue open is fine in this case
Comment 8 Chris Moerz 2021-12-04 15:51:48 UTC
Created attachment 229896 [details]
Update www/jmeter to 5.4.1

I created a revised patch that attempts to reference to any jars that can be found in other packages. This bumps version to 5.4.1, however. Not sure, how to change the bug title to reflect that.

There's one particular exception - log4j in ports unfortunately does not work; if we reference that instead of the jars in the distribution file, jmeter GUI won't start at all and just bails with an exception. There appear to be multiple classes missing because log4j ports is outdated, from what I can gather from the output.

In case I was supposed to create a new ticket, please let me know.

I'll be posting a poudriere log in a moment as well.
Comment 9 Chris Moerz 2021-12-04 15:52:59 UTC
Created attachment 229897 [details]
poudriere Log for FreeBSD 13.0, jmeter 5.4.1

As previously stated - here's the poudriere run for the jmeter patch.
Comment 10 Chris Moerz 2021-12-12 17:37:08 UTC
Unfortunately, further testing on 12.3 somehow shows that this patch and the resulting package do not work; slf4j dependency does not work -> please do not commit this.

It'll need further investigating why this is broken.
Comment 11 Jens Grassel 2021-12-13 07:50:58 UTC
Hi,

sorry for the long delay. I've given this some thought and in my opinion removing bundled jar files to get them from other packages is not a way to handle java dependencies. It will drive us directly into java ecosystem dependency hell. After all there is a reason why most (all?) java deployments bundle their own jars and create their own classpath. It is quite likely that a jar from a bundled package will be incompatible because some project versions move faster than others.
Furthermore disk space is not an issue nowadays except in some scenarios. We're talking about having quite a lot of extra work for saving a couple of MB disk space.

Kind regards,

Jens
Comment 12 Chris Moerz 2021-12-25 20:04:02 UTC
Created attachment 230402 [details]
Update www/jmeter to 5.4.2

Well, lucky me for waiting a couple more days. I saved myself another update due to the log4j fiasko...

I finally wrapped everything up combined with the bundled jars and ran poudriere to confirm the build is working. Portlint and portclippy linting included.

I'm very hopeful we'll get this wrapped; complexity has gone done considerably thanks to the bundled jars now. I certainly agree on the dependency hell - it's probably wiser in regards to app stability to bundle it.

Please let me know if you have any suggestions for further improvements.
Happy holidays and happy new year.
Comment 13 Chris Moerz 2021-12-25 20:05:04 UTC
Created attachment 230403 [details]
Poudriere Log for jmeter 5.4.2

Additional poudriere log for updated patch to jmeter 5.4.2
Comment 14 Ivan 2023-06-05 11:14:27 UTC
Bundling JARs and fat JARs is a correct behavior in Java ecosystem. Are we allowed to create a new port with recent jmeter version, if maintainer disagree with this for some reason? Current jmeter version is extremely old.
Comment 15 Jens Grassel 2023-06-20 11:36:47 UTC
(In reply to Ivan from comment #14)

I would also like to see it this way, because decoupling bundled libraries into other packages leads us straigt into dependency hell. Opens up some security concerns though. But it seems otherwise we're stalled.
Comment 16 Chris Moerz 2023-06-20 16:27:14 UTC
Unless the maintainer chimes in, this is probably qualifying as a maintainer timeout?

Jmeter has progressed to version 5.5 in the meantime. I suppose we could create another patch but this might inevitably reset the clock on the maintainer timeout?
Comment 17 Mikhail T. 2023-06-20 16:54:20 UTC
(In reply to Ivan from comment #14)
> Bundling JARs and fat JARs is a correct behavior in Java ecosystem.

It is a _common_ behavior, yes. But it is not the correct one. For decades BSD's been subtly proud of building everything from scratch. Why break that tradition for a particular programming language and its "ecosystem"?

Like most BSD traditions, this injunction against bundled code is also a _good idea_. And the bundling of 3rd-party binaries is even worse, than bundling source!

With so many developers expressing themselves on this ticket, is there no one to figure out, how to build the application properly?
Comment 18 Ivan 2023-06-20 17:01:53 UTC
> With so many developers expressing themselves on this ticket, is there no one to figure out, how to build the application properly?

Only fork and produce fat jar. Application has 100+ libraries and only fraction of them is available in the ports, not mentioning regressions introduced by version mismatches.
Comment 19 Chris Moerz 2023-06-20 17:05:48 UTC
> With so many developers expressing themselves on this ticket, is there no one to figure out, how to build the application properly?

Honestly, that's what I attempted; I referenced all the JARs that could be found  in other packages. Unfortunately, there are a large number of JARs, that are not to be found anywhere.

Following the logic of the current JAR argument to the end would mean, one should then create a package for each single JAR? The amount of overhead to keep that 
1. up to date
2. in working order with jmeter due to version incompatibilities

is probably enough to stop any porter dead in his tracks. At least it does it for me. I don't plan to create, say 50 JAR ports, that noone needs but jmeter as a dependency. What qualifies as important enough to be put in their own package, what is ok to bundle? What if one JAR that is only required by jmeter now because a requirement for another port - who refactors that JAR and takes responsibility for the additional port?

Just to reiterate: I do get your point and I do want to support it. It feels, Java simply does not make it easy to stick to the governing policy here, I'm afraid. It's a shame that this causes a way outdated port because of it.

I'm wondering if anyone is going to touch this anytime soon unless there's a clear and agreed path forward to build it that doesn't end in limbo due to discussions of principles.

Hence, the discussion, I suppose. I'm still hoping for an agreement for a porting method that is applicable in real life and not a one-shot Phd thesis, that'll need to be redone and tested in full every 2 months. Apology for the poor analogy...
Comment 20 Mikhail T. 2023-06-20 17:18:17 UTC
(In reply to Ivan from comment #18)
> Application has 100+ libraries and only fraction of them is available
> in the ports

The existing policy has an exemption for 3rd-party stuff unavailable through the ports-system yet, so availability is not an issue.

For the things, that are available through a port of their own, there is no good reason not to use it.

> not mentioning regressions introduced by version mismatches.

That's FUD, quite frankly. When there is such a regression, we deal with it. Do you really believe, jmeter is the first or somehow unique in this regard?

(In reply to Ivan from comment #19)
> What qualifies as important enough to be put in their own package,
> what is ok to bundle?

Again, when there is no existing port of a dependency, it is Ok to use the bundled version -- the policy only asks you to _consider_ creating a separate port.

> It feels, Java simply does not make it easy to stick to the governing
> policy here

That it does not -- and Maven, in particular, makes it "too easy" for the Java-developers to make these hideous bundles, which benefit only the lazy sysadmins and the hardware manufacturers :(

> Just to reiterate: I do get your point and I do want to support it.

Thank you -- and I appreciate it. Can we compromise on the separate port-usage by limiting it to only the already existing ports (like apache-commons-*, xerces-j, junit, etc.)?
Comment 21 Chris Moerz 2023-06-20 17:42:29 UTC
> That's FUD

you're right; I did not express that train of thought properly. I was thinking of different ports being built with different versions and then running into conflicting API expectations - i.e. one ports wants v1, the other v2. Again - probably way too theoretical, maybe not occurring in the real world, maybe fixable with flavors. I admit having been gone from Java Programing in decades... last version I worked closely with was 1.5, not that I want to date myself.

> Can we compromise ...

Your clarification makes sense to me. I'll attempt another port patch following that next weekend. Then lets go from there, if it's successful.