Community
Participate
Working Groups
Created attachment 139224 [details] first error Build ID: galileo RC4 Steps To Reproduce: install the Galileo 3.5 RC4 Java EE bundle. Use the New Server dialog and click the "Download Additional server adapters" link. After a while, you'll see adapters you can download. Try the Geronimo or BEA or WebSphere Adapter. You'll get an error (see attached image) Try the GlassFish Java EE adapter. You can go a little bit further, accept the license, but this is failing as well with another error (see image). The site.xml are correct and working with Eclipse 3.4 very well. So it is a regression from Eclipse 3.4. Regressions are P2 I think More information:
Created attachment 139225 [details] similar error for another server adapter
Created attachment 139226 [details] error for the GlassFish Server Adapter
Either MAc OSX or Windows 7: same effect. I could register the Glassfish UC and via this mechanism, get the plugin (even if Eclipse downloaded many other plugins that are not related to the GlassFish Plugin...possibly updates done after RC4?) But the download additional server adapters link in the "new Server" dialog is the main documented way of getting the GlassFish Java EE plugin. So this will impact a lot of our Java EE users.
I think it is an Equinox P2 bug... I google search for "No repository found containing: " and it does not seem to be a new pb...It happened also on 3.4.2 but the descriptions or solutions are not well described. For example https://bugs.eclipse.org/bugs/show_bug.cgi?id=236437 is marked as as fixed, but it does not tell how it was fixed, and in fact is not fixed if I still get this error with 3.5 RC4.
The GlassFish update center is located at https://ajax.dev.java.net/eclipse/site.xml
I'm wondering why this is not priority P1? I'm using Glassfish 2.1 and cannot do any work without changing to another J2EE server -- which I am not about to do this as we have selected Glassfish for our product. I'm not sure this was reported, so I will do so.. this bug appears on Linux, as well -- specifically Ubuntu 9.04. I sure hope you are able to fix this before the Galileo release. Thanks.
remember: the workaround if to declare our update center and get the plugin via this UC. So there is a solution, not nice, but you are not stuck.
(In reply to comment #7) > remember: the workaround if to declare our update center and get the plugin via > this UC. > So there is a solution, not nice, but you are not stuck. > Thanks for the reply, but, I'm sorry, I don't know what you are talking about. Can you please be more specific about what you mean to "declare" an update center, and what is "our update center". Can you please provide specific detail about what needs to be done? Thank you very much.
use the Help menu-->Install new Software... item Click the add..button ang register: ajax https://ajax.dev.java.net/eclipse (see https, not http) Enable this site. Then select it in the combox box, you can now see and download the GlassFish plugin. Eclipse might download additional plugins, this is out of our control. ps: You can/should always use the Eclipse Help system and search for "installing new software". If you do not find the doc good enough there, make sure you file doc bugs. Regarding P1 priority: I do not have the permission to change bug priority. What do you critically need in Galileo that you do not have in Ganymede?...Just curious...
Assigning to Tim for now
Paul - I reproduced this once with GlassFish, and the second and following times I hit the NPE below. In both cases this raised a p2-related question: 1) On the first run, the underlying code obtained a provisioning plan for the 1.0.27 version of the IU com.sun.enterprise.jst.server.sunappsrv.feature.feature.group from https://ajax.dev.java.net/eclipse. The status of the plan was OK, and yet it failed during install with the same error finding com.sun.enterprise.jst.server.sunappsrv.feature listed in the third attachment. What set of circumstances can cause a provisioning plan to be OK but fail to install? I thought (perhaps naively) that the purpose of the plan was to assure general success before attempting install. 2) On subsequent attempts I now receive the following NPE on every install. Should I open up a separate p2 bug? java.lang.NullPointerException at org.eclipse.equinox.internal.p2.touchpoint.eclipse.PublisherUtil.createBundleIU(PublisherUtil.java:27) at org.eclipse.equinox.internal.p2.touchpoint.eclipse.EclipseTouchpoint.prepareIU(EclipseTouchpoint.java:214) at org.eclipse.equinox.internal.p2.touchpoint.eclipse.EclipseTouchpoint.initializeOperand(EclipseTouchpoint.java:176) at org.eclipse.equinox.internal.provisional.p2.engine.Phase.initializeTouchpointParameters(Phase.java:178) at org.eclipse.equinox.internal.provisional.p2.engine.Phase.mainPerform(Phase.java:120) at org.eclipse.equinox.internal.provisional.p2.engine.Phase.perform(Phase.java:72) at org.eclipse.equinox.internal.provisional.p2.engine.PhaseSet.perform(PhaseSet.java:44) at org.eclipse.equinox.internal.provisional.p2.engine.Engine.perform(Engine.java:54) at org.eclipse.wst.server.discovery.internal.model.Extension.install(Extension.java:85) at org.eclipse.wst.server.discovery.ExtensionWizard$3.run(ExtensionWizard.java:124) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
FYI, depending on your timing in testing this, you might get an experimental version of 1.0.28 in which we tried to clean up dependencies in feature.xml as recommended by Tim: <https://glassfishplugins.dev.java.net/source/browse/glassfishplugins/eclipse-support/features/com.sun.enterprise.jst.server.sunappsrv.feature/feature.xml?rev=1.33&r1=1.32&r2=1.33> and cleaned up dependencies in the manifest as recommended by some of the checkers in the eclipse ui: <https://glassfishplugins.dev.java.net/source/browse/glassfishplugins/eclipse-support/plugins/com.sun.enterprise.jst.server.sunappsrv/META-INF/MANIFEST.MF?rev=1.42&r1=1.41&r2=1.42> We pushed to the live site because we couldn't find a way to test updates from the new server wizard unless it was on the live site. But anyway, none of that helped, so we've gone back to 1.0.27 until there is more info from your end.
Thank you. The workaround worked as advertised. The reason I asked for this to be made priority P1 was that I didn't realize there was a workaround -- and an easy one, at that. No need to change the priority. > Regarding P1 priority: I do not have the permission to change bug priority. > What do you critically need in Galileo that you do not have in Ganymede?...Just > curious... >
We've pushed the aforementioned dependency simplifications into a 1.0.28 of the glassfish plugin, but the error is still there. What is the likelihood of this being fixed for 3.5? Is there something that we can do in our plugin to avoid the error?
Please see comment #11. The core issue appears to be that the install fails for the glassfish IU even though the provisioning plan is ok, so I am transferring to the p2 team. Please let me know if this is a p2 bug or in what circumstances a plan is ok but can fail to install.
(In reply to comment #15) > Please see comment #11. The core issue appears to be that the install fails for > the glassfish IU even though the provisioning plan is ok, so I am transferring > to the p2 team. Please let me know if this is a p2 bug or in what circumstances > a plan is ok but can fail to install. > The plan is executed based on meta data. When the plan is calculated it is acting on the plan; removing, updating or installing components. When this takes place, some component may need to be downloaded from the associated artifact repositories. There is no guarantee that a particular artifact is found in one of the repositories. Assuming that the artifact reported missing is actually supposed to be used, then the most likely problem is that it is simply missing from the associated artifact repositories.
same buggy behavior with Eclipse 3.5 and the Jetty Server adapter.
Re: comment #16 - the required IU appears to be in the repository and works via the regular update UI, so it doesn't appear to be a download issue.
There are several different things going on here. First of all, it sounds as if the p2 UI can successfully install these things, so that would imply that it's not a problem with repo itself or the metadata. In the first two screen shots, the error message is flagging a missing requirement. That is, something required by the server adapter is not found. In the first attachment, it cannot find org.eclipse.jst.common.core and in the second attachment, I can't see the missing requirement (need to scroll)... Tim - for those two cases, I think the problem is that either the repositories containing those requirements are not added (or enabled), or that the provisioning context being given to the planner does not include them. One interesting thing to try. Try to install using the p2 UI and uncheck the box that says [ ] Contact all update sites during install to find required software. Do you get the same error? If so, then the problem is that your provisioning context needs to include all registered repos. If the error does not occur in this case, then something more subtle is going on. The third case observed by Tim is different. That is a case where all the metadata was found, but when downloading the artifacts, there was a problem finding them. Since comment #16 indicates that the regular p2 update UI *can* find these artifacts, I would again suspect the provisioning context being created by the wizard. Perhaps the artifact repositories were not filled in properly in the context??
(In reply to comment #11) > 2) On subsequent attempts I now receive the following NPE on every install. > Should I open up a separate p2 bug? This should probably be a separate bug. It looks like something going on in the publisher, so I've cc'ed Ian.
Hi Susan, thanks for the response. I tried this again today, and the glassfish plugins installed fine this time. All of the IUs required are in the same repository so I don't think it was an issue with the context, but since it now works for me I have no way to test the [ ] you suggested. I haven't changed my installation in any way this week and it clearly wasn't a connectivity issue (since it worked from the p2 UI), so I have no idea what caused (or is causing) this problem. Either there is something that was causing p2 problems under certain circumstances and has been "fixed" on the glassfish update site this week, or we're dealing with a very strange problem. On the other topics, I've confirmed that the WAS CE issue is unrelated to this problem. The server adapter in attachment 2 [details] was written for an older version of WTP and its dependency ranges do not support Eclipse 3.4/WTP 3.1, hence the install error. I have also opened bug 281546 for the NPE I hit, although it clearly doesn't happen today.
Tim, can you try again on a fresh installation? I have seen one or two times where it succeeded (about 2 weeks ago), but I just reproduced again and we've had 2 users file bugs about this against glassfish since 3.5 was released, so there are others experiencing this as well.
Confirmed, it failed again on a fresh install. So what causes a p2 provisioning plan status to be OK but fail during install most of the time? It doesn't appear to be either network or repository related.
We hit something very similar to this recently that started failing on 3.5 and had worked previously. Here's what we ran into, maybe it is related to this issue. Since the failure occurred after downloading, we assumed it was an issue with the artifact repository. As it turns out, in our case, the download went just fine, only that in p2 3.5, the conversion of a mock IU to full-fledged IU results in the verification of the profile in that new state. With 3.3 style site.xml sites (which this appears to be), p2 does -not- have the full dependency information for your bundles. What I believe happens is that p2 resolves what metadata you have given it on your site. If the site's feature(s) do not fully list out what it requires, p2 doesn't know to go get it since it can't expand beyond the mock IUs. In our case, we were able to fix the surrounding dependencies to have resolution occur. Workarounds for the site maintainer would be to convert to 3.4/3.5 style sites with content.xml for full-dependency resolution or to expand the top-level features being selected to make sure they list what other features are also required. Not 100% sure this is the same issue but definitely "feels" very similar.
I will try to convert to the new site style, but I need a bit of help: 1) Is there a way to reproduce this without pushing to our live site? For now, it is only reproducible in the Add Server->Download additional server adapters path and therefore requires me to push experiments to the live update site for testing. I would prefer to work in a local/workspace type environment to test. 2) What is the best way to convert to the new style? I tried this: ./eclipse -application org.eclipse.equinox.p2.metadata.generator.EclipseGenerator -updateSite <local on disk path to update site files> That generated content.xml and artifacts.xml on my disk and I can push them to the live site if I knew if they were correct. I suspect they need some modification first. For example, in the top of the file, I have repository name='file:/<path on disk> - metadata' Should I be generating this some other way or editing this file in some way before it is ready?
*** Bug 281734 has been marked as a duplicate of this bug. ***
> 1) Is there a way to reproduce this without pushing to our live site? You should be able to use a different site by adding it on the "Available Software Sites" preference page. 2) What is the best way to convert to the new style? There is some documentation on how to do this here: http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.isv/guide/p2_publisher.html#updatesite_publisher
I today tried to install the GlassFish plugin into Eclipse Galileo, using the advertised workaround (via UC). The version of the plugin was reported as 1.0.29 (but I tried 1.0.28 too, with the same result). What happened is that the install got stuck at 5% and after quite some time gave out the following error (this is for 1.0.28): An error occurred while collecting items to be installed session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect, operand=, action=). No repository found containing: osgi.bundle,com.sun.enterprise.jst.server.sunappsrv,1.0.28 No repository found containing: org.eclipse.update.feature,com.sun.enterprise.jst.server.sunappsrv.feature,1.0.28 Again, this was via UC. Installation via Additional Server Adapters (the normal way of installation) also failed. So, final result, no GlassFish plugin in Eclipse Galileo. Means we are reverting back to Ganymede until this issue has been resolved.
If you installed the sailfin server adapter (that was on our update site for a few days), that is the problem. There was a dependency problem between those, so if you got a version of that, it will mess with your glassfish server adapter updates. We pulled it off the site until we can figure out a solution, but meanwhile, try a new galileo installation with a new workspace and you should be able to install.
This was a fresh Galileo install (I downloaded it this morning and installed from scratch, however not to the default 'eclipse' directory because that's were Ganymede is). I also had to work around the proxy which we use at our company, but that was OK. So, clean install of Galileo, still no GlassFish.
I just tried on my Mac: Fresh Galileo install, fresh workspace, use UC to install GF 1.0.29. It worked, so if it is not working for you, that is different than this p2 bug and you can file it in the glassfishplugins issue tracker: https://glassfishplugins.dev.java.net/issues/ Be sure to include your platform/OS info and any info from your eclipse log file.
*** Bug 283903 has been marked as a duplicate of this bug. ***
The NPE from comment 11 is being tracked in bug 281546 however the remainder of the issues look to me look like they were site specific problems. I'm going to mark NOT_ECLIPSE but please feel free to re-open if you have a specific p2 bug here that we're missing.
reopen as this is related to most/all server adaptors from WTP "Additional server" processing. This processing was and is working for Eclipse 3.4 It is not working in 3.5. I did not see a spec change in site.xml describing the update centers... Please, this is a critical feature exposed in WTP which is not working any more in 3,5.
You're right and thanks ludo for sticking to your guns. This does not look like a site problem. I did some investigation trying to install the Jetty adapter as I'm pretty confident that site is setup correctly. I used -debug and a .options file with the following set: org.eclipse.equinox.p2.engine/engine/debug = true This gives me a view into what the p2 engine is being called with. From this I can see that the provisioning context is set with: metadata repos = URI of the Webtide/Jetty metadata repo artifact repos = [] e.g. default When the artifact repos setting is left blank the default behavior will search all "enabled" repos for the artifacts. Unfortunately when I tried this I noticed that the Jetty repo is marked "disabled". You look at this in the "Available Software Sites" preferences. Net result is we search but don't find the needed Jetty artifacts and the provisioning operation fails during the "collect" phase. If I go into the "Available Software Sites" preferences and explicitly "enable" the Webtide/Jetty site and then go through the install additional server adapters wizard everything works. -- Tim, I'm going to re-assign back to "WTP Server Tools" as we need to do one of two things: 1) Modify the provisioning context we use to add the matching artifact repo when we go to install the server adapter. Susan was suggesting something along these lines in comment 19. 2) Add the artifact repos as "enabled" when we go to add it. One consequence of this approach is that all installs will end up searching the server adapter repos whenever we're looking for artifacts. I'll still follow this to advise on the p2 API side of things. -- For now the best workaround is to use the "Available Software Sites" preferences page to explicitly "enable" a site.
Simon, can you please explain how to do #1? I assume it's changing the provisioning context, but the current context is already created using the URI that contains the IU: provContext = new ProvisioningContext(new URI[] { uri }); i.e. we do a metadata query against a given uri, then create a context that has only that uri.
(In reply to comment #36) > Simon, can you please explain how to do #1? I assume it's changing the > provisioning context, but the current context is already created using the URI > that contains the IU: > provContext = new ProvisioningContext(new URI[] { uri }); > i.e. we do a metadata query against a given uri, then create a context that has > only that uri. provContext = new ProvisioningContext(new URI[] { uri }); provContext.setArtifactRepositories(new URI[] { uri }); - This will create a really restricted provisioning context that can only see metadata and artifacts from the site at "uri". The benefit is that the collect portion of the operation is simple and that we have good control over exactly what can/will get installed. I think it might still be worth considering setting both the metadata and artifact repo for the selected adapter site "enabled" just prior to doing an install as this will allow p2 to detect availability of updates in the future. That might be 3.2 thing though instead of 3.1.1.
jfyi u still can install the appserv manually visit https://glassfishplugins.dev.java.net/download/index.html just until the bux's fixed.. regards...
Change suggested by Simon released to both WTP 3.1.1 and 3.2 builds. I haven't put this bug into FIXED state yet because I'm still testing, and uneasy since I was never able to reproduce failure 100% of the time. If anyone else is willing and able to test as well, please grab any recent 3.1.1 or 3.2 build from the WTP committers build page (http://build.eclipse.org/webtools/committers/) and report updates here.
Is there a way to update a 3.5 galileo installation with this fix via software updates? If so, please specify the update site and details of what should be installed and I'll test it.
Sorry, daily builds are not posted via update manager - only the zips are available for now.
*** Bug 282731 has been marked as a duplicate of this bug. ***
All my testing worked, so I am marking as resolved. Changes are available in current 3.1.1 and 3.2 builds (on committer download page). 3.2 I-build has been promoted to public download page already, next 3.1M build posted will also have the change.
I tried the GlassFish adapter in the 3.2 I-build and it worked for me.
*** Bug 286754 has been marked as a duplicate of this bug. ***
(In reply to comment #43) > All my testing worked, so I am marking as resolved. Changes are available in > current 3.1.1 and 3.2 builds (on committer download page). 3.2 I-build has been > promoted to public download page already, next 3.1M build posted will also have > the change. Hi, I just installed the IDE for Java EE Developers version 1.2.0.20090621-0820. It says that it has the Eclipse platform 3.5.0.I20090611-1540, but I am getting the same problem trying to get the GlassFish Server Adapter. For the date of the Eclipse platform I suppose its older than the solution u announce here as OK, but for the number of the release 3.1 to 3.5 does not sounds ok to me. Can you tell me what can I do?, am I making a mistake? Tks ...
yep, you have the old eclipse... Either use a candidate build ( http://www.eclipse.org/epp/download.php ) or wait for tomorrow's delivery of 3.5.1 20090621 is jun 2009. You need a september 200909xx build.
Install is working with 3.5.1, but update is not. I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=291822 for the new case.
Closing old bugs.
New Gerrit change created: https://git.eclipse.org/r/108800
New Gerrit change created: https://git.eclipse.org/r/108799
