Upgrading to 4.5.5

[GeorgeS2019]

I wonder if you are familiar with the latest IKVM which could make the upgrading simpler using ikvm.marven? https://github.com/sergey-tihon/Stanford.NLP.NET/issues/128

[yakivyusin]

Hello George,

I didn't follow the IKVM updates, thanks for the info. Will investigate this possibility.

[yakivyusin]

Hello @GeorgeS2019

I have published the prerelease version of update to 4.5.5 (using MavenReference): 4.5.5-pre.1. I will be glad if you try it.

[GeorgeS2019]

@yakivyusin

Please check these discussions to assure you have covered them.

https://github.com/ikvmnet/ikvm/issues/446

[yakivyusin]

@GeorgeS2019

@sergey-tihon faced the compiling issue for stanford-segmenter & net472. I'm not wrapping this library, only stanford-corenlp for .net 6.

[wasabii]

@yakivyusin There is no need to include the dll files in the package.

[yakivyusin]

Hello @wasabii

I know. This is done by my library design.

[wasabii]

@yakivyusin For what purpose? It is likely to break the end user's build down the line, as you are repackaging edu.stanford.nlp:stanford-corenlp assemblies, various shared Java libraries, IKVM assemblies, and .NET runtime assemblies, which will have been generated by you, instead of by the end user of your package. These are likely to lead to some fashion of conflict. Either yours will overwrite theirs. Or theirs will overwrite yours.

And it leaves you as the distributor of those binaries, and thus subject to their various licenses. Which may be fine if they all allow binary only distribution with no attribution. But they probably don't.

If it's due to some bug or deficiency in ikvm-maven I'd like to know so I can address it.

[wasabii]

For example, a number of these binaries are licensed under the Apache v2 license.

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work

You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

The binaries you are distributing (produced by IKVM from the original JARs) are "Derivative Works", as they are in Object form, and ultimately based on the Work (the original Java source).

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

Since it is now you distributing these Derivative Works, it would be on you to distribute any NOTICE files along with them.

[wasabii]

Another example: jmock.dll is distributed. Which is ultimately derived from jmock.jar. Which is binary form produced by the jMock project, under the jMock Project License, which states:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Since you are the one now doing the redistribution, you must now include the above copyright notice in your documentation.

[yakivyusin]

@wasabii Thanks for your analysis, I'll definitely take it into account. The current prerelease version was just the quick proof-of-concept of using ikvm.maven.

What I need to achieve: Maven dlls should be compiled and copied to output directory of a consumer project, but they should not be referenced (so, no Java namespaces should be available). Could it be achieved with the current ikvm.maven functionality?

[wasabii]

I do not believe that is a feature of Maven at all, no.

According to the Maven documentation at https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#:~:text=System%20Dependencies-,Transitive%20Dependencies,from%20the%20remote%20repositories%20specified:

(*) Note: it is intended that this should be runtime scope instead, so that all compile dependencies must be explicitly listed. However, if a library you depend on extends a class from another library, both must be available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive.

So, in the Maven world, compile dependencies are always added to the classpath of transitive references. So, A -> B -> C always results in C being available at compile time to A. The need for this makes a lot of sense: code in A might consume classes in B which make use of classes in C, and thus C needs to be available to the compiler at that time; and the build system can't know this on it's own.

This isn't actually different than the default in the NuGet world: PackageReferences are transitive. Though, PackageReferences can technically have aa PrivateAssets="compile". Maybe it's worth considering something like this on IKVM.Maven.Sdk. Though I'm not completely sure how important it is. It is quite normal for deps of deps of deps to appear in the available namespaces for .NET projects.

[wasabii]

See also here for a discussion on it: https://stackoverflow.com/questions/11044243/limiting-a-transitive-dependency-to-runtime-scope-in-maven

[GeorgeS2019]

@wasabii Upgrading to 4.5.6 is now possible using the excellent latest ikvm.maven