[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825445#comment-16825445
]
Gunnar Morling commented on MCOMPILER-320:
------------------------------------------
Hey [~rfscholte], first of all, thanks a lot for all you work on maintaining
this and other Maven plug-ins!
{quote}
If I would have accepted every PR or implement every proposal, this project
would be total chaos.
{quote}
My total sympathies for this one, it's the tough and not always pleasant fate
of libraries maintainers :-)
{quote}
In this case I tried to come up with a proposal that should be more natural. In
general I believe dependencies should be made explicit so Maven can resolve
them at the right time...
{quote}
Agreed to that, but could you take a look at David's example in the [comment
above from 17/Jan/18|
https://issues.apache.org/jira/browse/MCOMPILER-320?focusedCommentId=16329558&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16329558]?
It shows how the proposed change would simplify the creation of multi-release
JARs. The challenge there -- and it's nicely solved by the proposed change --
is to compile source sets specific to different Java versions while re-using
classes compiled before for other versions.
So e.g. you might want to compile a base line of the majority of the project's
classes (common to all Java versions) and then only one small additional set of
classes specific to Java 11, 12 etc. For efficiency reasons, you want to do
this *without re-compiling* all the common classes from the base line. A while
ago, I solved this in a [blog post
here|http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/]
using the Maven Ant run plug-in, essentially emulating the change proposed here
and hinting that there indeed is a gap in the compiler plug-in feature set
currently. As the classpath elements refer to classes just being compiled,
there's also no way how this could be solved using dependency scopes AFAICS.
By renaming the option to {{additionalClasspathElements}} so to be consistent
with the similar option of the Surefire plug-in, I would think it's a valuable
addition addressing a common use case; specifically I wouldn't know how the
issue of MR JARs can be efficiently solved without it, as indicated by my Ant
run hack above.
Would this input enough to reconsider the decision? Cheers!
> Allow additional class path items to be given during compilation
> ----------------------------------------------------------------
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
> Reporter: David M. Lloyd
> Assignee: Robert Scholte
> Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
