Community
Participate
Working Groups
The feature org.eclipse.equinox.core.sdk includes the org.eclipse.equinox.console.ssh bundle, and its dependencies org.apache.mina.core and org.apache.sshd.core. However, mina.core and sshd.core depend on slf4j api, and slf4j.api depends on some slf4j implementation. The feature (and the updatesite as well) does not contain bundles for slf4j api and implementation. This causes a p2 install of the feature to fail because of unsatisfied dependencies (slf4j).
I believe in SLF4J API 1.6.4 they removed that dependency from the API to the implementation. An implementation is not actually required.
(In reply to comment #1) > I believe in SLF4J API 1.6.4 they removed that dependency from the API to the > implementation. An implementation is not actually required. This is correct and I suspect if the feature is installed from the juno repository it should "just work" since slf4j API 1.6.4 should be available there. We should consider adding the slf4j API 1.6.4 bundle to the equinox SDK. I am pretty sure we already use it to build against.
There's no hard-and-fast rule that each repository must be "self-contained", but ... seems like equinox should be. (In fact, we probably did not do this in the past, only because we did not have a valid implementation, only a stub, so jumped through hopes to have available at compile time, but not included ... but as previously mentioned, impl is no longer hard requirement, so would likely simplify the build just to include it in Eclipse SDK feature). I'll assume for now this is a "service release candidate", Tom or John let me know if that's "too big a change" for some reason I'm not thinking of.
(In reply to comment #3) > I'll assume for now this is a "service release candidate", Tom or John let me > know if that's "too big a change" for some reason I'm not thinking of. I was thinking this would be a good candidate for SR1.
We should be careful here. I went back to see if 3.7.2 had the same problem. Indeed the bundle is slf4j is not there. But I wonder "is it required"? (back in that version) set up "aggregation editor" to validate the repo and received error that "javax.xml.parsers" was missing: Cannot complete the install because one or more required items could not be found. Missing requirement: Eclipse Content Mechanism 3.4.100.v20110423-0524 (org.eclipse.core.contenttype 3.4.100.v20110423-0524) requires 'package javax.xml.parsers 0.0.0' but it could not be found JavaPackage(javax.xml.parsers) is required by: ValidationSet(37Repo) Contribution(37Repo) MappedRepository(file:///home/files/buildzips/372/) InstallableUnit(org.eclipse.core.runtime.feature.feature.group 1.0.1.R37x_v20110907-7H7KFD6BpeIkWN-XxegWjHnQa9Df) InstallableUnit(org.eclipse.core.runtime 3.7.0.v20110110) InstallableUnit(org.eclipse.core.contenttype 3.4.100.v20110423-0524) And then say the Juno zipped up repo had same problem. So, my point is, there may be more than one thing missing, may depend on VM level, etc.
(In reply to comment #5) > We should be careful here. I went back to see if 3.7.2 had the same problem. > Indeed the bundle is slf4j is not there. But I wonder "is it required"? (back > in that version) set up "aggregation editor" to validate the repo and received > error that "javax.xml.parsers" was missing: > What does "aggregation edition mean? This is rather troubling because that package is available in J2SE 1.4 or later and should be available to install so I suspect this "aggregation editor" is not taking into account the packages available in the execution environment. > > Cannot complete the install because one or more required items could not be > found. > Missing requirement: Eclipse Content Mechanism 3.4.100.v20110423-0524 > (org.eclipse.core.contenttype 3.4.100.v20110423-0524) requires 'package > javax.xml.parsers 0.0.0' but it could not be found > > JavaPackage(javax.xml.parsers) is required by: > ValidationSet(37Repo) > Contribution(37Repo) > MappedRepository(file:///home/files/buildzips/372/) > InstallableUnit(org.eclipse.core.runtime.feature.feature.group > 1.0.1.R37x_v20110907-7H7KFD6BpeIkWN-XxegWjHnQa9Df) > InstallableUnit(org.eclipse.core.runtime 3.7.0.v20110110) > InstallableUnit(org.eclipse.core.contenttype > 3.4.100.v20110423-0524) > > > And then say the Juno zipped up repo had same problem. > > So, my point is, there may be more than one thing missing, may depend on VM > level, etc.
> > What does "aggregation edition mean? This is rather troubling because that > package is available in J2SE 1.4 or later and should be available to install so > I suspect this "aggregation editor" is not taking into account the packages > available in the execution environment. > I'd say that's right. The "aggregator editor" is what we use to validate repositories as we create the common Simultaneous Release (you lead such a sheltered life :) Normally, our repositories (that is, the complete repos, at URLs) contain IUs that "provide" JRE packages. (usually named something like <unit id='a.jre.javase' version='1.6.0' singleton='false'> I guess our zipped up repos do not have them. And that's probably not unusual or expected. My mistake. But, my main point is still valid. What exact use case are we satisfying? What's the "starting point" for installing the Equinox SDK? The Eclipse Platform? Are we talking about installing into a runtime target? Or, installing from some minimal "p2 director app"? And, even, what version of JRE or CDC Foundation. For example, javax.xml.parsers is provided by other packages in Orbit ... so ... off hand ... wasn't sure if that was needed or not. (I know now, not). Perhaps these questions would make no difference to the end result ... but ... I just thought best to have the "requirement" well specified.
As far as I can tell, this should work for 3.8/4.2. The repository at .../updates/3.8/R-3.8-201206081200/ has <unit id='org.slf4j.api' version='1.6.4.v20120130-2120' singleton='false'> I unzipped 3.8.1 platform, and use _only_ the .../updates/3.8 repository (and unchecked the "check other sites" box) and I could install the Equinox Core SDK, and after that had a shiny new org.slf4j.api_1.6.4.v20120130-2120.jar in my plugins. Perhaps this bug was opened based on 3.7 repositories? Or, I'll need more information. Thanks.
Oh, re-reading the title, you are talking about the "zipped up" repo for the Equinox SDK. I'll look at that more. At first glance, though, we create that zip by mirroring the feature, <p2.mirror source="file://${buildRepo}"> <destination kind="metadata" location="file://${featureTemp}" name="@{feature} Repo" format="file://${buildRepo}" /> <destination kind="artifact" location="file://${featureTemp}" name="@{feature} Repo" format="file://${buildRepo}" /> <iu id="${runtimeIU}" version="" /> <iu id="${sdkIU}" version="" /> <slicingOptions platformFilter="true" includeOptional="false" includeNonGreedy="false" followStrict="true" /> </p2.mirror> So ... not sure why it would not be included, if it was _required_. But, I'll check.
Created attachment 222688 [details] patch to add slf4j to equinox sdk feature I think the right solution here, is for the SDK feature to say what it wants to include in its package -- it is basically a "packaging feature" -- so, it can say it also wants slf4j. If this feature was built with a "pure" PDE build, It would give an error during the build, but since this feature is instead "assembled" by a p2.mirror task, it just takes that its told. Sound right?
Tom, this is in rt.equinox.framework so ... up to you (or equinox committer) to decide/apply.
(In reply to comment #11) > Tom, this is in rt.equinox.framework so ... up to you (or equinox committer) > to decide/apply. I think this is correct. I went ahead and released the patch. Thanks David!
I confirmed with 10/24 I build, that the equinox sdk zipped repo can now (with no other repos enabled) install the equinox core sdk. But, I think the fix was also intended to be in Juno SR2, so the fix needs to be cherry-picked back to R3_8_maintenance. (right?)
Lazar, what are your thoughts. Is this critical to get fixed in Juno SR2? I'm not super concerned if the feature is not self contained in Juno.
