chore: Add a curation for Maven:junit:junit-dep

[sschuberth]

No description provided.

[fviernau]

Can we split out setting VCS type and URL into a separate curation please, to do one thing at a time?

Strictly speaking also setting the revision would be nice to separate out, so that we can have a comment which explains it.

[sschuberth]

Can we split out setting VCS type and URL into a separate curation please, to do one thing at a time?

Hmm, I don't regard setting all source code origins for the same package at once as different things. In what scenario would it help to have the addition of the source artifact and the VCS location in separate commits?

Esp. as the commit messages tends to be very short or even empty for curations because the actual background is given in the comment, splitting this would be more work as the comment would need to be "artificially" amended from the first to the second commit.

Strictly speaking also setting the revision would be nice to separate out, so that we can have a comment which explains it.

You mean a comment that explains why a tag named "r4.11" belongs to version "4.11"? That seems like overkill to me.

Actually, adding the revision wouldn't even have been absolutely necessary in this case as ORT is guessing it correctly. But having a curation for a concrete version that does not point to a concrete revision (esp. if it's an easy to find out tag) seems a bit awkward to me. So, to mirror the explicit source artifact curation, I chose to also be explicit about the revision here, so ORT does not have to spend time to guess it.

[fviernau]

Hmm, I don't regard setting all source code origins for the same package at once as different things. In what scenario would it help to have the addition of the source artifact and the VCS location in separate commits?

1. It is possible to "import" the curations separately into your ORGs ORT config, in an automated way.
2. It increases the likelyhood that the comment refers to what the curation does.
3. It leads to simpler comments, easier to review
4. It does one thing at a time, like we do git commits, as mentioned, easier to cherry-pick (not in a git sense).

so ORT does not have to spend time to guess it.

I'm not convinced doing this kind of performance tweaks via curations. I believe the database should be
kept as simple as possible. In particular not consume review / maintainance time for things which are already automated.

Apart from that, I believe VCS type and URL by default should be set agnostic of the version, or at least not only for one specific version.

I believe in some "high compliance" scenario, there can be use cases in which one does not want to blindly trust ort-config database, but selectively import needed curations. This is IMO much simpler if curations do one thing at a time, and do not cross reference other package attributes in the comments. E.g.:

1. As an ORT user I want to import all VCS type / url curations form ort-config
2. As an ORT user I want to import all source artifact curations from ort-config

Would you agree it's worth supporting such use cases?

[sschuberth]

1. It is possible to "import" the curations separately into your ORGs ORT config, in an automated way.

I don't think so... if you just "cherry-pick" those commits that add the lines you're interested in, you'll mostly likely run into diff hunk context conflicts.

For points 2. and 3. I can only state that I disagree, I don't believe that it makes a relevant difference in review complexity.

For point 4., I'm all in for commit atomicity, but splitting at that low level just feels artificial to me. Except maybe for rare cases where finding out the source code origins was very difficult for each, then I'd also split this in two with background information provided in the respective commit messages.

I'm not convinced doing this kind of performance tweaks via curations.

It's not an intended performance tweak. It's something that I would have done anyway, with the nice side-effect of eventually also speeding up things.

Would you agree it's worth supporting such use cases?

I agree with the "high compliance" scenario to be a valid one, but I would go completely differently for implementing it: I would not look at the Git history at all, but process the curations and import only those data fields I'm interested in / trust.

[fviernau]

It's not an intended performance tweak. It's something that I would have done anyway, with the nice side-effect of eventually also speeding up things.

Ok, but then it's better to also not use it as a main rationale to do something.

I agree with the "high compliance" scenario to be a valid one, but I would go completely differently for implementing it: I would not look at the Git history at all, but process the curations and import only those data fields I'm interested in / trust.

This must have been a mis-understanding. I never meant to flag an issue with git history / commits.
Only with making separate curations for separate things.

[fviernau]

Shall we also move this discussion to a call, ideally involving further people as this seems to need again more fundamental decisions ?

[fviernau]

but process the curations and import only those data fields I'm interested in / trust.

That's exactly what I have in mind. But when curations mix things, it is not possible anymore to also import the "comment". This is what I'm afteer.

[sschuberth]

Shall we also move this discussion to a call, ideally involving further people as this seems to need again more fundamental decisions ?

As there's no one else available than us currently, I don't think we can resolve this before Monday. Maybe we can also take this to the Kotlin Dev meeting then.

[sschuberth]

That's exactly what I have in mind. But when curations mix things, it is not possible anymore to also import the "comment". This is what I'm afteer.

That then more sounds like a data model change that would be required / sensible to do: Introduce a comment field per source origin, rather than only have a single top-level one.

[sschuberth]

After our discussion, I've dropped the version specific VCS and source artifact curations in favor of only a version-agnostic VCS curation.