[JIRA] [jenkins-test-harness] (JENKINS-35445) Incorrect packaging of Apache HttpComponents in hpi files

[arodrig...@cloudbees.com (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andres Rodriguez started work on  JENKINS-35445 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 

Change By:
 
 Andres Rodriguez 
 
 
 

Status:
 
 Open In Progress 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JIRA] [jenkins-test-harness] (JENKINS-35445) Incorrect packaging of Apache HttpComponents in hpi files

[arodrig...@cloudbees.com (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andres Rodriguez created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-35445 
 
 
 
  Incorrect packaging of Apache HttpComponents in hpi files  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 Andres Rodriguez 
 
 
 

Components:
 

 jenkins-test-harness 
 
 
 

Created:
 

 2016/Jun/07 10:07 PM 
 
 
 

Environment:
 

 New parent POM.  Split JTH 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Andres Rodriguez 
 
 
 
 
 
 
 
 
 
 
When migrating plugins to the new parent POM and the split JTH, one of the most usual issues are incompatibilities between the versions of Apache HttpComponents used by the plugin itself (in many cases indirectly through its dependencies) and the one brought by the HtmlUnit dependency of the JTH. 
Normally some juggling the dependencies orders and scopes saves the day, but we are starting to see cases where a configuration that let compilation and tests (including InjectedTests) run turns out building an hpi file that is not the one intended. 
The fact that Maven 3 (correctly, imho) gets rid of the possibility of having different versions of a dependency in different scopes, also contributes to this situation (meaning that this behavior could have been a workaround in Maven 2). 
E.g., in aws-java-sdk-plugin#3, introducing the version of httpclient needed for the InjectedTests in the test scope (we should not upgrade a dependency of a