[jira] [Comment Edited] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788190#comment-17788190
]
Peter Monks edited comment on MNG-6677 at 11/21/23 12:15 AM:
-
Apologies for Lazarus'ing this issue, but I just want to reinforce how
important it is that SPDX License Expressions are modeled somewhere in a future
version of the POM, regardless of what values may exist in
{{}} sub-elements. The existing model has two fundamental
issues that impact downstream tools that attempt to consume this information:
# the current sub-elements of {{}} aren't validated, and there's an
enormous variation in the quality of data in those sub-elements in the real
world (on Maven Central and other artifact repositories)
# in the presence of multiple {{}} elements, it's impossible for
downstream tooling to infer whether the conjunction between those licenses is a
logical {{AND}} or a logical {{OR}} or a mix of both
SPDX License Expressions elegantly solve both problems, while still providing
an "escape hatch" for licenses that are not listed by SPDX themselves; the
so-called {{{}LicenseRef{}}}, and (as of SPDX v3.0) {{AdditionRef}} constructs.
was (Author: pmonks):
Apologies for Lazarus'ing this issue, but I just want to reinforce how
important it is that SPDX License Expressions are modeled somewhere in a future
version of the POM, regardless of what values may exist in
{{}} sub-elements. The existing model has two fundamental
issues that impact downstream tools that attempt to consume this information:
# the current sub-elements of {{}} aren't validated, and there's an
enormous variation in the quality of data in those sub-elements in the real
world (on Maven Central and other artifact repositories)
# in the presence of multiple {{}} elements, it's impossible for
downstream tooling to infer whether the conjunction between those licenses is a
logical {{AND}} or a logical {{OR}}
SPDX License Expressions elegantly solve both problems, while still providing
an "escape hatch" for licenses that are not listed by SPDX themselves; the
so-called {{{}LicenseRef{}}}, and (as of SPDX v3.0) {{AdditionRef}} constructs.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788190#comment-17788190
]
Peter Monks edited comment on MNG-6677 at 11/21/23 12:08 AM:
-
Apologies for Lazarus'ing this issue, but I just want to reinforce how
important it is that SPDX License Expressions are modeled somewhere in a future
version of the POM, regardless of what values may exist in
{{}} sub-elements. The existing model has two fundamental
issues that impact downstream tools that attempt to consume this information:
# the current sub-elements of {{}} aren't validated, and there's an
enormous variation in the quality of data in those sub-elements in the real
world (on Maven Central and other artifact repositories)
# in the presence of multiple {{}} elements, it's impossible for
downstream tooling to infer whether the conjunction between those licenses is a
logical {{AND}} or a logical {{OR}}
SPDX License Expressions elegantly solve both problems, while still providing
an "escape hatch" for licenses that are not listed by SPDX themselves; the
so-called {{{}LicenseRef{}}}, and (as of SPDX v3.0) {{AdditionRef}} constructs.
was (Author: pmonks):
Apologies for Lazarus'ing this issue, but I just want to reinforce how
important it is that SPDX License Expressions are modeled somewhere in a future
version of the POM, regardless of what values may exist in
{{}} sub-elements. The existing model has two fundamental
issues that impact downstream tools that attempt to consume this information:
# the current sub-elements of {{}} aren't validated, and there's an
enormous variation in the quality of data in those sub-elements in the real
world (on Maven Central and other artifact repositories)
# in the presence of multiple {{}} elements, it's impossible for
downstream tooling to infer whether the conjunction between those licenses is a
logical {{AND}} or a logical {{OR}}
SPDX License Expressions elegantly solve both problems, while still providing
an "escape hatch" for licenses that are not listed by SPDX themselves; the
so-called {{{}LicenseRef{}}}, and (as of SPDX v3.0) {{{}AdditionRef{}}},
constructs.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788190#comment-17788190
]
Peter Monks commented on MNG-6677:
--
Apologies for Lazarus'ing this issue, but I just want to reinforce how
important it is that SPDX License Expressions are modeled somewhere in a future
version of the POM, regardless of what values may exist in
{{}} sub-elements. The existing model has two fundamental
issues that impact downstream tools that attempt to consume this information:
# the current sub-elements of {{}} aren't validated, and there's an
enormous variation in the quality of data in those sub-elements in the real
world (on Maven Central and other artifact repositories)
# in the presence of multiple {{}} elements, it's impossible for
downstream tooling to infer whether the conjunction between those licenses is a
logical {{AND}} or a logical {{OR}}
SPDX License Expressions elegantly solve both problems, while still providing
an "escape hatch" for licenses that are not listed by SPDX themselves; the
so-called {{{}LicenseRef{}}}, and (as of SPDX v3.0) {{{}AdditionRef{}}},
constructs.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] Commented: (MECLIPSE-310) mvn eclipse:eclipse fails to generate .classpath files for some poms
[
http://jira.codehaus.org/browse/MECLIPSE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174913#action_174913
]
Peter Monks commented on MECLIPSE-310:
--
This is still occurring with mvn 2.0.10, although in my case the module I'm
working on is being packaged as an AMP (Alfresco Module Package - see
http://wiki.alfresco.com/wiki/AMP_Files and
http://repository.sourcesense.com/maven2-sites/maven-amp-plugin/). I also
tried the workaround described above (force packaging=jar for the eclipse
plugin) but that didn't change the behaviour.
mvn eclipse:eclipse fails to generate .classpath files for some poms
Key: MECLIPSE-310
URL: http://jira.codehaus.org/browse/MECLIPSE-310
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Reporter: Brian DePradine
Some modules in the Apache Axis2 project do not generate .classpath files.
The common factor appears to be those modules that are packaged as MAR
(Module ARchive) files. These pom for these modules all contain the following:
packagingmar/packaging, an example pom is included below. If this line is
removed then the all eclipse artifacts are generated as expected.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdorg.apache.axis2/groupId
artifactIdaxis2-parent/artifactId
versionSNAPSHOT/version
relativePath../parent/pom.xml/relativePath
/parent
artifactIdaddressing/artifactId
packagingmar/packaging
nameApache Axis 2.0 - Addressing/name
descriptionWS-Addressing implementation/description
dependencies
dependency
groupIdorg.apache.axis2/groupId
artifactIdaxis2-kernel/artifactId
version${version}/version
/dependency
/dependencies
build
sourceDirectorysrc/sourceDirectory
testSourceDirectorytest/testSourceDirectory
resources
resource
directoryconf/directory
excludes
exclude**/*.properties/exclude
/excludes
filteringfalse/filtering
/resource
resource
directorysrc/directory
excludes
exclude**/*.java/exclude
/excludes
/resource
/resources
testResources
testResource
targetPath../test-resources/targetPath
directorytest-resources/directory
includes
include**/**/include
/includes
/testResource
/testResources
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
inheritedtrue/inherited
configuration
skipfalse/skip
excludes
exclude**/*Util.java/exclude
/excludes
/configuration
/plugin
plugin
groupIdorg.apache.axis2/groupId
artifactIdaxis2-mar-maven-plugin/artifactId
version${version}/version
extensionstrue/extensions
configuration
includeDependenciesfalse/includeDependencies
/configuration
/plugin
/plugins
/build
/project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2480) Support for different types of version ranges in dependencies
Support for different types of version ranges in dependencies - Key: MNG-2480 URL: http://jira.codehaus.org/browse/MNG-2480 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Environment: n/a Reporter: Peter Monks G'day, It would be ideal if Maven supported different types of dependency version ranges, to allow for more flexible dependency version resolution. For example, if I was the provider of an open source library I might like to be able to state that my code is dependent on some other library, and in the dependency version section be able to say that it's been tested with one or two specific versions (say [1.1,1.2]), but should theoretically work over a range of versions (say [1.1,2.0) ). In this example the two version ranges might be called the soft range and the hard range (or certified and uncertified or whatever - the idea is what's important, not the terminology). Currently many of the poms for open source libraries in the public Maven repositories specify precise version numbers which invariably causes version mismatches (which then tickles bug MNG-2123, but that's another story...). I suspect that one of the reasons that open source teams do this is because they've only tested their code against one version of each library they're dependent upon, so it's understandable that they don't want to put a wider range of version numbers in their poms. But this increases the changes of a version number mismatch which forces the ultimate consumer of the library (and its dependencies) to manually fiddle with poms until the various version number ranges overlap. If it were possible to specify hard vs soft version number ranges in the poms directly, then open source providers may have more incentive to be more permissive in their version number ranges, while still making it clear which versions of their dependencies they've actually tested against. Cheers, Peter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
