| Summary: | [Build] Update/remove version dependency of o.a.log4j | ||
|---|---|---|---|
| Product: | [Technology] SWTBot | Reporter: | Miles Parker <milesparker> |
| Component: | Build | Assignee: | Project Inbox <swtbot-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | lorenzo.bettini, mariot.chauvin, mistria |
| Version: | unspecified | ||
| Target Milestone: | 2.1.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Miles Parker
Hi Miles, Correct me if I am wrong but the current version range "[1.2.13, 1.3.0)" means SWTBot is compatible with o.a.log4j package from including 1.2.13 to excluding 1.3.0. So if Xtext has set an explicit dependency to 1.2.15 package it should works. For the importance of explicit version dependencies see bug 286527 and bug 326379. Yes, this whole thing is sort of a build nightmare without a good solution. The issue is that somehow the explicit dependencies that work ok at build time get hard-wired at provisioning time. I don't know for sure that this will cause an issue, but just based on past experience. Would it be possible to set it to 1.2.15? If not, perhaps we should coordinate/discuss on cross-project list. Here is some context.. http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05052.html http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05022.html Miles, I understand your dismay about debugging dependencies problems, but sorry I don't see why we should update to 1.2.15 and how it will solve your problem. Could you provide us all the warnings you get in order to identify the root of the problem ? Sure thing. BTW, This isn't an issue for me at the moment / yet. I'm really just sharing it because it might come up on Indigo build and syncing up the Orbit dependencies. But now I'm thinking that you guys aren't in Indigo, in which case it won't matter as much. These issues don't usually come into play until provisioning. So if there is some reason to keep w/ 1.2.13 for now, don't worry about it. WARNING [0009] : Component request org.apache.log4j:osgi.bundle/[1.2.15.v201005080500,1.2.15.v201005080500] is inconflict with request org.apache.log4j:osgi.bundle/[1.2.13.v200903072027,1.2.13.v200903072027] WARNING [0049] : Component request org.apache.log4j.source:osgi.bundle/[1.2.15.v201005080500,1.2.15.v201005080500](&(buckminster.download.source=true)(!(eclipse.p2.optional=false))) is inconflict with request org.apache.log4j.source:osgi.bundle/[1.2.13.v200903072027,1.2.13.v200903072027](&(buckminster.download.source=true)(!(eclipse.p2.optional=false))) I'm experiencing the same problem when building an Xtext DSL where the tests use Swtbot which has a wired fixed dependency on org.apache.log4j 1.2.13 (and not >= 1.2.13)... the problem comes up when resolving source bundles and orbit repository provides org.apache.log4j 1.2.13 as binary but not as source (only org.apache.log4j 1.2.15 as source)... Here is a CQ requesting usage of log4j 1.2.15 for SWTBot: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7320 Although I would tend to think that the issue is more on your side (why does your build require SWTBot source? log4j source? Couldn't you use bundles -with version range in dependencies- rather than feature...), I think it shows that "includes" dependencies could be replaced by "imports" and it doesn't cost much to ship a log4j 1.2.15 by default. Here is a suggested change that should ease integrations: https://git.eclipse.org/r/13424 The suggested change was merged and result is available on snapshot site http://download.eclipse.org/technology/swtbot/snapshots |