[jira] [Updated] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wouter Born updated MSHARED-1290:
-
Affects Version/s: maven-filtering-3.3.0
maven-filtering-3.2.0
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wouter Born updated MSHARED-1290:
-
Description:
I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
and found that {{PropertyUtils}} was logging many false positives about cycles
between properties.
The cycle detection (introduced for MSHARED-417) reports false positives when a
variable occurs multiple times in a property, example:
{code:java}
depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
version=1.2.3 {code}
While writing a unit test to fix this, I also found that there are also cycle
false positives whenever one of the property values is the same as a property
name, example:
{code:java}
test1=${test2}
test2=${test3}
test3=test2{code}
was:
I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
and found that {{PropertyUtils}} was logging many false positives about cycles
between properties.
The cycle detection (introduced for MSHARED-417) reports false positives when a
variable occurs multiple times in a property, example:
{code:java}
depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
version=1.2.3 {code}
While writing a unit test to fix this, I also found that there are also cycle
false positives whenever one of the property values is the same as a property
name, example:
{code:java}
test1=${test2}
test2=test1 {code}
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745665#comment-17745665
]
ASF GitHub Bot commented on MSHARED-1290:
-
wborn opened a new pull request, #78:
URL: https://github.com/apache/maven-filtering/pull/78
This fixes MSHARED-1290.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=test1 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-filtering] wborn opened a new pull request, #78: [MSHARED-1290] PropertyUtils cycle detection results in false positives
wborn opened a new pull request, #78: URL: https://github.com/apache/maven-filtering/pull/78 This fixes MSHARED-1290. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1290) PropertyUtils cycle detection results in false positives
Wouter Born created MSHARED-1290:
Summary: PropertyUtils cycle detection results in false positives
Key: MSHARED-1290
URL: https://issues.apache.org/jira/browse/MSHARED-1290
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-3.3.1
Reporter: Wouter Born
I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
and found that {{PropertyUtils}} was logging many false positives about cycles
between properties.
The cycle detection (introduced for MSHARED-417) reports false positives when a
variable occurs multiple times in a property, example:
{code:java}
depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
version=1.2.3 {code}
While writing a unit test to fix this, I also found that there are also cycle
false positives whenever one of the property values is the same as a property
name, example:
{code:java}
test1=${test2}
test2=test1 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINDEXER-195) New Search API backend: remoterepository
[ https://issues.apache.org/jira/browse/MINDEXER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745654#comment-17745654 ] ASF GitHub Bot commented on MINDEXER-195: - cstamas opened a new pull request, #323: URL: https://github.com/apache/maven-indexer/pull/323 Adds new RR limited backend, usable for existence checks. This backend is NOT a proper indexer backend, but instead it uses remote repository and maven metadata to answer some "basic" questions. On positive side, it does not rely on any 3rd party service, hence, has no delay: what is returned by it is available to maven as well. More in README --- https://issues.apache.org/jira/browse/MINDEXER-195 > New Search API backend: remoterepository > > > Key: MINDEXER-195 > URL: https://issues.apache.org/jira/browse/MINDEXER-195 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.0.4 > > > A limited backend (not really a general query backend) that still can answer > some basic queries and works agains a remote repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745618#comment-17745618 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1645651621 Hi @slawekjaranowski @cstamas @olamy , Could you please review this PR when you have a chance? Thank you very much! > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] kun-lu20 commented on pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1645651621 Hi @slawekjaranowski @cstamas @olamy , Could you please review this PR when you have a chance? Thank you very much! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SCM-1011) Do not set --non-interactive for SVN provider by default
[
https://issues.apache.org/jira/browse/SCM-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SCM-1011:
Assignee: Konrad Windszus
> Do not set --non-interactive for SVN provider by default
>
>
> Key: SCM-1011
> URL: https://issues.apache.org/jira/browse/SCM-1011
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-svn
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> For historical reasons the SVN commands were always called with option
> {{--non-interactive}}
> (https://github.com/apache/maven-scm/commit/f079a27b52dc243cd4731c1b68c8d714f9aa3829#diff-a51b4af351fd8bb911bf50a382255bdf1236a5b8d634ab09acb019247c917ae3R62).
> Although this became configurable with SCM-402 the default always stayed the
> same.
> Now that https://issues.apache.org/jira/browse/MSHARED-1072 is fixed, I would
> propose to leave out the flag by default in order to allow for interactive
> prompts if Maven is executed in interactive mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MRELEASE-1134) Pass interactive flag to ScmProvider
[ https://issues.apache.org/jira/browse/MRELEASE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved MRELEASE-1134. --- Fix Version/s: next-release Resolution: Fixed Fixed in https://github.com/apache/maven-release/commit/45327f7b47011e848fae0ea6844284b4ea9366b4 > Pass interactive flag to ScmProvider > > > Key: MRELEASE-1134 > URL: https://issues.apache.org/jira/browse/MRELEASE-1134 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: next-release > > > Currently the interactive flag from the ReleaseDescriptor is not passed on to > SCM, therefore it only has an impact on invocations triggered from the > release manager directly but not on invocations triggered through SCM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1134) Pass interactive flag to ScmProvider
[ https://issues.apache.org/jira/browse/MRELEASE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745510#comment-17745510 ] ASF GitHub Bot commented on MRELEASE-1134: -- kwin merged PR #197: URL: https://github.com/apache/maven-release/pull/197 > Pass interactive flag to ScmProvider > > > Key: MRELEASE-1134 > URL: https://issues.apache.org/jira/browse/MRELEASE-1134 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the interactive flag from the ReleaseDescriptor is not passed on to > SCM, therefore it only has an impact on invocations triggered from the > release manager directly but not on invocations triggered through SCM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-release] kwin merged pull request #197: [MRELEASE-1134] Pass interactive flag to SCM provider
kwin merged PR #197: URL: https://github.com/apache/maven-release/pull/197 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-1289) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSHARED-1289: - Fix Version/s: (was: maven-shared-utils-next-release) > Deprecate maven-shared-utils > > > Key: MSHARED-1289 > URL: https://issues.apache.org/jira/browse/MSHARED-1289 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > As discussed in > https://lists.apache.org/thread/9wkmo1cfq7hx6qwo2xp070rkdz1w5myp this library > never became successor of plexus-utils and therefore is less maintained. > Instead of maintaining two libraries we should deprecated Maven Shared Utils > and recommend using plain JDK API where possible or fall back to either > plexus-utils or other well known third party libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7706) Deprecate ${localRepository} mojo parameter expression
[
https://issues.apache.org/jira/browse/MNG-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-7706:
---
Description:
The mojo parameter expression 'localRepository' injects type
[{{ArtifactRepository}}|https://maven.apache.org/ref/current/maven-artifact/apidocs/org/apache/maven/artifact/repository/ArtifactRepository.html]
that is part of the suite coming from Maven2 (predates Mercury, that was
superseded by Aether, today Maven Resolver).
The problem with this interface is that it is not compatible (nor is possible
to adapt it) to Maven Resolver
[LocalRepositoryManager|https://maven.apache.org/resolver/maven-resolver-api/apidocs/org/eclipse/aether/repository/LocalRepositoryManager.html]
(LRM) due lack of context. Also, the use of this interface in Mojos causes
issues like MNG-7663, as they fully (and blindly) re-implement Maven local
repository with *wired in* layout.
Moreover, Mojos using this expression are usually dragging other (legacy)
deprecated things as well, most typically maven-artifact-transfer, or
maven-dependency-tree and so on, all things that predates Maven 3.1 (are done
to "protect" from Aether package change happened between Maven 3.0 and Maven
3.1). Today baseline for plugins is 3.2.5, so none of these "indirection" are
needed anymore. In fact, the use of this expression is very good sign of legacy
and technical debt present in given plugin. And also, these plugins cripple
Maven to adopt new features. This warning is a clear indicator for legacy or
neglected plugins.
The type {{ArtifactRepository}} is used in Maven internally (most in
maven-compat, a bit less in maven-core), this is telling as well, but IMHO
there is no need to deprecate this interface, as:
* plugins who migrate from this ancient interface to Resolver will have much
simpler job with maven 4 API (as it is much closer to Resolver than old Maven
APIs)
* this tackles only Plugins, while Maven itself is fine, as post Maven 4 the
internals will be shut off, so warning Mojo authors is enough
* still, we should look into core where and why is this type used for
* deprecate localRepository used of {{ArtifactRepository}} type on following:
{{{}MavenExecutionRequest{}}}, {{MavenSession}} and {{ProjectBuildingRequest}}
as instance created for these are effectively not used (and are created "too
early" and they carry repository system session anyway
h3. If a Mojo gets this WARNING, how should it be fixed?
* presence of parameter {{{}$\{localRepository{ (with presence of type
ArtifactReposiory) usually means following things: Mojo uses maven-compat
Maven2 compatibility layer, OR uses some deprecated libraries (most prominent
example is maven-artifact-transfer). Both are technical debts, and remedy is to
switch code to use current APIs.
* second most often reason for parameter is access to the base directory of
local repository. In this case {{RepositorySystemSession}} should be injected
instead, use expression {{{}$\{repositorySystemSession{ and get the
LocalRepositoryManager (LRM) from it. Word of warning: in most cases you DO NOT
want the base directory of local repository, as since Maven 3.9.0 the layout of
it is not fixed. If you want to access contents of local repository, you *must
use LRM APIs instead* (this is actually true since Maven 3.0.x)!
If user is stuck with plugin that issues this warning, user still can use it,
but should avoid use of any advanced (split, etc) local repository features,
available since 3.9.0. Inevitably, the deprecated APIs (maven-compat, etc) will
get removed in the future, so if no way to update the Mojo, user should plan to
migrate to some alternative solution (to buy out the affected Mojo).
was:
The mojo parameter expression 'localRepository' injects type
{{ArtifactRepository}} that is part of the suite coming from Maven2 (predates
Mercury, that was superseded by Aether, today Maven Resolver).
The problem with this interface is that it is not compatible (nor is possible
to adapt it) to Maven Resolver LocalRepositoryManager due lack of context.
Also, the use of this interface in Mojos causes issues like MNG-7663, as they
fully (and blindly) re-implement Maven local repository with *wired in* layout.
Moreover, Mojos using this expression are usually dragging other (legacy)
deprecated things as well, most typically maven-artifact-transfer, or
maven-dependency-tree and so on, all things that predates Maven 3.1 (are done
to "protect" from Aether package change happened between Maven 3.0 and Maven
3.1). Today baseline for plugins is 3.2.5, so none of these "indirection" are
needed anymore. In fact, the use of this expression is very good sign of legacy
and technical debt present in given plugin. And also, these plugins cripple
Maven to adopt new features. This warning is a clear indicator for legacy or
neglected plugins.
The type {{Artifact
