A work-around for this problem which I've previously mentioned is roughly:
1. Figure out which classes are the problem 2. Figure out which jars contain those classes 3. Figure out which version of those classes you want to keep 4. Extract and re-jar the others "problem" jars minus the offending classes 5. Distribute those updated jars to the rest of your team via Corporate Repo or similar This is perhaps not ideal but it does allow you to "get past" the "problem". If your problem jars are being supplied by a vendor, complain to them and perhaps they will adopt a better policy regarding their Jars. If your problem jars are being supplied by another dev team in your organization, you should be able to get them to change the way they do things or at least provide you with proper bundles that won't give you problems like this. Wayne On 7/26/07, jaxzin <[EMAIL PROTECTED]> wrote:
Thanks Manos, What I've found so far by looking at the source is that its dependent on how the Set that MavenProject.getArtifacts() orders itself. I still haven't found which impl of Set is used. That would tell us how predictable the order is. My guess is its a HashSet and so the order will be determined by the hashCode of the the Artifact object. Brian Manos Batsis wrote: > > > > Come on guys let us not give too much attention to eachother :-) > > I dont think Maven's behaviour regarding the order of JARs in the > classpath is random; that would be impossible. > > My guess is the order is predictable and based on the dependencies > configuration and the algorithm that goes over it. Something like > > 1) Scan explicit deps > 2) (Recursive?) Either > 2.A) For each one add it's deps and move to the next depth level OR > 2.B) Add each one, then process the next depth level of deps > 3) Remove the overridden versions > > This is pretty rough but you get the point. My bet is you will always > get the same classpath in a project whose POM does not change. > > This of course may not provide an easy solution to the OPs prob, but the > code is OS after all so anyone is free to modify it as needed and post > patches in the JIRA or whatever :-) > > Cheers, > > Manos > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Setting-jar-order-in-maven.compile.classpath-tf4111876s177.html#a11811974 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
