Community
Participate
Working Groups
When creating a target environment file and adding the ECF repo [1] to this file, the plugins cannot be resolved. The next step i tried is to add a zip with the same repo to the target definition [2] but this zip cannot be resolved by the target environment either. When inspecting the zip file contents i see it contains pack.gz files and no plain jars. I suspect that p2 is able to process pack.gz files but that the target editor is not able to do so. [1] http://download.eclipse.org/rt/ecf/3.4/site.p2 [2] http://build.ecf-project.org/repo/N-HEAD-sdk.feature/ (this is a zip, download first) for more info see https://bugs.eclipse.org/bugs/show_bug.cgi?id=331536
did you mean for this to be in PDE build or PDE UI? all the target stuff is in PDE UI. As to the actual problem, packed files are not readable by anyone other than unpack200.exe (or equivalent). p2 invokes unpack when it fetches packed files. In theory using a local software site and pointing to packed files *should* result in JARs being added to the PDE bundle pool. Can you provide pointers to the problematic zip? the links in comment 0 either do not work or point to directories.
Thanks for looking at this. > Can you provide pointers to the problematic zip? the links in comment 0 either > do not work or point to directories. http://www.eclipse.org/downloads/download.php?file=/rt/ecf/3.4/org.eclipse.ecf.sdk_3.4.0.v20101029-1626.zip When using the update site in p2 we get no problems. In the mean time we have kept the unpacked jars in the repo and this is not accepted by the Target Editor either. http://download.ecf-project.org/repo/C-HEAD-sdk.feature/lastSuccessful/archive/site.p2/plugins/ Maybe my assumption that it was the pack.gz that caused the problem was faulty. The question remains why can p2 consume the repo and the target editor cannot.
the bug is in your metadata. This another instance of the problem we discussed at the end of Helios. The ECF core feature (for example) says that it includes particular versions of the various ECF bundle but the metadata in your repo specifies in-exact version ranges. If I recall correctly, it is something to do with the ECF build use of a buckminster flag to map versions. As I said at the time, this practice is problematic on several fronts. - Obviously it causes the problem at hand - More fundamentally it introduces a mismatch between the features and their metadata. The feature declares one dependency and the metadata declares another. Feature consumers will be misled by this. The problem shows up in PDE Target land because you are likely using the "slicer" mode (i.e., NOT checking the "Include Required Software" box in the target editor). This directs PDE to essentially follow only exact version requirements. (its not quite as simple as that but it is one of the effects). I can't find the older bug but there is much detail and discussion there. Also, subsequently there has been talk at the planning council to require projects participating in the release train to ensure they have exact version requirements on their software to ensure reproducability etc. In short, you are free to define features that have wider ranges but to be on the train you must (I believe) also have features that have exact versions. In either event your p2 metadata should match the dependencies expressed in the features.
(In reply to comment #3) Yes, you are correct, I use the "slicer" mode. Thanks Jeff, for elaborating. From an end user perspective: I need to build my plugins against a set target. I think that if I, the user, point the target editor to a repo, I want all/most plugins from that repo to be resolved. I understand how delicate this situation is. The resolver just replies and does this correctly, given ECF's metadata. Is it at all possible that the target editor give some hints? "8 out of 25 plugins loaded from this repository" We can fix the problems in the ECF but is this enough?
(In reply to comment #4) > From an end user perspective: I need to build my plugins against a set target. > I think that if I, the user, point the target editor to a repo, I want all/most > plugins from that repo to be resolved. Its an interesting point. For people close to a project this would be true. For the broader community however I suspect that they point to Helios or Indigo or... and get just a small piece of the pie. Having said that, it would be quite easy to create a "repo" container that just adds all of a repo (well, the latest versions) to the target. Perhaps that addresses your usecase? > Is it at all possible that the target editor give some hints? > > "8 out of 25 plugins loaded from this repository" Theoretically sure. The question really is, "what does that mean?" For a small, focussed, self-contained repo it can be useful. For larger contexts however its less clear. For example, in the newest target support (hopefully committed for M4) target resolution is carried out in the context of all repos defined in the target. So you can contribute a repo that has just say one feature and that feature depends on 57 bundles NONE of which are in the same repo. There have been several people looking for this kind of support and it just makes sense given the way p2 works. In that context, which "this repository" would we be reporting against? > We can fix the problems in the ECF but is this enough? Great question. I think we are still evolving the way we deal with target dependency management. A recent set of changes have helped make production and consumption of target elements easier but there is still a ways to go. There are bound to be quite a number of user scenarios and points of view on how it should/could work. Wonder if the PDE team already has some of these in the wiki or somewhere?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
