Community
Participate
Working Groups
I had a small workspace with just a few java projects in it and and tiny (toy) web-app project. When I opened with M6, I got all the JSF migration info. I'm 99.9% sure I had never done anything with JSF in this workspace or projects, so I think the dialog and webpage were inappropriate and that many non-JSF users will find it confusing (if not down right intrusive). From experience, we've found users dislike it when something in Eclipse happens that was not the result of them choosing to do it. In fact, even if there _is_ migration to do, a much better design is to do it from a menu action, or preference, since even if I do have a JSF project, that may not be the first thing I want to deal with. And, imagine, if everyone did that, there might actually be many such pop-up on startup dialogs ... which users would hate. In JSF's case, since it was in "preview" release, it might be better to just document well that once project is opened with new version, then IF the project is subsequently shared, THEN everyone must migrate. I am assuming there is not harm done if the project is not shared, or if the person does not commit the migrated project to a repository. Thanks.
Hi David, The migration dialog should only appear if a JSFLibraryRegistry.xml file exists in your jsf.core workspace meta-data. You are right, there is a bug if this is happening in a workspace where no one has ever created a JSF Library Registry. The problem is we have moved to a non-backward compatible way of specifying the registry which will necessarily break existing workspaces. The choice we were faced with was either a) hosing our users' existing workspaces without warning them or b) hosing them, telling them and then giving them one chance to back out if they hadn't (as no one does that I know) read the release notes to find out what was happening so they could move back to 1.5 until they are ready. We chose b). To be clear, this is per _workspace_ not per project and it is a forced, irreversible change as soon as the workspace (actually the jsf core plugin) is loaded so it will break the user immediately, without any recourse or warning if this dialog is not launched. Things that used to work will quietly stop for no apparent reason and will stop working if the workspace is reloaded in 1.5 also.
Thinking about what you encountered, perhaps there is a use case that is problematic. In the case where the JSF Library Registry file is present, but is empty. In this case, there is no harm to the user to force a migration quietly since nothing could depend on it anyway. The only issue then becomes that the user won't know that their ws is no longer backward compatible... If we can cover off this case somehow, would that satisfy you?
(In reply to comment #2) > > If we can cover off this case somehow, would that satisfy you? > That'd be better, but ... why can't the old way co-exist until the user explicitly requests it? If that's not possible, how about if it "co-exists" until the first time it's needed? That is, until the first time the user does something with JSF, and _then_ warn them with the dialog, etc. I'm not sure what the change was, or why both forms can not be supported (at least until later, when the user says to migrate), but normally it's very bad to do something irreversible, just because someone starts up Eclipse. And, even though you give them a choice, you have to admit, it's not a much of a choice .... either do not use the new version of eclipse you just installed and maybe have been waiting for, for some new function perhaps unrelated to JSF ... or change your workspace in someway that most users will likely not understand so it doesn't work with old version of Eclipse (and, it's just JSF that doesn't work (right?). While we are on the topic ... will be be a problem next year? If the registry changes again? Is there some better design that should be planned for now? As an alternative design, perhaps you could make a backup version of the registry file, and leave it there in the metadata, automatically migrate their existing one, and then you'd at least have the ability to give instructions that they could "manually" get back to the old version, if they had to. Normally, that would not be very acceptable, but since JST was (only) in preview status, it might be better than the alternative? And, now that I think of it .... why not simply use a new file name for the new version? Which you create first time the registry is used. You'd continue to use that new one, but if someone starts up the workspace with the old version of WTP/JSF, that old file would still be there and be "detected" and used, as usual, by the old version? I realize there'd still be some explaination you'd have to give ... and, perhaps not perfectly compatible (in the back and forth sense of the word) but ... again, still perhaps better than it is.
> why can't the old way co-exist until the user explicitly requests it? > If that's not possible, how about if it "co-exists" until the first time > it's needed? That is, until the first time the user does something with JSF, > and _then_ warn them with the dialog, etc. I'll let Gerry explain the technical details since he understands it much better. > normally it's very bad to do something irreversible, just because someone > starts up Eclipse. And, even though you give them a choice, you have to admit, Agreed, which is why we wanted to at least alert the user that it was happening. > it's not a much of a choice .... either do not use the new version of eclipse > you just installed and maybe have been waiting for, for some new function Well the choice is not quite as stark as that. First, it only affects use of the new version with *existing* workspaces that have JSF libraries defined (although there is this one case we maybe didn't account for properly where the registry is empty). Second, once you confirm you want to proceed, we provide you with instructions to do the manual step to get everything working again. > While we are on the topic ... will be be a problem next year? If the registry > changes again? Is there some better design that should be planned for now? We have started to put the pieces in place to do a better job of this in future. Since there can only be one instance of the registry at a time and the user can change it at will, I'm still not sure how to do a user-driven migration, but we are open to ideas. > As an alternative design, perhaps you could make a backup version of the > registry file, and leave it there in the metadata, automatically migrate their > existing one, and then you'd at least have the ability to give instructions We actually do that already. The problem is that projects will stop working because the classpath will no longer be set up properly. Then they will decide something is off with the new version and try to load the old version and it won't work either (because we've deleted the old registry; the old version will know nothing about the backup). > And, now that I think of it .... why not simply use a new file name for the new > version? Which you create first time the registry is used. You'd continue to > use that new one, but if someone starts up the workspace with the old version > of WTP/JSF, that old file would still be there and be "detected" and used, as That's exactly what we are doing. The problem is how to keep the two files in sync. If they load it in the new version and make some changes, this will only affect the new instance. If they go back to an older version, the settings won't carry back. To avoid this issue, we back up the older version, delete it and then create the new version using a new file name as you have said.
>The problem is how to keep the two files in >sync. If they load it in the new version and make some changes, this will only >affect the new instance. If they go back to an older version, the settings >won't carry back. Is it that they can not be kept in sync? Or, just that it'd take a lot of programming work that we are not willing to invest in? I ask this, since the latter is an acceptable answer when former version was a preview release ... but, once formally released, no more "get out of jail free" cards :) If the old and new should happen to get "out of sync", can a user get in sync, by going through some motions, even if essentially repeating what they'd done before? If so, then I think to document that is sufficient, and no intrusive dialogs needed. (So, in other words, just leave the old file there, with it's old name). Honestly, this whole discussion makes me all the more concerned about how different members of a team can possibly stay "in sync" even in normal conditions, if it's so dependent on workspace saved settings. And teams being in sync is a higher priority requirement than old/new version sync, IMHO. Sounds like a hard problem.
> Honestly, this whole discussion makes me all the more concerned about how > different members of a team can possibly stay "in sync" even in normal The idea is to eliminate the old way of doing it in favor of the new way. The new way takes advantage of the fix to Module Dependencies that allows us to implement this feature using regular JDT classpath containers. With this change I believe that a team can now uses variables in their project build path configuration in order to point to JSF Libraries. This is the standard way to support install-specific dependencies across SCC shared projects in Eclipse, is it not?
(In reply to comment #6) > > With this change I believe that a team can now uses variables in their project > build path configuration in order to point to JSF Libraries. This is the > standard way to support install-specific dependencies across SCC shared > projects in Eclipse, is it not? > Yes, variables/module dependencies on the normal classpath is the way to go. Adding Rob as our classpath container expert, but sounds like all is well moving forward .... now just need to decide what to do for this one time "migration".
I have fixed a bug where the dialog was erroneous launched if an empty version 1 registry was present. In this case, the user is deemed not to be in need of being alerted, since the workspace will function exactly as no before (were no libraries, so there's nothing that depends them that could break).
I am going to mark this as fixed in this week's(4/13) build. I beleive we have the 'correct' level of migration for a pre-tech release feature. Please comment/re-open the bug if you still consider this as an issue.
I (still) think nothing should "pop up" in this case. It is intrusive and there is no great harm in the alternative. I'd recommend just migrating quietly when needed (which, if done right, might not even be when the workbench first starts up, but only later when the registry library was used). Then, leave the old file "in place", so if they do revert to previous version, they would simply be right back to where they were with that old version. And, naturally, provide some brief notes explaining this. Seems so obvious to me, I must be missing something. But, it may also be you are falling prey to see everything from your own point of view (which is normally good :) That pont of view assume's someone with a JSF project is doing lot's of JSF work, and would greatly appreciate all the detailed, customized JSF information presented to them automatically. But, that's seldom the case. Imagine other cases, where someone has hundreds of projects in their workspace, some years and years old, some new, and maybe one or two JSF projects they experimented with briefly 5 or 6 months ago. To those users, this would all be very confusing, intrusive, and give a "first impression" that is negative to all of WTP. On user-demand is best. Quiet second best. Forced, with no alternative but to abandon everything is second or third from the worst :)
(In reply to comment #10) Just to be clear on this point: with the fix documented in #8, you will now *only* see this dialog if you explicitly created a JSF Library Registry using a pre-M6 version of JSF Tools in your workspace. So even if you installed JSF tools in the past, but never really used it you will not see this dialog.
One more clarification: In the current scheme for migration, we migrate the content of the JSF Library registry. However, we don't fix the reference to the library on JSF projects in the workspace. The intent of the dialog is to warn the user to either back off from moving to 2.0 or to manually fix the project references. We had one bug in our implementation that resulted in the dilog being thrown even when you had an empty registry. This has been fixed. With this fix in place, is it still a bad practice to throw the dialog? We are investigating less optimal ways to do this.
> is it still a bad practice to throw the dialog? Yes. In two ways. 1) It is bad practice to do anything on workbench startup. 2) it is bad practice to have a dialog pop-up that is not related to a users actions. Seems to me, in this case, this is just a glorified "read me" item you happen to feel is real important. It also seems, to me, if you left the old file registry file in place ... the old version would continue to work -- so, no great harm is being done. (Sorry if I'm over simplifying).
(In reply to comment #13) > Seems to me, in this case, this is just a glorified "read me" item you happen > to feel is real important. It also seems, to me, if you left the old file > registry file in place ... the old version would continue to work -- so, no > great harm is being done. (Sorry if I'm over simplifying). This is not a glorified readme. Since we are not migrating the project references it is possible for the user to experience a 'silent' failure of a working project that was created in 1.5. We will explore ways to move/remove this dialog.
Fixed for Apr 20 Ibuild. We have withdrawn the migration dialog at startup. The migration of the workspace occurs silently without warning. However, when the user's *projects* are modified in a way that may make them backward incompatible, they are warned. These two cases are: 1) When an old project has new JSF libraries added that are based on classpath containers added to the build path. This is the most dangerous situation since in this case, the project may continue to compile in older versions, but the J2EE module dependencies will not deploy to the runtime. 2) When the contents of a library is modified (add or remove jars). In this case, projects created with the new registry will have their classpath updated immediately, but nothing will happen directly to old projects that are not using the new classpath-based libraries. This new solution has the following benefits: - no dialog will popup unless the user is explicitly working with JSF libraries. - the user will only be warned when projects are being changed, which as it turns out is the main problem in the first place. - existing projects will continue to compile and run in either old or new workspaces, although modifications made in new workspaces will cause backward compatibilty issues, which is when the user will be warned.
Closing in 2.0RC1.
