Maven plugin - revert the security manager back to previous

[tomb50]

This prevents subsequent plugins from being impacted by the orchid SM (often seen as java.lang.SecurityException: Modifying file outside source, destination, and temp directories)

For example, a maven module where I want to package the output of orchid in a standard jar.

I bind orchid:build to the install phase, but subsequent plugins such as maven-jar and maven-install fail as the SecuirtyManager is hanging around!

The below stacktrace demonstrates a subsequent plugin (in this case groovy failing due to the orchid security manager)

java.lang.SecurityException: Modifying file outside source, destination, and temp directories: home/tomb/.m2/repository/org/codehaus/groovy/maven/runtime/gmaven-runtime-1.5/1.0 at com.eden.orchid.api.OrchidSecurityManagerImpl.checkFilesystemWriteAccess (OrchidSecurityManagerImpl.java:107) at com.eden.orchid.api.OrchidSecurityManagerImpl.checkWrite (OrchidSecurityManagerImpl.java:91) at java.io.File.mkdir (File.java:1325) at java.io.File.mkdirs (File.java:1357) at org.eclipse.aether.internal.impl.TrackingFileManager.update (TrackingFileManager.java:89) at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write (DefaultUpdateCheckManager.java:590) at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact (DefaultUpdateCheckManager.java:526) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads (DefaultArtifactResolver.java:619) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads (DefaultArtifactResolver.java:510) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve (DefaultArtifactResolver.java:401) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts (DefaultArtifactResolver.java:229) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact (DefaultArtifactResolver.java:207) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact (DefaultRepositorySystem.java:262) at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:318) at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:299) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject (MavenMetadataSource.java:591) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve (MavenMetadataSource.java:211) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse (DefaultLegacyArtifactCollector.java:551) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect (DefaultLegacyArtifactCollector.java:148) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve (DefaultArtifactResolver.java:504) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions (DefaultArtifactResolver.java:358) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively (DefaultArtifactResolver.java:352) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively (DefaultArtifactResolver.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively (DefaultArtifactResolver.java:287) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively (DefaultArtifactResolver.java:261) at org.codehaus.groovy.maven.plugin.ProviderMojoSupport$ArtifactHandlerImpl.resolve (ProviderMojoSupport.java:207) at org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.buildClassPath (ArtifactProviderLoader.java:91) at org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.loadProvider (ArtifactProviderLoader.java:114) at org.codehaus.groovy.maven.runtime.loader.artifact.ArtifactProviderLoader.load (ArtifactProviderLoader.java:78) at org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.load (DefaultProviderSelector.java:216) at org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.discover (DefaultProviderSelector.java:178) at org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.register (DefaultProviderSelector.java:122) at org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.select (DefaultProviderSelector.java:71) at org.codehaus.groovy.maven.runtime.loader.DefaultProviderManager.select (DefaultProviderManager.java:102) at org.codehaus.groovy.maven.plugin.ProviderMojoSupport.provider (ProviderMojoSupport.java:120) at org.codehaus.groovy.maven.plugin.ComponentMojoSupport.feature (ComponentMojoSupport.java:49) at org.codehaus.groovy.maven.plugin.ComponentMojoSupport.feature (ComponentMojoSupport.java:42) at org.codehaus.groovy.maven.plugin.ComponentMojoSupport.doExecute (ComponentMojoSupport.java:53)

[tomb50]

I have manually tested this by updating the test.sh to install the plugin (instead of just packaging) and then using it in my project

[cjbrooks12]

Good catch! The Maven plugin was originally a community contribution and I plan on moving it into a separate repo soon to encourage more community support on making it work fully as it should. I'm much more familiar with Gradle, which runs Orchid in a separate JVM process, so I'm not always aware of the issues that arise with Orchid running within the normal Maven process and modifying the global JVM state.

[tomb50]

Awesome, thanks for the swift response btw - I must have missed it. Indeed a separate repo in the future would be easier (at least for me :-D) to contribute to without having to worry to much about overstepping