Bug 778351 (SOA-836) - need to add a process to check for duplicate/different jar versions early in the build process
Summary: need to add a process to check for duplicate/different jar versions early in ...
Keywords:
Status: CLOSED WONTFIX
Alias: SOA-836
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: Build Process
Version: 4.3 IR4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: CONTINUING
Assignee: nwallace
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-25 13:44 UTC by trev
Modified: 2011-02-23 10:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-23 10:52:04 UTC
Type: Feature Request


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-836 0 None None None Never

Description trev 2008-09-25 13:44:32 UTC
Date of First Response: 2008-09-25 09:59:52
project_key: SOA

Comment 1 trev 2008-09-25 13:46:58 UTC
need to write something to convert eap jar names  to original names and compare/contrast with those from the other projects used in soa.
need to also identify which jars come from which project

Comment 2 Aleksandar Kostadinov 2008-09-25 13:59:52 UTC
recently we found an issue that jbossall-client.jar has older remoting version than remoting jars we use. So it would be much better if all libs are checked for duplicate classes and if the classes are actually the same thing in all libs.

Obviously client and server classes will show duplicates but the process should check if these are identical as they should.

Comment 3 trev 2008-09-26 08:34:08 UTC
Once Jars are identified we need to  establish why any replacements are being made and identify if there is a real need for them to be replaced.

Comment 4 trev 2009-02-17 15:49:19 UTC
We have new java version of jarCatalog and some other tools to try.

Comment 5 trev 2009-02-17 15:53:08 UTC
Can you check out JarCatalog and dist-diff against the latest EAP version and the version we are using for SOA 4.3 CP01
We need to know whether either are useful tools to identify what has changed between releases or if they generate too many false positives to be useful.

Comment 6 nwallace 2009-02-23 10:52:38 UTC
Dist-diff is useful if you know there are changes. There's too much info to be able to scan through it for unexpected changes. Each new release contains newly bundled jars who's time stamps then change so that just about everything comes up as changed.

Jarcatalog again is useful but not the whole picture in itself. It could be a good root source of info for another procedure but again time stamps are a pain. The only thing that could possible be of use is the size of files in the jars. Now this isn't 100% of course but would be an indicator. So if the procedure to come created an output of jars, files within and sizes, this could then be diff'd one way or another against the next release to flag changes. 

Looking at tattletale next.

Comment 7 nwallace 2009-02-23 14:38:36 UTC
Tattletale. This is similar to Jarcatalog in what it does but with a very pretty display.
It looks to be good for finding duplicate jars and files within but gives nothing that would help with detecting changes.

Comment 8 nwallace 2009-03-03 10:50:25 UTC
Forgot to add that a compare within eclipse gives similar results to dist-diff but at least you can open changed files within the eclipse window. No option to ignore anything like version or time stamp changes.

Comment 9 trev 2011-02-23 10:52:04 UTC
Release Notes Text: Added: for ongoing SOA projects this will be handled as part of the MEAD dependency load



Note You need to log in before you can comment on or make changes to this bug.