[
https://issues.apache.org/jira/browse/MNG-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533056#comment-16533056
]
Boris Brodski commented on MNG-6130:
------------------------------------
Hello Michael,
Hello Robert,
I tried to use the version 3.0.1 of the 'maven-javadoc-plugin' and this indeed
looks good at the first glance.
Although I do completely understand, why changing the compat-code is a bad
idea, I would like to bring an argument, why this may be not as bad in this
particular case. (Yes, yes, everybody say that :) )
The nature of the bug is kind of random. It strikes rare, but if it strikes,
the activated profiles get deactivated for a particular small execution part
(evaluation sub-tree), that may or may not break builds. The slightest change
in the build environment, like locally available or not available artifacts,
affects the bug. You can run 'mvn clean install' two times - first time the bug
strikes, second time not.
So here is my point: The builds, that we may break by applying this bugfix, are
builds that should already be breaking on the slightest change in the build
environment. So the chances are big, that those builds were fixed, so that they
run no matter if this bug strikes or not.
I hope, you get my idea :)
Cheers,
Boris Brodski
PS I will try to meet you on IRC tomorrow.
> Loss of profile information in workaround for MNG-4900
> ------------------------------------------------------
>
> Key: MNG-6130
> URL: https://issues.apache.org/jira/browse/MNG-6130
> Project: Maven
> Issue Type: Bug
> Components: core
> Affects Versions: 3.3.9, 3.5.0
> Environment: Windows
> Reporter: Boris Brodski
> Priority: Major
> Labels: easyfix, patch
> Fix For: waiting-for-feedback
>
> Attachments: MNG-6130.patch
>
>
> Please, forgive me not providing example project reproducing the bug.
> It's very tricky and hopefully not necessary, since the 1-line fix is
> provided.
> Using profiles together with maven-javadoc-plugin results in the following
> problem:
> - Configuration from active profiles is not considered during dependency
> resolution started problematically from the maven-javadoc-plugin.
> This leads to unpredictable behavior, that is somewhat hard to reproduce.
> Here is the technical inside and the 1-line fix:
> In the DefaultMavenProjectBuilder.toRequest():
> {noformat}
> if ( profileManager != null ) {
> ...
> } else {
> ...
> /*
> * MNG-4900: Hack to workaround deficiency of legacy API which makes it
> impossible for plugins to access the
> * global profile manager which is required to build a POM like a CLI
> invocation does. Failure to consider
> * the activated profiles can cause repo declarations to be lost which in
> turn will result in artifact
> * resolution failures, in particular when using the enhanced local repo
> which guards access to local files
> * based on the configured remote repos.
> */
> request.setActiveProfileIds( req.getActiveProfiles() );
> request.setInactiveProfileIds( req.getInactiveProfiles() );
> }
> {noformat}
> Here we copy active and inactive profile ids, but we don't copy the list of
> all profile ids. Missing line:
> {noformat}
> request.setProfiles( req.getProfiles() );
> {noformat}
> As the result the method DefaultProfileManager.getActiveProfiles() always
> returns an empty list:
> {noformat}
> List<Profile> activeProfiles = new ArrayList<>( profiles.size() );
> for ( Profile profile : profiles ) {
> ...
> }
> return activeProfiles;
> {noformat}
> "profiles" here is empty, since it wasn't copied together with
> "getActiveProfiles()" and "getInactiveProfiles()"
> Adding the missing line fixes the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
