Bugzilla – Full Text Bug Listing
| Summary: | Unable to add dependencies in the manifest editor's Dependencies tab | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Andrew Rootmann <vluki> |
| Component: | tooling | Assignee: | Leo Dos Santos <leo.dos.santos> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | b.kapukaranov, eclipse, glyn.normington, leo.dos.santos, milesparker, mlippert |
| Version: | 3.5.0.M02 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 364573 | ||
|
Description
Andrew Rootmann
This is for the Virgo IDE version: 1.0.0.201202082045-SNAPSHOT Andrew, we are now supporting both the old (3.0.2) and new (3.5) server, but this is brand new. Are you sure you selected the "3.5" server type when defining a new server? Yes, I'm sure. I was able to successfully launch the server after I had the config directory manually created and I only have 3.5.0.M02 version. This issue is easily reproducible. Just create a new EclipseRT Bundle project, open the MANIFEST.MF, click the Add button on the Dependencies tab and observe nothing happening. Next, check the Error Log view to see the exceptions similar to the ones above. OK, it does work for me, and the reason I asked is that the feature is only a few days old. See bug 364573. Assuming that you mean clicking on the "Import Bundle" Add.. It works for me, but in the trivial sense, as aren't actually any bundles for me to import. Where ae you installing the tooling from? Please grab the latest plugin from: https://hudson.eclipse.org/hudson/job/virgo.ide.snapshot/lastSuccessfulBuild/artifact/org.eclipse.virgo.ide.site/target/site/ Miles, I've just downloaded the latest snapshot 1.0.0.201202091812-SNAPSHOT from http://download.eclipse.org/virgo/snapshot/IDE. The behavior is different as compared to the yesterday's snapshot 1.0.0.201202082045-SNAPSHOT. The Add button now works as expected with the original 3.5.0.M02 directory structure - I can now see all packages available on the server in the Package Selection dialog box. However, I still see the same exception in the Eclipse log when I save the manifest after having just added a new import. It doesn't seem to be affecting anything though... Please see in the stack trace how the exception is complaining about not being able to find file "D:\Downloads\virgo-kernel-3.5.0.M02\config\org.eclipse.virgo.repository.properties" Thanks for your help! Andrew java.lang.RuntimeException: Failed to read repository configuration at org.eclipse.virgo.kernel.tools.internal.SystemPackageFilteringRepository.readRepositoryConfiguration(SystemPackageFilteringRepository.java:137) at org.eclipse.virgo.kernel.tools.internal.SystemPackageFilteringRepository.<init>(SystemPackageFilteringRepository.java:95) at org.eclipse.virgo.kernel.tools.DependencyLocator.<init>(DependencyLocator.java:92) at org.eclipse.virgo.kernel.osgi.provisioning.tools.DependencyLocator.<init>(DependencyLocator.java:77) at org.eclipse.virgo.kernel.osgi.provisioning.tools.DependencyLocator20.<init>(DependencyLocator20.java:43) at org.eclipse.virgo.ide.runtime.core.ServerUtils.createDependencyLocator(ServerUtils.java:174) at org.eclipse.virgo.ide.runtime.core.ServerUtils.createDependencyLocator(ServerUtils.java:137) at org.eclipse.virgo.ide.jdt.internal.core.classpath.ServerClasspathContainer.createDependencyLocator(ServerClasspathContainer.java:577) at org.eclipse.virgo.ide.jdt.internal.core.classpath.ServerClasspathContainer.refreshClasspathEntries(ServerClasspathContainer.java:263) at org.eclipse.virgo.ide.jdt.internal.core.util.ClasspathUtils.updateClasspathContainer(ClasspathUtils.java:172) at org.eclipse.virgo.ide.jdt.internal.core.classpath.ServerClasspathContainerUpdateJob.runInWorkspace(ServerClasspathContainerUpdateJob.java:97) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.io.FileNotFoundException: D:\Downloads\virgo-kernel-3.5.0.M02\config\org.eclipse.virgo.repository.properties (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(Unknown Source) at java.io.FileInputStream.<init>(Unknown Source) at org.eclipse.virgo.kernel.tools.internal.SystemPackageFilteringRepository.readRepositoryConfiguration(SystemPackageFilteringRepository.java:132) ... 12 more I'm sorry! I spoke too soon... The bug is still there as originally reported. Despite the risk of causing a lot of confusion and I'll try to explain... I have two Virgo servers configured in my workspace. While testing the latest snapshot I only reverted one of them to the original 3.5.0 directory structure (by removing the "config" directory and leaving only "configuration") while the other server was using the modified directory structure (as described in the original post). Apparently this other server interfered with the repository loading logic hence making the "Add.." button work. I removed all the server configurations, re-created a new one against the original 3.5.0.M02 download directory structure and there it was - the exception was back and the Package selection dialog box would no longer show up... I think this might explain why it worked for Miles... Please make sure you have no servers configured before you try to reproduce the problem. Andrew I've looked at the code and it appears the configuration directory name is hardcoded in org.eclipse.virgo.kernel.tools.internal.SystemPackageFilteringRepository to "config" like so (line 70): private static final String REPOSITORY_CONFIG_PATH = File.separatorChar + "config" + File.separatorChar + "org.eclipse.virgo.repository.properties"; This config path doesn't exists in Virgo 3.5.0 and this causes the FileNotFoundException that makes the Add Import Packages fail. Hope it helps. (In reply to comment #6) > I have two Virgo servers configured in my workspace. While testing the latest > snapshot I only reverted one of them to the original 3.5.0 directory structure > (by removing the "config" directory and leaving only "configuration") while the > other server was using the modified directory structure (as described in the > original post). Apparently this other server interfered with the repository > loading logic hence making the "Add.." button work. OK, that's worrying in itself.. (In reply to comment #7) > I've looked at the code and it appears the configuration directory name is > hardcoded in > org.eclipse.virgo.kernel.tools.internal.SystemPackageFilteringRepository to > "config" like so (line 70): > > private static final String REPOSITORY_CONFIG_PATH = File.separatorChar + > "config" + File.separatorChar + "org.eclipse.virgo.repository.properties"; Thanks for the hint. It looks like that one didn't get updated and that we're going to need to isolate it as well. (I'm going to take a run at consolidating all of these path definitions at some point. OTOH, hopefully the dir structure won't change again anytime soon!) OK, just realized that that code is actually in kernel. Bouncing over to kernel team -- have a look at this one please? I'm not sure why that isn't breaking anything given mismatch with 3.5 dir structure unless perhaps tooling is the only code using that. I could make a fix on the tooling side by creating a new DependencyLocator (we should prob. factor out the _10 stuff anyway) and doing a replace for the config string, but that doesn't seem like the best solution maintenance wise. Ok, there are a few issues happening here. First of all, we're bundling a 2.0 version of the org.eclipse.virgo.kernel.tools jar which has the old config path hard coded to it. We'll need to update this jar, or better yet start consuming it from the Virgo update site. Even then, we'll probably need to have a separate DependencyLocator35 alongside the existing DependencyLocator20 that calls out to the appropriate API depending on whether we're on Virgo 3.5 or pre-3.5. For now I'd say this is a tooling issue, not a kernel issue. There is certainly a kernel bug here as the following code from SystemPackageFilteringRepository (on branch 364571-introduce-nano of the kernel tools repo) shows: private static final String REPOSITORY_CONFIG_PATH = File.separatorChar + "config" + File.separatorChar + "org.eclipse.virgo.repository.properties"; That may not be the whole story, but at least it's a part. (In reply to comment #10) > Ok, there are a few issues happening here. First of all, we're bundling a 2.0 > version of the org.eclipse.virgo.kernel.tools jar which has the old config path > hard coded to it. We'll need to update this jar, or better yet start consuming > it from the Virgo update site. Yep, that's why I've wanted to get those out. See bug 368582 blocked by 369864. But.. > > Even then, we'll probably need to have a separate DependencyLocator35 alongside > the existing DependencyLocator20 that calls out to the appropriate API depending > on whether we're on Virgo 3.5 or pre-3.5. The API is actually the same..see below. But you're right, we'll need to generalize this on the tooling side anyway as there is obviously no reason for the kernel to be supporting both structures! (In reply to comment #11) > private static final String REPOSITORY_CONFIG_PATH = File.separatorChar + > "config" + File.separatorChar + "org.eclipse.virgo.repository.properties"; Yep. Plus.. I can't help but think this might have something to do w/ bug 371064 as there is some interesting server runtime stuff going on there. I'll discuss that one w/ Leo. adapted kernel-tools with commit b150bc6 Thanks. Am I right in thinking that this means that this will be broken for pre 3.5 will now -- that is, I think IDE team still needs to find a way to adapt this for both cases? (In reply to comment #14) > Thanks. Am I right in thinking that this means that this will be broken for pre > 3.5 will now -- that is, I think IDE team still needs to find a way to adapt > this for both cases? I'd thinks so, yes. If we adopt kernel-tools as it is now, we'll be hardcoded to the 3.5 repository paths. Is there a possibilty to keep around a LegacySystemPackageFilteringRepository or a LegacyDependencyLocator in kernel-tools for pre-3.5 installs? I'm going to bounce this over to runtime as they'll need to provide the classes that Leo suggests. Let us know if you guys need more information on this or thin it is somethign we should actually be handling. (In reply to comment #15) > (In reply to comment #14) > > Thanks. Am I right in thinking that this means that this will be broken for pre > > 3.5 will now -- that is, I think IDE team still needs to find a way to adapt > > this for both cases? > > I'd thinks so, yes. If we adopt kernel-tools as it is now, we'll be hardcoded > to the 3.5 repository paths. > > Is there a possibilty to keep around a LegacySystemPackageFilteringRepository > or a LegacyDependencyLocator in kernel-tools for pre-3.5 installs? Yes. Pre35DependencyLocator and Pre35SystemPackageFilteringRepository are provided in kernel-tools commit 34673a9d0e0dceb59c80146d952374e9494587e8. Assigning back to tooling to make use of the facilities in comment 17. Thanks Glyn. I've adopted the latest *kernel.tools.jar and I've pushed a fix to the p2-provisioned branch. http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?h=p2-provisioned&id=1ca1c31d904a81f36fdecb73a08b763e9df0bec0 (In reply to comment #19) > Thanks Glyn. I've adopted the latest *kernel.tools.jar and I've pushed a fix to > the p2-provisioned branch. > http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?h=p2-provisioned&id=1ca1c31d904a81f36fdecb73a08b763e9df0bec0 Leo, are you sure those changes got pushed? I can't see it on build server: https://hudson.eclipse.org/hudson/job/virgo.ide.snapshot/317/changes#detail0 They are in the p2-provisioned branch, you should see the change in the link I posted. Hudson is probably building only against master. I've opened bug 373303: Produce a composite update site for Virgo IDE snapshots. We should have a composite update available before merging p2-provisioned into master, so that we're not introducing more install dependencies for users. (In reply to comment #21) > They are in the p2-provisioned branch, you should see the change in the link I > posted. Hudson is probably building only against master. > > I've opened bug 373303: Produce a composite update site for Virgo IDE > snapshots. We should have a composite update available before merging > p2-provisioned into master, so that we're not introducing more install > dependencies for users. Hmm.. I'm thinking that only people who are bleeding edge users will be going right to the repos, and we should be promoting a milestone or interim until these issues are resolved for the more general users. We've already got all of the Libra dependencies in the Wiki notes. What else would we be adding beyond the other virgo sites? |