[jboss-jira] [JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated

[Geoffrey De Smet (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965103#comment-12965103 ] 

Geoffrey De Smet edited comment on DROOLS-471 at 5/2/14 9:34 AM:
-----------------------------------------------------------------

Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar. For example, you can't deploy a war that contains weld to JBoss EAP, because EAP already has weld and it doesn't accept wars that include it too.

Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:

- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.

But if an issue does slip through and wasn't detected, don't blame the guy trying to improve our deps, blame the lack of arq tests.


was (Author: ge0ffrey):
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:

- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.

But if an issue does slip through and wasn't detected, don't blame the guy trying to improve our deps, blame the lack of arq tests.

> Remove repository jboss-deprecated
> ----------------------------------
>
>                 Key: DROOLS-471
>                 URL: https://issues.jboss.org/browse/DROOLS-471
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.1.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
>      <repository>
>       <id>jboss-deprecated</id>
>       <name>JBoss Deprecated</name>
>       <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
>       <releases>
>         <enabled>true</enabled>
>         <updatePolicy>never</updatePolicy>
>       </releases>
>       <snapshots>
>         <enabled>false</enabled>
>       </snapshots>
>     </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.xml#L88
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)