[jira] [Commented] (MPOM-218) consider impact of maven-remote-resources-plugin in plugins not pluginManagement
[ https://issues.apache.org/jira/browse/MPOM-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900492#comment-16900492 ] Christopher Tubbs commented on MPOM-218: In Accumulo, we just just provide a basic "DEPENDENCIES" file. The plugin doesn't clobber the one that already exists: https://github.com/apache/accumulo/blob/rel/2.0.0/DEPENDENCIES > consider impact of maven-remote-resources-plugin in plugins not > pluginManagement > - > > Key: MPOM-218 > URL: https://issues.apache.org/jira/browse/MPOM-218 > Project: Maven POMs > Issue Type: Improvement >Reporter: Adrian Cole >Priority: Major > > While maven-remote-resources-plugin in plugins, it is difficult to work with > vs if it were in pluginManagement. For example, the parent pom can spit out a > distracting empty DEPENDENCIES file, which ends up by default in the source > distribution. > I've noticed multiple projects (ex dubbo, edgent) creating separate > distribution modules which on one hand works around this issue, but on the > other is a source of maintenance. > I'd ask to consider using pluginManagement instead, or possibly having the > ability to not create a DEPENDENCIES file when there are none, which would > also solve the problem. Maybe there's also another way to strip this out with > an assembly, but I've failed to figure this out. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MJAVADOC-619) Maven Javadoc bottom claims copyright for future years
[
https://issues.apache.org/jira/browse/MJAVADOC-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900409#comment-16900409
]
Emmanuel Bourg commented on MJAVADOC-619:
-
The patch I implemented in Debian is about supporting [SOURCE_DATE_EPOCH
|https://reproducible-builds.org/docs/source-date-epoch/] in the Javadoc
plugin. The adoption of SOURCE_DATE_EPOCH is slowly growing across a wide
variety of tools, but as I understand there is still some resistance to support
it in the Maven ecosystem (mostly because the environment variable approach
looks a bit hackish, but that's really the lowest and only common denominator
of very different tool ecosystems).
Maybe a less controversial change would be to use the build date in the javadoc
plugin (from {{MavenSession.getStartTime()}}) instead of the current date. So
if at some point there is an agreed upon mechanism to override the build date
centrally (either by supporting SOURCE_DATE_EPOCH, using the date of pom.xml,
or a mix of both) then the javadoc plugin will benefit from it. And this would
allow Debian to drop its patch since the build date is already
[overridden|https://salsa.debian.org/java-team/maven/blob/master/debian/patches/reproducible-build-timestamp.patch].
There would be just one issue left to override the timezone to property format
the date.
> Maven Javadoc bottom claims copyright for future years
> --
>
> Key: MJAVADOC-619
> URL: https://issues.apache.org/jira/browse/MJAVADOC-619
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Bernhard M. Wiedemann
>Priority: Major
>
> Originally filed at https://issues.apache.org/jira/browse/MCOMPILER-380
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#bottom]
> includes {{{currentYear}}}
> [https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/timestamp/copyright]
> explains why this is bad (not only for reproducible builds)
>
> Debian worked already around this with
> [https://sources.debian.org/src/maven-javadoc-plugin/2.10.4-1/debian/patches/reproducible-footer.patch/]
> but I think, this warrants a more general patch.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6716:
Fix Version/s: (was: 3.6.x-candidate)
3.6.2
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.2, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> 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
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (MNG-6713) Fix ExclusionArtifactFilter to respect wildcard
[ https://issues.apache.org/jira/browse/MNG-6713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MNG-6713: --- Assignee: Robert Scholte > Fix ExclusionArtifactFilter to respect wildcard > --- > > Key: MNG-6713 > URL: https://issues.apache.org/jira/browse/MNG-6713 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Ray Tsang >Assignee: Robert Scholte >Priority: Major > Fix For: 3.6.2 > > Time Spent: 10m > Remaining Estimate: 0h > > In the process of trying to fix MENFORCER-195, we discovered that it also > required a change in Maven Core. The issue is that the > ExclusionArtifactFilter is not excluding using wildcard. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven] saturnism commented on a change in pull request #269: [MNG-6713] Fix ExclusionArtifactFilter to respect wildcard exclusions.
saturnism commented on a change in pull request #269: [MNG-6713] Fix
ExclusionArtifactFilter to respect wildcard exclusions.
URL: https://github.com/apache/maven/pull/269#discussion_r310764089
##
File path:
maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/ExclusionArtifactFilter.java
##
@@ -41,8 +41,20 @@ public boolean include( Artifact artifact )
{
for ( Exclusion exclusion : exclusions )
{
-if ( exclusion.getGroupId().equals( artifact.getGroupId() )
-&& exclusion.getArtifactId().equals(
artifact.getArtifactId() ) )
+if ( "*".equals( exclusion.getGroupId() ) && "*".equals(
exclusion.getArtifactId() ) )
Review comment:
moved it to a private constant. unless if there is a more suitable place for
a public global constant, I feel keeping it local is better.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518352145 @michael-o We have successfult buid [1] with this fix [2]. Can you have a look? Should I post a new Jira ticket? [1]: https://builds.apache.org/job/maven-box/job/maven/job/removed-java-tools-3/2/ [2]: https://github.com/apache/maven/commit/caee9f03a43364fa145642c490f67d44a94d6bd3 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MASSEMBLY-803) Add file name mapping option when extracting dependencies
[
https://issues.apache.org/jira/browse/MASSEMBLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900231#comment-16900231
]
Gordon Pettey commented on MASSEMBLY-803:
-
I'd like to see this implemented. JREs are also a use case.
When I am using assembly to include a JRE (8, so not possible to use jlink),
every vendor package I'm aware of offers a tar.gz or zip with a layout like
{{vendor-name-version-tags/bin/java}}. I'd like to strip off that first
directory and place the contents in {{jre/}}, rather than hard-code the
directory name of whatever vendor I selected for that project in any {{.sh}} or
{{.bat}} startup scripts (or hard-code that directory name in the pom and use
resource filtering, which is not much better).
> Add file name mapping option when extracting dependencies
> -
>
> Key: MASSEMBLY-803
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet, moduleSet
>Reporter: Plamen Totev
>Priority: Minor
>
> Hi,
> Currently when using {{dependencySets}} with {{unpack}} set to {{true}},
> there is no way to set the output file names mapping. As plexus-io supports
> file names mapping, I think it will be relatively easy to add such option.
> Consider the following scenario. You want to distribute tomcat as part of
> your product. You could add something like that;
> {code:xml}
>
>
>
> org.apache.tomcat:tomcat:8.0.33:zip
>
> true
>
>
> {code}
> So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
> folder.What if I want to distribute it under {{tomcat}}? There is no
> way(AFAIK) to just extract sub folder of the archive. Of course there is
> {{}} tag but the matched files will be still under
> {{apache-tomcat-8.0.33/...}}
> The use of {{FileMapper}} for example may strip the root folder (the
> {{RegExpFileMapper}} seems like a perfect candidate).
> What do you think about such feature?
> p.s. Not quite sure where is the proper place to discuss such improvements
> requests - here or in the mailing list. So excuse me if this is not the
> proper place.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Kiemes updated MNG-6727:
Description:
We would like to pass a [version
range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
the parent which should be possible since 3.5.0
At the same time, we would like to use [CI friendly
versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
itself.
Both on their own work well, but combined they don't.
{{}}
{{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/xsd/maven-4.0.0.xsd]";>}}
{{ 4.0.0}}
{{ }}
{{ org.springframework.boot}}
{{ spring-boot-starter-parent}}
{{ [2.1,3.0)}}
{{ }}
{{ com.example}}
{{ test}}
{{ ${revision}}}
{{ pom}}
{{ }}
{{ 0.0.1}}
{{ }}
{{}}
The resulting error is:
{{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
has 1 error}}
{{[ERROR] Version must be a constant @ line 13, column 12}}
Changing the version range of the parent to a fixed version e.g.
\{{2.1.5.Release}}, building works.
Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
without using the {{properties}} works as well.
So it somehow must be the combination of both features which are actually not
really related or am I missing something?
PS: I left the modules out for abbreviation purpose. The pom itself can still
be used to reproduced
was:
We would like to pass a [version
range|[https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]] to
the parent which should be possible since 3.5.0
At the same time, we would like to use [CI friendly
versions|[https://maven.apache.org/maven-ci-friendly.html]] for the artifact
itself.
Both on their own work well, but combined they don't.
{{}}
{{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/xsd/maven-4.0.0.xsd]";>}}
{{ 4.0.0}}
{{ }}
{{ org.springframework.boot}}
{{ spring-boot-starter-parent}}
{{ [2.1,3.0)}}
{{ }}
{{ com.example}}
{{ test}}
{{ ${revision}}}
{{ pom}}
{{ }}
{{ 0.0.1}}
{{ }}
{{}}
The resulting error is:
{{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
has 1 error}}
{{[ERROR] Version must be a constant @ line 13, column 12}}
Changing the version range of the parent to a fixed version e.g.
\{{2.1.5.Release}}, building works.
Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
without using the {{properties}} works as well.
So it somehow must be the combination of both features which are actually not
really related or am I missing something?
PS: I left the modules out for abbreviation purpose. The pom itself can still
be used to reproduced
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 3.6.1
>Reporter: Tom Kiemes
>Priority: Major
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{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/xsd/maven-4.0.0.xsd]";>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to repro
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900220#comment-16900220
]
Sebastian Ratz commented on MNG-6642:
-
Any news on a 3.6.2 release?
The regression was introduced in a patch release so I think this also warrants
a timely patch release with a fix.
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6727) Using version range in parent and CI Friendly Version fails
Tom Kiemes created MNG-6727:
---
Summary: Using version range in parent and CI Friendly Version
fails
Key: MNG-6727
URL: https://issues.apache.org/jira/browse/MNG-6727
Project: Maven
Issue Type: Bug
Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 3.6.1
Reporter: Tom Kiemes
We would like to pass a [version
range|[https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]] to
the parent which should be possible since 3.5.0
At the same time, we would like to use [CI friendly
versions|[https://maven.apache.org/maven-ci-friendly.html]] for the artifact
itself.
Both on their own work well, but combined they don't.
{{}}
{{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/xsd/maven-4.0.0.xsd]";>}}
{{ 4.0.0}}
{{ }}
{{ org.springframework.boot}}
{{ spring-boot-starter-parent}}
{{ [2.1,3.0)}}
{{ }}
{{ com.example}}
{{ test}}
{{ ${revision}}}
{{ pom}}
{{ }}
{{ 0.0.1}}
{{ }}
{{}}
The resulting error is:
{{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
has 1 error}}
{{[ERROR] Version must be a constant @ line 13, column 12}}
Changing the version range of the parent to a fixed version e.g.
\{{2.1.5.Release}}, building works.
Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
without using the {{properties}} works as well.
So it somehow must be the combination of both features which are actually not
really related or am I missing something?
PS: I left the modules out for abbreviation purpose. The pom itself can still
be used to reproduced
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518242274 I made the change locally and the unit test `StringSearchModelInterpolatorTest` passed succesfully. It's only unit test, so the IT would be more required. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518240573 @michael-o We can skip entire loop which is even better https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L280 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518233886 Of course and that's the point. Because reading the field of Java File does not make sense. It's not our code. What makes sense to me regarding interpolation of `java.io.File` is to get cannonic path of that file in string form. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518233272 But the field `isQualifiedForInterpolation` applies to the entire class, not just the field of this type. Are you certain about the `else if`? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518232941 There are more issues like introspecting `static` fields. Improvements: two instance variables can be turned to local variables, etc. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 edited a comment on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 edited a comment on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518232041 @michael-o I was backtracking the problem, and I have some findings. I know it is not your code ;-), but you are my ASF partner and @gnodet is dev partner too, so I want to discuss it with you and see your opions. The field `fs` of `java.io.File` was cached in `ObjectField -> CacheField` [1]. It is called in [2] without ignoring `java`, `javax` and `jackarta` packages. I think the whole problem is that the fields are eagerly introspected on Java objects in [1] which should be avoided by keeping the `CacheField` empty. Thus we should change the `else` to `else if ( isQualifiedForInterpolation )` in [3]. [1]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L307 [2]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L212 [3]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L305 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518232041 @michael-o I was backtracking the problem, and I have some findings. I know it is not your code ;-), but you are my ASF partner and @gnodet is dev partner too, so I want to discuss it with you and see your opions. The field `fs` of `java.io.File` was cached in `ObjectField -> CacheField` [1]. It is called in [2] without ignoring `java`, `javax` and `jackarta` packages. I think the whole problem is that the fields are eagerly introspected in Java objects in [1] which should be avoided by keeping the `CacheField` empty. Thus we should change the `else` to `else if ( isQualifiedForInterpolation )` in [3]. [1]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L307 [2]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L212 [3]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/StringSearchModelInterpolator.java#L305 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518217957 @Tibor17 This isn't my code, @gnodet can you pick this up? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518211774 Perhaps also the sanity check to introspect nested objects as well. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] Tibor17 edited a comment on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 edited a comment on issue #261: [MNG-6697] New fast model interpolator
not using reflection
URL: https://github.com/apache/maven/pull/261#issuecomment-518210937
@michael-o
Pls post a new links and PRs for related issues.
I wanted to say, using given questions, that this caching algorithm should
have sanity check for cacheable and eligible objects to cache, simply the
pseodo code in my mind:
```
if ( isValid( obj ) )
{
doCache( obj );
}
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
Tibor17 commented on issue #261: [MNG-6697] New fast model interpolator not
using reflection
URL: https://github.com/apache/maven/pull/261#issuecomment-518210937
@michael-o
Pls post a new links and PRs for related issues.
I wanted to say, using given questions, that this caching algorithm should
have sanity for cacheable and eligible objects to cache, simply the pseodo code
in my mind:
```
if ( isValid( obj ) )
{
doCache( obj );
}
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection
michael-o commented on issue #261: [MNG-6697] New fast model interpolator not using reflection URL: https://github.com/apache/maven/pull/261#issuecomment-518130361 We need to check the log, I thiink there was also some use of reflection before this change. BTW, this is a common problem, not just in Maven. Compiling with Maven 3.5.4 a webapp: ``` Building WAR files... WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/net/home/osipovmi/.m2/repository/org/glassfish/jaxb/jaxb-runtime/2.3.0/jaxb-runtime-2.3.0.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release ``` I think we should spawn another issue for this, continue with 3.6.2, but address this in the next release. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MDEP-655) The unpack integration test fails intermittent.
[ https://issues.apache.org/jira/browse/MDEP-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899826#comment-16899826 ] Karl Heinz Marbaise commented on MDEP-655: -- In the Bug description there is a workaround described which I have used...I'm investigating this more in detail...to see if there is more to do... > The unpack integration test fails intermittent. > --- > > Key: MDEP-655 > URL: https://issues.apache.org/jira/browse/MDEP-655 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: unpack >Affects Versions: 3.1.1 > Environment: Mac OS >Reporter: Pim Moerenhout >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When doing a clean integration test, the test case fails intermittent on Mac > OS. The command executed are: > mvn clean verify -Prun-its -Dinvoker.test=unpack,setup* > or > mvn clean install -- This message was sent by Atlassian JIRA (v7.6.14#76016)
