Plugin classpath used during JSP compilation

[ksmith97]

I ran into this issue compiling JSPs with scriplets, where it was using a version of guava from the plugin dependency chain that was incompatible with the version in my project dependencies. It looks like the plugin dependencies are available at compile time and are in fact given preferential class loading preference.

I made a repo https://github.com/ksmith97/JSPC-issue to showcase the issue and how I fixed it for the guava case. I'm not sure if its possible to create a general solution but at the very least documenting it might help someone with a similar issue in the future.

I know scriplets are not good practice anymore but for some of us that just inherited a codebase with a large existing number of them we have to support them.

[ChristianMurphy]

Thanks @ksmith97!
Is this related to #41?
Would you be interested in opening a PR documenting the fix?

[ksmith97]

@ChristianMurphy My fix specifically resolved my issue with guava but it was not really a general solution for the issue. Clearly some of the plugin dependencies should not be on the JSP compilation path but I'm not sure where to start on that particular issue.

[ChristianMurphy]

@ksmith97 I'm not sure off the top of my head, that would require some research.
To clarify the intent of this issue.
The goal is to be able to user one version of guava to compile the plugin, and a different version of guava to compile the JSP itself.
Is that an accurate interpretation?

[ksmith97]

The goal is that dependencies required for the plugin to execute should not exist on the classpath of the jsp compiler. To avoid issues like mine where a plugin jar overrode a project jar or a potential issue where the project is missing a dependency declaration but the plugin classpath accidentally supplies it(for example guava!) leaving you to explode at runtime.

[ksmith97]

I have some free time so I am looking into what might have caused this issue. At a quick glance it looks like this shouldn't have been a problem in the first place since the classpath looks like it comes from project.compileClasspathElements and the documentation does not imply that this should contain plugin artifacts but its not super clear. I will probably need to write a test to verify that this is what is actually happening and debug it some before trying to fix it. Changing this is potentially breaking behavior although I cannot think of many reasons you would want a compile time dependency from the plugin on your classpath but maybe there is for some sort of compile time generation of code.

[ChristianMurphy]

Hey there! 👋

Thanks for opening an issue with jspc-maven-plugin. 👍 🙇‍♂️
At the moment, the jspc maven plugin does not have an active maintainer to process your request. ⛔
While the Jasig jspc maven plugin is without an active maintainer, we recommend the Apache Sling jspc maven plugin and the Jetty jspc maven plugin as alternatives that are actively maintained. ✅
If you are interested in becoming a project maintainer, there is a uPortal-dev list post where you can register your interest. 📧

Thanks again for contributing to the jspc-maven-plugin! ✨