Comment 1 Neil Hauge 2008-06-18 16:37:34 EDT

Trying to reproduce....How are you are getting to that "Product Configuration" dialog using Ganymede?  I thought that "Manage Configuration..." had gone away with p2, but perhaps I just don't know how to access it any longer?  Used to be under Software Updates->Manage Configuration...


I've also verified that this exact feature exists in the wtp-sdk-R-3.0-20080616152118.zip, and appears to be fully valid.

Comment 2 Kit Lo 2008-06-18 19:00:00 EDT

Thanks for the information. I verified that the feature is in wtp-sdk-R-3.0-20080616152118.zip. Please close this bug as INVALID.

Comment 3 David Williams 2008-06-18 20:16:46 EDT

Well ... before we close it ... :) 

I think Kit was running into this issue for a number of reasons, but I think I _might_ see the issue .... 

If you install the SDK, you should just be able to delete the eclipse-link feature, right? Since it's optional? But ... as I looked at this, I'm not sure it is listed as optional in all of the JPT features. (And, there seems to be two SDK features .... not sure why that is, but probably a separate issue). 

And, to see the "Product Configuration" dialog (I think) you can re-enable Classic Update Manager Capabilities in preferences. As you might expect, the error in the dialog doesn't really cause problems all by itself, but an "invalid configuration" can cause problems with future updates. 

So ... should we investigate if eclipse-link needs more "optional" attributes in feature.xml's? 

Comment 4 David Williams 2008-06-18 20:34:32 EDT

Tran, Karen, do you have any insights into this bug and/or if can/should be fixed for 3.0? I think maybe it should, if it is really possible for adopters to result in "invalid configuration" since that then prevents future updates. 

(But, I'm not positive of all the details ... or if I am seeing things right). 

Comment 5 David Williams 2008-06-18 22:13:52 EDT

Created attachment 105368 [details]
patches to make eclipse-link optional

How'd we miss this for so long?

Comment 6 Neil Hauge 2008-06-19 00:50:10 EDT

The EclipseLink feature is optional by being an unreferenced and separate feature.  We discussed this at some point in the past and decided it would be better to just have a separate feature instead of an Included Optional feature (from jpt).  The jpt.sdk feature you are looking at is an assembly feature, which from my knowledge means that it shouldn't be related to what ships, but is rather used for build purposes.

Now that I look at what is shipped, it is indeed there, and this would appear to be the problem.  Tran will have to shed more light on what is going on here, but we should not be shipping this assembly feature (and absolutely not be including anything from eclipselink in a plain jpt feature unless it is purely for build purposes).  I don't think that feature should be in the build output, as it is redundant, although looking at the "correct", non-assembly feature, I notice that the update URL is missing, so it may need some clean-up as well.

For the regular jpt.feature, I don't think we want to "include" the eclipselink.feature at all, since we never wanted it to be an "include" in the first place.

So, I think the correct course of action here is to simply remove this org.eclipse.jpt.sdk feature (not the ...jpt_sdk.feature) file from the build output, as I think this is just wrong.  I'm not sure how it is ending up there in the first place.  We may also need to clean up the correct jpt_sdk.feature feature, at least include the update/discoverly labels.

Comment 7 Neil Hauge 2008-06-19 00:52:28 EDT

Comment on attachment 105368 [details]
patches to make eclipse-link optional

Based on my previous comments, I don't think these changes are necessary.

Comment 8 Neil Hauge 2008-06-19 01:46:51 EDT

I've also verified that the correct feature (jpt_sdk) is what shows up in Software Updates, and as a result, eclipselink support is never pulled in as a dependency.  From what I can tell, the assembly feature isn't causing any update/uninstall related issues.  It seems to be ignored.

Comment 9 David Williams 2008-06-19 02:22:59 EDT

Thanks Neil ... your comments make a lot of sense and sort of explain how we missed this so long ... I suspect this assembly feature to 'slipped in' to the zip recently. 

Long term, we (Tran? :) can fix the build scripts to exclude this feature from the zip file. 

I suspect we should (carefully) remove the feature from the zip files, just so adopters (or end users) do not mistakenly end up with this feature causing an "invalid configuration" which can not be 'updated'. 

Comment 10 David Williams 2008-06-20 12:07:20 EDT

I wrote some scripts and fixed our current SDK zip files in 

http://build.eclipse.org/webtools/committers/wtp-R3.0-R/20080616152118/R-3.0-20080616152118/

BTW, I have stored the script file in 

releng.wtpbuilder\one_time_use_scripts

so other can review if desired, and so they can be there if we need to do
something similar in the future. (The "hard" part is saving the old stuff ... I
did that by adding 'ORIG' to the core name of zips, and their MD5 files ... and
not just tweaking the zip file, but remembering to re-generate the MD5 files
that go with it). 

Kit, Helen, (Tran, Karen?) if you can confirm quickly today, that would be
great, and then I'd like to announce widely since we are changing the contents
of a zip file that in theory some adopters might have picked up already to
"hand construct" their products. [BTW, by "confirm", I mean to make sure I
removed the right (assembly) feature, and that everything else is the same
(using, for example some diff program to compare the original vs. current zip
file) and also to confirm the published MD5 checksum's are valid (that is, that
the checksum of the zip file validates against the published MD5 file]. 

The three zips effected were 

wtp-jpt-sdk-R-3.0-20080616152118.zip
wtp-sdk-noop-R-3.0-20080616152118.zip
wtp-sdk-R-3.0-20080616152118.zip

Which are now "gone" and the new counter parts have a 'a' suffix added. 

wtp-jpt-sdk-R-3.0-20080616152118a.zip
wtp-sdk-noop-R-3.0-20080616152118a.zip
wtp-sdk-R-3.0-20080616152118a.zip

The originals were renamed to 

wtp-jpt-sdk-R-3.0-20080616152118ORIG.zip
wtp-sdk-noop-R-3.0-20080616152118ORIG.zip
wtp-sdk-R-3.0-20080616152118ORIG.zip


PMC members, even though I've "done the work" already, please signify your
approval or dissent [I did save the originals, so could revert if required]. 

I've opened bug 237953 to track the future "releng work" to correctly construct
the zip file in the first place. 

Comment 11 David Williams 2008-06-20 20:30:09 EDT

Kit was verifying the SDK zips are now ok, but as we IM'd about it, discovered that we have the same problem with the non-SDK zips. 

That is, there are two jpt features included in the zips: 
org.eclipse.jpt 
an assembly feature that 'includes' the eclipse link feature, but does not say 'optional' (so, that's the error). 

and there is another 
org.eclipse.jpt.feature 
which does not mention eclipse link. 

So ... guess we should clean that up too, or else those that use the zip files to 'assemble' new products or custom installs could end up with invalid configurations. 

I'll use similar scripts to remove the 
'org.eclipse.jpt' feature as well, from our zips. 

Comment 12 David Williams 2008-06-21 03:07:53 EDT

Ok, now fixed. 

I downloaded all the zips and 
1) confirmed they verify with the MD5 files (that is, to make sure the MD5 files contain the right file names). 
2) diffed each 'a' zip with each 'ORIG' zip and confirmed the only difference was the removal of the invalid feature.