| Summary: | need to add a process to check for duplicate/different jar versions early in the build process | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 4 | Reporter: | trev <tkirby> |
| Component: | Build Process | Assignee: | nwallace <nwallace> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.3 IR4 | ||
| Target Milestone: | --- | ||
| Target Release: | CONTINUING | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/SOA-836 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-23 10:52:04 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
trev
2008-09-25 13:44:32 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 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. 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. We have new java version of jarCatalog and some other tools to try. 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. 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. 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. 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. Release Notes Text: Added: for ongoing SOA projects this will be handled as part of the MEAD dependency load |