[jira] [Updated] (MNG-8112) extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path
[ https://issues.apache.org/jira/browse/MNG-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich DiCroce updated MNG-8112: -- Description: As the title says: extension.xml is ignored when an extension is loaded by -Dmaven.ext.class.path, which makes it impossible to expose any additional packages. I am filing this as a bug due to [this comment|https://issues.apache.org/jira/browse/MNG-6906?focusedCommentId=17719869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17719869] on MNG-6906, which says that lib/ext and -Dmaven.ext.class.path are supposed to be synonymous. Note that MNG-6906 is a related but different problem. When looking at org.apache.maven.cli.MavenCli, the problems aren't too hard to see: # lib/ext extensions get loaded into the plexus.core realm (as per m2.conf), but -Dmaven.ext.class.path extensions are loaded into the maven.ext realm (as per MavenCli#setupContainerRealm()). # loadCoreExtensions() operates on the coreRealm, but due to #1, the extensions are not in that realm. Also, the result of parseExtClasspath() is not passed to loadCoreExtensions(), so there is no way for loadCoreExtensions() to find the relevant files. The most obvious solution would be to call coreRealm.addURL() for each of the files discovered by parseExtClasspath(). This would solve #1 above which would implicitly fix #2. Though I don't know if it would have other consequences. If this is not a bug and is instead "works as designed", then [https://maven.apache.org/guides/mini/guide-using-extensions.html] needs to be updated to explain that the three methods of loading core extensions are not equivalent. was: As the title says: extension.xml is ignored when an extension is loaded by -Dmaven.ext.class.path, which makes it impossible to expose any additional packages. I am filing this as a bug due to this comment on MNG-6906, which says that lib/ext and -Dmaven.ext.class.path are supposed to be synonymous. Note that MNG-6906 is a related but different problem. When looking at org.apache.maven.cli.MavenCli, the problems aren't too hard to see: # lib/ext extensions get loaded into the plexus.core realm (as per m2.conf), but -Dmaven.ext.class.path extensions are loaded into the maven.ext realm (as per MavenCli#setupContainerRealm()). # loadCoreExtensions() operates on the coreRealm, but due to #1, the extensions are not in that realm. Also, the result of parseExtClasspath() is not passed to loadCoreExtensions(), so there is no way for loadCoreExtensions() to find the relevant files. The most obvious solution would be to call coreRealm.addURL() for each of the files discovered by parseExtClasspath(). This would solve #1 above which would implicitly fix #2. Though I don't know if it would have other consequences. If this is not a bug and is instead "works as designed", then [https://maven.apache.org/guides/mini/guide-using-extensions.html] needs to be updated to explain that the three methods of loading core extensions are not equivalent. > extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path > --- > > Key: MNG-8112 > URL: https://issues.apache.org/jira/browse/MNG-8112 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.9.6 >Reporter: Rich DiCroce >Priority: Major > > As the title says: extension.xml is ignored when an extension is loaded by > -Dmaven.ext.class.path, which makes it impossible to expose any additional > packages. > I am filing this as a bug due to [this > comment|https://issues.apache.org/jira/browse/MNG-6906?focusedCommentId=17719869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17719869] > on MNG-6906, which says that lib/ext and -Dmaven.ext.class.path are supposed > to be synonymous. Note that MNG-6906 is a related but different problem. > When looking at org.apache.maven.cli.MavenCli, the problems aren't too hard > to see: > # lib/ext extensions get loaded into the plexus.core realm (as per m2.conf), > but -Dmaven.ext.class.path extensions are loaded into the maven.ext realm (as > per MavenCli#setupContainerRealm()). > # loadCoreExtensions() operates on the coreRealm, but due to #1, the > extensions are not in that realm. Also, the result of parseExtClasspath() is > not passed to loadCoreExtensions(), so there is no way for > loadCoreExtensions() to find the relevant files. > The most obvious solution would be to call coreRealm.addURL() for each of the > files discovered by parseExtClasspath(). This would solve #1 above which > would implicitly fix #2. Though I don't know if it would have other > consequences. > If this is not a bug and is instead "works as designed", then > [https://maven.apache.org/
[jira] [Created] (MNG-8112) extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path
Rich DiCroce created MNG-8112: - Summary: extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path Key: MNG-8112 URL: https://issues.apache.org/jira/browse/MNG-8112 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.9.6 Reporter: Rich DiCroce As the title says: extension.xml is ignored when an extension is loaded by -Dmaven.ext.class.path, which makes it impossible to expose any additional packages. I am filing this as a bug due to this comment on MNG-6906, which says that lib/ext and -Dmaven.ext.class.path are supposed to be synonymous. Note that MNG-6906 is a related but different problem. When looking at org.apache.maven.cli.MavenCli, the problems aren't too hard to see: # lib/ext extensions get loaded into the plexus.core realm (as per m2.conf), but -Dmaven.ext.class.path extensions are loaded into the maven.ext realm (as per MavenCli#setupContainerRealm()). # loadCoreExtensions() operates on the coreRealm, but due to #1, the extensions are not in that realm. Also, the result of parseExtClasspath() is not passed to loadCoreExtensions(), so there is no way for loadCoreExtensions() to find the relevant files. The most obvious solution would be to call coreRealm.addURL() for each of the files discovered by parseExtClasspath(). This would solve #1 above which would implicitly fix #2. Though I don't know if it would have other consequences. If this is not a bug and is instead "works as designed", then [https://maven.apache.org/guides/mini/guide-using-extensions.html] needs to be updated to explain that the three methods of loading core extensions are not equivalent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774037#comment-17774037
]
Rich DiCroce commented on MRESOLVER-372:
Tamas, you read my mind. :)
Making the cache CAS-like could be handy. Early drafts of the SLSA spec
required content-addressable caches for levels 3 and 4, but it looks like the
final draft removed that. Probably because it was infeasible due to the
popularity of build systems like Maven that don't currently comply with it. But
as you said, making a change that large could be a problem for other code that
assumes Maven caches are laid out in a particular way. That's why I suggested
to just use timestamped files, since that's a smaller change that's less likely
to break things.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[ https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17773776#comment-17773776 ] Rich DiCroce commented on MRESOLVER-372: I've been investigating why the most recent versions of Eclipse throw errors when trying to update snapshots, and ended up here. IMO this problem can only be properly fixed by changes to Maven Resolver, but the situation is complicated. It's important to note that the rest of what I write is about the exception posted in the original description of this issue. The exception posted by Delany in the comment above is NOT the same issue. The top-level problem is that Eclipse has an open handle to the JAR file. On Windows, this prevents the file from being replaced. So we start going down the rabbit hole. Why does Eclipse have an open handle to the JAR file? I found that there are at least three separate answers: # m2e loads Maven plugins so they can be executed during builds # Eclipse JDT loads the project's dependencies if annotation processing is enabled # PMD Eclipse Plugin also loads the project's dependencies if "Enable using Java Project Build Path" is enabled But all three of these boil down to the same problem: they need to construct a URLClassLoader so they can load classes from the JARs. The classloader is the thing that is actually holding the open handle. Okay, so the problem could be solved by not holding on to the classloader. Except that's probably not feasible. An IDE needs to support incremental compilation. That means state needs to be retained between builds, which could mean that the classloader can't just be discarded. Well then, maybe the classloader itself could be changed to not hold open references to the JARs? That seems like it could cause all sorts of havoc if a JAR was replaced, and some classes are loaded from the old JAR and some classes get loaded from the new JAR. I doubt the JDK maintainers would be willing to accept a change like that. Okay, so we have to hold on to the classloader and the classloader has to hold on to the JARs. What if we just copied the JARs to some temp directory? Well, we could do that... but then every single part of the IDE that needs to load the project's plugins or dependencies has to implement that. That could be a lot of changes in a lot of places. And if any part of the IDE doesn't do that, the problem comes back and is very painful to locate. Which brings us to the conclusion I arrived at: the right solution is to just not replace the JARs at all. So I started digging through the Maven Resolver code and found the aether.artifactResolver.snapshotNormalization option. When this option is enabled (which is the default), Maven Resolver first downloads a new snapshot to a timestamped JAR file, then copies that JAR to the -SNAPSHOT file. Okay, so we just need to disable that option and our problem is solved! Except it's not. For one thing, locally built JARs are always written to the -SNAPSHOT file. So if you have two Eclipse workspaces open, and you're building a JAR in one workspace that is needed by the other workspace, you're still going to have the same problem. Secondly, from reading the code, it looks like Maven Resolver always looks for the -SNAPSHOT file first, precisely because that's where a locally built JAR is always installed. So if we turn off normalization and we already have a -SNAPSHOT file, then we'll never actually use any new snapshots we download from a server. That brings us to my proposed solution: the -SNAPSHOT file must die. Instead, all snapshot JARs must have timestamped filenames so that the JAR files are always immutable. Achieving this requires some big changes though: * maven-install-plugin would need an option to install timestamped snapshots. For backwards compatibility, this would have to be off by default. * Maven Resolver would need to deal with timestamped, locally-built snapshots. It would also have to deal with -SNAPSHOT files written by older versions, which probably means changing the way it decides which snapshot to use. Perhaps it could look at all the eligible snapshots and use the one with the newest file modification time. (Of course, then you're depending on the system clock to be sane, which isn't great either.) I'm not an expert on any of the internals here, so there may be other headaches I haven't thought of. Even if we can get consensus on how to fix this, I don't have time to work on it right now. I've already spent more time investigating this than I should have. But I figured it was worth it to document my findings so someone else can take a crack at it. > Download fails if file is currently in use under windows > > > Key: MRESOLVER-372 > URL: https://issues.apache.org/jira/browse/MRESOLVER-
[jira] (MCOMPILER-242) Add option to force consistent ordering of source files
Rich DiCroce created MCOMPILER-242: -- Summary: Add option to force consistent ordering of source files Key: MCOMPILER-242 URL: https://jira.codehaus.org/browse/MCOMPILER-242 Project: Maven Compiler Plugin Issue Type: New Feature Affects Versions: 3.3 Reporter: Rich DiCroce In theory, the order in which source files are compiled should not matter. In practice, there are issues like [JDK-8067422|https://bugs.openjdk.java.net/browse/JDK-8067422] in which compilation order does matter. That issue does not affect the functionality of the compiled class, but does result in different output. This is a problem if you need to create a strictly reproducible build, by which I mean it should be possible to repeat a build and have the checksum for all files be identical. Adding such an option would require changes in both maven-compiler-plugin and plexus-compiler-api. Specifically, the method org.codehaus.plexus.compiler.AbstractCompiler#getSourceFiles(CompilerConfiguration) needs to have a check added at the end. Depending on the value of some option in the configuration, it should sort the result array to ensure consistent ordering. The ability to set that option would then be exposed by maven-compiler-plugin. I have hacked in such an option without changing maven-compiler-plugin (for simplicity) [here|https://github.com/rdicroce/plexus-compiler/tree/sort-source-files], but it would be nicer if the option were properly exposed. The choice of "-XDsortFiles" comes from the very undocumented javac option of the same name, which is supposed to do the same thing but appears to only have an effect if javac itself needs to walk the directory tree to discover source files. Note that, without this change, compilation order is still consistent as long as the files have the same absolute path every time they are compiled. So, for example, if you check out a project and compile it multiple times from "C:/sources/foo", the output will always be the same. But if you check out the project into "C:/other-sources/foo", the order will be different. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-721) Mercurial ChangeLog command doesn't respect limit
Rich DiCroce created SCM-721: Summary: Mercurial ChangeLog command doesn't respect limit Key: SCM-721 URL: https://jira.codehaus.org/browse/SCM-721 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.8.1 Reporter: Rich DiCroce The changeLog() method does not respect the limit parameter. This appears to happen because the limit parameter gets lost in the middle of the method chain: 1. HgScmProvider.changelog() calls AbstractCommand.execute() 2. AbstractCommand.execute() calls AbstractChangeLogCommand.executeCommand() 3. AbstractChangeLogCommand.executeCommand() calls one of two overloads of executeChangeLogCommand(), both of which are deprecated. Neither takes a limit parameter, and the limit parameter is lost at this point. I encountered this problem on Mercurial, but other providers will also be affected unless their concrete ChangeLogCommand implementations override executeCommand() to call a method that supports the limit parameter. Curiously, HgChangeLogCommand does have such a method, but it is never called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
