Open HannesWell opened 2 years ago
There are already some data used when you add a pom dependency inside the target location have you tried that?
Be aware that "about.html" is an eclipse specific thing an not any standard (I think one would rather use Markdown today ...)
But this would require a permanent internet connection and IIRC some licenses require a 'physical' cop
Generally one could embedded the pom in METAINF/maven and many artifacts already do that.
By the way if you like to take a look you could start here where we generate the initial feature data:
and where we already derive some from the pom: https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.pde/src/org/eclipse/m2e/pde/MavenPomFeatureModel.java
Also take in mind that with multiple items in a location it might not be possible to generate a consistent set. Actually the licencing of features does not math to them from the pom(s)....
The motivation is to display the legal information of Maven dependencies that usually do not have an
about.html
in their bundle root.
By the way: I think it would be good when on all places where about.html
is used, it alternatively could also use the META-INF/maven
info as a fallback.
Be aware that "about.html" is an eclipse specific thing an not any standard (I think one would rather use Markdown today ...)
That's right. But its the file shown when I open in Help ->About ... -> Installation Details -> Plug-ins -> Legal Info:
Currently the information located in the pom.xml in a jars META-INF/maven
is not considered there, although this probably the most common/reliable source of license information for a ordinary artifact (not directly from the Eclipse cosmos) from a Maven repository as you have already mentioned. So that dialog could read the licenses
element and display any/the first/all licenses listed there respectively open a license element's URL.
The motivation is to display the legal information of Maven dependencies that usually do not have an
about.html
in their bundle root.By the way: I think it would be good when on all places where
about.html
is used, it alternatively could also use theMETA-INF/maven
info as a fallback.
Do you know of any other location besides the just mentioned one?
But this would require a permanent internet connection and IIRC some licenses require a 'physical' cop
Generally one could embedded the pom in METAINF/maven and many artifacts already do that.
That's right, many Maven artifacts contain there pom there, but the licenses element usually looks like the following and only contains an URL to the license, not the license it self:
<licenses>
<license>
<name>GNU Lesser General Public License Version 2.1, February 1999</name>
<url>http://jgrapht.sourceforge.net/LGPL.html</url>
<distribution>repo</distribution>
</license>
<license>
<name>Eclipse Public License (EPL) 2.0</name>
<url>http://www.eclipse.org/legal/epl-v20.html</url>
<distribution>repo</distribution>
</license>
</licenses>
And some licenses require a copy of the license so it would be good to include one automatically. But since the artifacts are as they are and I don't want to modify them (which would for example break signatures), the generated feature seemed to be a good place for me.
Also take in mind that with multiple items in a location it might not be possible to generate a consistent set. Actually the licencing of features does not math to them from the pom(s)....
That's right. Each artifact and the feature itself can be different (I just wonder under which license one would put a collection of individually licensed artifacts). I was thinking about the possibility to generate a text for the copy-right or license section (not sure which one is better) that looks like the following:
The feature contains the following plug-ins/artifacts:
- plugin.a
- plugin.b
provided under the following License 1:
<License 1 text>
- plugin.c
provided under the following License 2:
<License 2 text>
...
Alternatively the license files could be copied into the generated feature when it is build.
However I don't know yet how to deal with this the best way, I mainly opened this issue as a reminder (because I recently had to update a manually crafted license file) and to gather some early feedback. Furthermore I think this can also be interesting for the Eclipse Platform when Artifacts are consumed directly from Maven-Central. I can work on this, but it has quite low priority for me at the moment (probably changes in the future).
I don't think a feature.xml is something one could really "license", it is just that this information should give an impression about what license allies to the included content.
If the pom.xml
does not contain anything useful your are out of luck anyways, thats why I think we should only generate the info when initially creating the feature and then the user has to adjust this as they need.
Do you know of any other location besides the just mentioned one?
Common places I used for finding infos in a custom license dialog are:
only contains an URL to the license
As far as I know the html is displayed in an embedded browser component, that should be able display ordinary links as well.
When a M2E-PDE target feature is generated for Maven-dependencies it would be handy if there would be an option to fill the
Copyright
,License Agreement
and the description in theGeneral Information
sections with values derived from the included artifacts pom's (mainly the license section). They would then available in theEclipse IDE Installation Details
.General Information
could list all contained artifacts (and maybe the repository they are derived from).The motivation is to display the legal information of Maven dependencies that usually do not have an
about.html
in their bundle root. But since the information has to be available in the pom (at least when published on Maven-Central) it would be handy to use it too. Alternatively the corresponding dialog (probably in org.eclipse.ui or similiar) could be enhanced to read license information from a pom.xml. But this would require a permanent internet connection and IIRC some licenses require a 'physical' copy.This is a first idea, so there could be space for improvements. My main intention is to simplify the compliance of license requirements and avoid the need to manually maintain a license file.