[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966676#comment-16966676
]
David M. Lloyd commented on MCOMPILER-320:
------------------------------------------
> Everything on the classpath should be managed as a dependency in the pom.
That means every intermediate build step - every stub class - every layer -
needs a separate Maven submodule and artifact. For what reason? Because of an
unreasonable ideology. I feel like those who cling to this point of view have
never done anything nontrivial with Maven. Not even considering the pointless
performance penalties of doing so, it vastly complicates otherwise far simpler
builds for absolutely no valid reason.
I'm sorry to see that you're so very blinded by this naive notion. I think to
be safe you'd better disable multiple executions of plugins like the compiler
plugin just to make sure that people don't operate under the illusion that
Maven has the capability that it actually does have (but make sure you don't
think too much about why that capability exists). If you cripple it enough,
perhaps your illusory ideology will become real.
In the meantime we'll have to continue maintaining our fork, which, with one
simple change, dramatically simplifies layered compilation, and allows us to
exercise a much more sane design principle: one module per artifact, rather
than N modules per artifact plus extra scaffolding to prevent the pointless
intermediate modules from being deployed.
> Only this way Maven can ensure complete classpath resolution (including
> transitive dependencies).
This is patently false. This has nothing to do with dependency resolution and
everything to do with layered compilation.
> To me it is still an edge case and AFAIK only Redhat needs to trick the
> compiler
This is false also. Only Red Hat *has* gone so far as to do this because most
"regular" users would see it's not possible and try a different (worse)
approach, or just give up. That in no way means this approach isn't better, or
cleaner, or more logical. Must users simply don't know how to ask for what
they need. It's not unusual within one of my many active projects for just one
user to ask for something (maybe after months or years of project maturity)
which later goes on to be a popular feature. So this logic is clearly flawed.
> I've tried to find the problem with Quarkus, but it is simply too big.
I guess you'll have to take my word then. This is a very useful feature - one
entirely consistent with the design of the Java compiler - and you're
needlessly limiting Maven's capabilities by excluding it. Do you _really_
believe that users will see this feature and run amok with it? I don't.
> 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
(v8.3.4#803005)
