[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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-tabpanel&focusedCommentId=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:
> mar, an example pom is included below. If this line is
> removed then the all eclipse artifacts are generated as expected.
> 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";>
> 4.0.0
>
> org.apache.axis2
> axis2-parent
> SNAPSHOT
> ../parent/pom.xml
>
> addressing
> mar
> Apache Axis 2.0 - Addressing
> WS-Addressing implementation
>
>
> org.apache.axis2
> axis2-kernel
> ${version}
>
>
>
> src
> test
>
>
> conf
>
> **/*.properties
>
> false
>
>
> src
>
> **/*.java
>
>
>
>
>
> ../test-resources
> test-resources
>
> **/**
>
>
>
>
>
> maven-surefire-plugin
> true
>
> false
>
> **/*Util.java
>
>
>
>
> org.apache.axis2
> axis2-mar-maven-plugin
> ${version}
> true
>
>
> false
>
>
>
>
>
--
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
[jira] Commented: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_67676 ] Peter Monks commented on CONTINUUM-725: --- FWIW I'm seeing *exactly* the same behaviour here (with continuum 1.0.3). > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 release? -- 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
