Opened 7 months ago

Closed 7 months ago

#68449 closed defect (fixed)

java portgroup: option java.enforce: determine whether still needed; if so, refine comments

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: chrstphrchvz (Christopher Chavez), catap (Kirill A. Korinsky)
Port: java

Description

Comments at the top of the java portgroup read:

# Sometimes a port hard code inside produces scripts and other files used JVM,
# then its true use java.enforce to enforce dependency.

I can't understand what that's trying to say; it needs to be reworded.

Change History (9)

comment:1 Changed 7 months ago by chrstphrchvz (Christopher Chavez)

This was https://github.com/macports/macports-ports/pull/20051

My guess is that the comment meant to say that if a port’s build outputs have hardcoded filepaths from the java.fallback port, then set java.enforce for the port to always depend on java.fallback, regardless of whether Java already present on the system.

If I understand the intention of this option correctly, then I do not see how it is desirable, and I am in favor of removing it. I agree with Nils Breun that such hardcoding in build outputs should be avoided.

And as currently implemented, java.enforce does not actually force the port to build using java.fallback, because it does not force JAVA_HOME to point to java.fallback rather than some other Java installation.

java.enforce is not used by any ports; it was only ever used in abcl, but not since an alternative was found: https://github.com/macports/macports-ports/pull/20089/files#diff-0869457f20b83a77c7320b01a92bbc4d7c15feb5489b8bd32880305e94bab285R53

comment:2 Changed 7 months ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:3 Changed 7 months ago by chrstphrchvz (Christopher Chavez)

comment:4 Changed 7 months ago by mascguy (Christopher Nielsen)

Cc: mascguy catap added

As mentioned in the PR, but to reiterate for all: We should not simply remove/undo changes made by others, without keeping them in-the-loop.

That includes both on tickets, as well as PRs.

And ultimately we need to give folks an opportunity to elaborate on their original changes, before moving ahead.

comment:5 Changed 7 months ago by mascguy (Christopher Nielsen)

As for the grammatical issues, we also need to respect that not everyone is a native English speaker.

So we should try to be kind, and assist when necessary, with such things.

comment:6 in reply to:  5 Changed 7 months ago by mascguy (Christopher Nielsen)

Replying to mascguy:

As for the grammatical issues, we also need to respect that not everyone is a native English speaker.

So we should try to be kind, and assist when necessary, with such things.

Indeed, since I merged the original PR, I could have refined the wording of the comments. So that's on me.

comment:7 Changed 7 months ago by mascguy (Christopher Nielsen)

Summary: java portgroup: Unintelligible commentsjava portgroup: option java.enforce: determine whether still needed; if so, refine comments

comment:8 Changed 7 months ago by mascguy (Christopher Nielsen)

Cc: mascguy removed
Owner: set to mascguy
Status: newassigned

comment:9 Changed 7 months ago by chrstphrchvz (Christopher Chavez)

Resolution: fixed
Status: assignedclosed

In 92361107b3e617929681505a6a3442649387e0af/macports-ports (master):

java 1.0 portgroup: remove java.enforce option

Closes: #68449

Note: See TracTickets for help on using tickets.