Maven 2 & 3

Plugin dependencies are incorrectly included as needed artifacts in IBM JDK 1.5 sr8 and IBM JDK 1.6

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Not A Bug
  • Affects Version/s: 2.0.9
  • Fix Version/s: None
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    OS : Windows Server 2003
    JDK: IBM JDK 1.5 sr8 edition and IBM JDK 1.6
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

We have been using a "parent pom" that specifies the plugin dependencies for our projects. This parent pom has been in use for more than a year. We have been using IBM JDK 1.5 sr4 until recently, and we had no problems building the parent pom. However for the upcoming release we upgraded to IBM JDK 1.5 sr8. Upon upgrade to the sr8 edition, when we tried to build the parent pom, the build process incorrectly tried to search for specified plugin dependencies, and since these specified plugin dependencies are built AFTER the parent pom is built the build process fails with the error message that it could not find the plugin-dependencies in order to proceed with building the parent pom.

We encountered the same issue with IBM JDK 1.6 as well. Since many of the developers who use our product will be using IBM JDK 1.6, we need to resolve this issue for both IBM JDK1.5 sr8 and IBM JDK 1.6.

We did NOT encounter this issue with the Sun JDK 1.6. This led us to approach IBM to investigate the issue as it appeared that this maybe an IBM JDK specific issue. We sent our test case to them, and they reported to us that suspect that maven code could be depending on the hashmap ordering, which is breaking the dependency check.

They instructed us to post this issue to the maven issue tracking and they will follow up with the maven folks.

Attached is the test case to reproduce the problem. Please read the file how_to_reproduce.txt in the attached. IBM folks will provide you with the needed JDK's.

Attachments

Issue Links

This issue is related to:
MNG-3106 Multiple profile activation conditions broken Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

That one is nice. The build failure (Unable to build project for plugin 'com.ebay.ebox.maven.plugin.sr8:maven-v4-plugin') or build success ultimatively depend on the POM profile "ebox-v4-prebuild" being active or not. If the profile is active, it introduces a dependency on the mentioned plugin which can't be resolved yet.

The relevant piece of info about the profile "ebox-v4-prebuild" is that it employs multiple activation conditions. Before MNG-3106 was fixed in r656820, the first and only the first matching profile activator would determine the actiation status. The activators are looked up from the Plexus container with a non-deterministic order. Now, with JDK 1.5 sr4, the activator responsible for <file> was checked before the one responsible for <property>. As ".v4prebuild" does not exist, the file activator caused the profile to be disabled. In newer JDKs, the order of the activators was reversed, so this time the property activator was queried first, and it deemed the profile active as the property "skip.v4.prebuild" is not set.

Newer Maven versions handle multiple activators as logically ORed, so they will activate the profile, regardless of the activators order. So you would need to update your profile activation conditions.

Show
Benjamin Bentmann added a comment - That one is nice. The build failure (Unable to build project for plugin 'com.ebay.ebox.maven.plugin.sr8:maven-v4-plugin') or build success ultimatively depend on the POM profile "ebox-v4-prebuild" being active or not. If the profile is active, it introduces a dependency on the mentioned plugin which can't be resolved yet. The relevant piece of info about the profile "ebox-v4-prebuild" is that it employs multiple activation conditions. Before MNG-3106 was fixed in r656820, the first and only the first matching profile activator would determine the actiation status. The activators are looked up from the Plexus container with a non-deterministic order. Now, with JDK 1.5 sr4, the activator responsible for <file> was checked before the one responsible for <property>. As ".v4prebuild" does not exist, the file activator caused the profile to be disabled. In newer JDKs, the order of the activators was reversed, so this time the property activator was queried first, and it deemed the profile active as the property "skip.v4.prebuild" is not set. Newer Maven versions handle multiple activators as logically ORed, so they will activate the profile, regardless of the activators order. So you would need to update your profile activation conditions.
Hide
Permalink
nambi sankaran added a comment -

This issue manifests when we use IBM JDK 1.6.
But there are no problems with SUN JDK 1.6.

Why do we see different behaviour between Different JDK vendors?

Show
nambi sankaran added a comment - This issue manifests when we use IBM JDK 1.6. But there are no problems with SUN JDK 1.6. Why do we see different behaviour between Different JDK vendors?
Hide
Permalink
Baback Nemazie added a comment -

Hi Ben,

It seems your response suggests that an upgrade to version 2.0.10, the version on which MNG-3106 was fixed, should have fixed the problem. However I previously tried mvn 3.0 alpha and I encountered the same problem. Trying with mvn 2.0.10 I still have the same problem. Building the parent pom pulls in the plugin dependencies.

Please advise.

Show
Baback Nemazie added a comment - Hi Ben, It seems your response suggests that an upgrade to version 2.0.10, the version on which MNG-3106 was fixed, should have fixed the problem. However I previously tried mvn 3.0 alpha and I encountered the same problem. Trying with mvn 2.0.10 I still have the same problem. Building the parent pom pulls in the plugin dependencies. Please advise.
Hide
Permalink
Benjamin Bentmann added a comment -

You misunderstood me. MNG-3106 only fixed the non-determinism of the profile activation that you observe with SR4 vs SR8. In newer Maven versions the profile "box-v4-prebuild", i.e. the one that brings in the plugin dependency, will be activated. Apparently, you don't want this profile activated so either you explicitly disable it via "-P!box-v4-prebuild" on the CLI or you fix your profile activation condition.

Show
Benjamin Bentmann added a comment - You misunderstood me. MNG-3106 only fixed the non-determinism of the profile activation that you observe with SR4 vs SR8. In newer Maven versions the profile "box-v4-prebuild", i.e. the one that brings in the plugin dependency, will be activated. Apparently, you don't want this profile activated so either you explicitly disable it via "-P!box-v4-prebuild" on the CLI or you fix your profile activation condition.
Hide
Permalink
Benjamin Bentmann added a comment - - edited

Why do we see different behaviour between Different JDK vendors?

I repeat: "The activators are looked up from the Plexus container with a non-deterministic order." And before MNG-3106, the activation of a profile was sensitive to the order of the activators. That it works with Maven 2.0.9- and IBM JDK 1.5 SR4 or Sun JDK 1.6 is a mere coincident.

Show
Benjamin Bentmann added a comment - - edited
Why do we see different behaviour between Different JDK vendors?
I repeat: "The activators are looked up from the Plexus container with a non-deterministic order." And before MNG-3106, the activation of a profile was sensitive to the order of the activators. That it works with Maven 2.0.9- and IBM JDK 1.5 SR4 or Sun JDK 1.6 is a mere coincident.
Hide
Permalink
Eric Pabst added a comment - - edited

I posted a fix for MNG-4516 which is related.

Show
Eric Pabst added a comment - - edited I posted a fix for MNG-4516 which is related.
Hide
Permalink
Benson Margulies added a comment -

THe reason for the differing behavior is that Maven uses classes like HashMap which iterate in undefined order, so unless special effort is taken to impose an order, results can vary between implementations. Since this particular order is defined by Maven to be undefined, it's not a defect that this difference occurs. So I think this should be closed as not-a-bug.

Show
Benson Margulies added a comment - THe reason for the differing behavior is that Maven uses classes like HashMap which iterate in undefined order, so unless special effort is taken to impose an order, results can vary between implementations. Since this particular order is defined by Maven to be undefined, it's not a defect that this difference occurs. So I think this should be closed as not-a-bug.
Hide
Permalink
Benson Margulies added a comment -

Behavior is neither incorrect, nor myterious.

Show
Benson Margulies added a comment - Behavior is neither incorrect, nor myterious.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.