You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Boris Brodski (JIRA)" <ji...@apache.org> on 2018/07/03 13:02:00 UTC

[jira] [Commented] (MNG-6130) Loss of profile information in workaround for MNG-4900

    [ https://issues.apache.org/jira/browse/MNG-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531338#comment-16531338 ] 

Boris Brodski commented on MNG-6130:
------------------------------------

Hello Michael, sure it would be awesome :)

I gave it another try. For about 3 days I tried really hard to isolate and reproduce the problem. I gained more knowledge about to matter, but still was unable to pinpoint it. Our build, that reproduces the problem is huge with lots of modules, parent hierarchy, repos, m2 configuration and plugins. The error hangs somehow together with javadoc plugin with a custom doclet + javadoc dependencies of the 'eclipse-plugin' type. This dependency shouldn't exist locally. Resolving it requires expanding property-variables, that doesn't work correctly resulting in a corrupt URL exception. My problem is, that at some point I can't reduce the project without loosing the error. Removing even completely unrelated parts of the configuration prevents the error.

At the end I still have a huge project with many parents, custom m2 configuration, many repos and some plugins. Too large to build a regression test out of it :(

If you would like to help me, we could chat on the matter. I'm very interested in this bugfix being included into the upcoming release!

Thank you!

> 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)