[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=16534098#comment-16534098
]
Robert Scholte commented on MNG-6130:
-
In general we say: if a plugin has an issue, update to the latest and see if it
is fixed. That seems to be the case here, since the latest maven-javadoc-plugin
did fix your issue. All maven-compat classes have replacements which should be
used by plugins. Not changing this code is also a political way of saying that
plugins should try to move to more recent APIs of Maven. It would be nice if
all current classes in maven-compat could be dropped in Maven 4, so we somehow
need to motivate plugins to move forward.
> 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 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)
[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=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 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)
[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=16531870#comment-16531870
]
Michael Osipov commented on MNG-6130:
-
[~rfscholte], thanks for the analysis. {{DefaultProjectBuilder}} is out of my
knowledge. Any ideas how we can proceed here?
[~boris_brodski], can you make sure that all of the plugins you are using in
the faulty build are Maven 3+?
> 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 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)
[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=16531762#comment-16531762
]
Robert Scholte commented on MNG-6130:
-
{{DefaultMavenProjectBuilder}} is part of maven-compat, it is deprecated and
should only be used by Maven2 plugins. Instead plugins should use
{{DefaultProjectBuilder}}.
I prefer not to touch maven-compat, it is there only for compatibilty.
I'm kind of surprised that it is used, the maven-javadoc-plugin shouldn't use
it (latest is already Maven 3 only and doesn't use maven-compat), nor should
Maven.
So we should verify if this is an issue for {{DefaultProjectBuilder}}, in the
end that's the used implementation.
> 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 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)
[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=16531736#comment-16531736
]
Michael Osipov commented on MNG-6130:
-
[~boris_brodski], thank you for looking into this.I do really appreciate.
Please join IRC on freenode, #maven.
[~rfscholte], any idea how we can proceed here? The requester is unable to
strip down his issue. I don't want to reject hard work just because the IT is
too complex to build.
> 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 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)
[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=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 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)
[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=16521277#comment-16521277
]
Michael Osipov commented on MNG-6130:
-
[~boris_brodski], do you think you can provide an IT for that? Would be awesome.
> 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 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)
[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=16071792#comment-16071792
]
Michael Osipov commented on MNG-6130:
-
I cannot properly merge this without a test. Can you provide one? Otherwise it
will never make into master...
> 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
>Assignee: Michael Osipov
> Labels: easyfix, patch
> Fix For: 3.5.1-candidate
>
> 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 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
(v6.4.14#64029)
[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=16011274#comment-16011274
]
Michael Osipov commented on MNG-6130:
-
[~boris_brodski], are you able to create a sample project? I'd like to turn
that into an IT. At best, you provide the IT.
> 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
>Assignee: Michael Osipov
> Labels: easyfix, patch
> Fix For: 3.5.1-candidate
>
> 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 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
(v6.3.15#6346)
