search

eirslett / frontend-maven-plugin

"Maven-node-grunt-gulp-npm-node-plugin to end all maven-node-grunt-gulp-npm-plugins." A Maven plugin that downloads/installs Node and NPM locally, runs NPM install, Grunt, Gulp and/or Karma.
Apache License 2.0
4.2k stars 868 forks source link

Node cannot be installed to relative path #1124

Closed mvilliger closed 7 months ago

mvilliger commented 7 months ago

Do you want to request a feature or report a bug? Report a Bug

What is the current behavior? Using a relative path in installDirectory for goal install-node-and-npm always leads to "Bad zip entry" exception:

<plugin>
  <groupId>com.github.eirslett</groupId>
  <artifactId>frontend-maven-plugin</artifactId>
  <configuration>
    <installDirectory>${project.build.outputDirectory}/subfolder/../node</installDirectory>
    <nodeVersion>whatever</nodeVersion>
  </configuration>
</plugin>

The reason seems to be here where a normalized destPath is compared against a non-normalized destinationDirectory. I assume the destinationDirectory should be normalized as well before comparing.

If the current behavior is a bug, please provide the steps to reproduce. Execute the install-node-and-npm goal with a relative installDirectory for node as shown in the sample above.

What is the expected behavior? Node is correctly extracted to the normalized path of the given relative installDirectory.

Please mention your frontend-maven-plugin and operating system version. frontend-maven-plugin version: 1.14.2 operating system: any

eirslett commented 7 months ago

What is the use case for this? Is it not possible to achieve using ${maven.multiModuleProjectDirectory} or ${project.parent.basedir} or something like that? Why is node being installed inside outputDirectory (I assume it's one of the target folders)?

mvilliger commented 7 months ago

We use a general parent pom which installs Node into the parent module's target dir as soon as the first sub-module is built which requires Node. For this the destination directory is configured using various properties which some might contain /../.

Anyway it should not have any downside to normalize both directories as comparing them only makes sense if both are compared normalized. Don't you think?

mvilliger commented 7 months ago

Another point: These kind of installDirectories used to work fine in version < 1.13. So it seems like a regression concerning this feature. Currently, this blocks us from updating the plugin.