Community
Participate
Working Groups
The "jst" prefix in the id of the Java Facet is a WTP-specific designation. In order to make the Java Facet more portable, the facet needs to be renamed. The plan is to rename it from "jst.java" to just "java". In order to assure backwards compatibility with projects created with prior versions of WTP, an aliasing system will be created such that anyone attempting to resolve "jst.java" facet will resolve the renamed "java" facet. This change should be completely invisible to users and largely invisible to downstream plugins. The only way that this change could impact downstream plugins is if they are comparing the id of project facet returned by getProjectFacet call to the value that was passed in (a very unlikely scenario) or if they are reading the project metadata file directly (also rather unlikely and not supported). Note that compatibility is only in one direction. If the user creates a project in Helios and then opens it in Galileo or earlier, they will get errors in the problems view regarding an unrecognized facet. If this ends up being problematic for any adopter, we can issue a patch for Galileo that does reverse aliasing.
(In reply to comment #0) > ... In > order to make the Java Facet more portable, the facet needs to be renamed. How does this make it more portable? Sounds to me like its an internal arbitrary ID ... maybe named to match the namespace of the plugin that it is in? (Which is a common convention, usually desirable convention? But, keep in mind who's asking :) ... I'm just asking in general for my education ... I've little knowledge of facets or their IDs. Sounds like the project-compatibility issue is complicated, so just wondering what the pay off is for that extra work. Sorry if "its obvious", but appreciate the education. Thanks,
The portability that I am referring to is in the sense that Java Facet is moving out of WTP in the near future and it would be good to future-proof project metadata going forward. The new facet id is chosen such that as the facet implementation jumps from WTP to fproj to possibly JDT, there is no further impact on user's project metadata. This changes goes along with Bug 298906, which is more urgent. It makes sense to make both of these changes concurrently.
Are there any details on the upcoming "aliasing system"? Is there a bugzilla for that as well? Is it going to be a specific to the java facet or a "global" system all facett owners could use for their facets as well?
Can you post more information on the aliasing system and the scope of the aliasing? Does the aliasing system resolve on the extension point level as well? For example, if an adopter currently define my runtime to support the java facet, does the adopter continue to reference the jst.java facet on their extension point? Is there any reason why we want to future-proof it now? Given that the current java facet is still in WTP, it make sense to continue to use jst.java for the time being. When it is being moved out to WTP, a new prefix may get introduced to reflect the corresponding component. If we make the change now, the id may get changed again in the future.
More information about the aliasing system can be found in this bugzilla entry: Aliasing system is needed for facet id and facet version https://bugs.eclipse.org/bugs/show_bug.cgi?id=298974
> Can you post more information on the aliasing system and the scope of the > aliasing? Sure. See Comment #5. > Does the aliasing system resolve on the extension point level as well? Yes it does. > For example, if an adopter currently define my runtime to support the > java facet, does the adopter continue to reference the jst.java facet on their > extension point? The adopter can choose to continue to reference it as jst.java or switch to just java. Either reference will work. For instance, there are numerous references to the java facet throughout WTP and none of them need to be changed as part of this change. > Is there any reason why we want to future-proof it now? Given that the current > java facet is still in WTP, it make sense to continue to use jst.java for the > time being. When it is being moved out to WTP, a new prefix may get introduced > to reflect the corresponding component. If we make the change now, the id may > get changed again in the future. I think I answered this in Comment #3 in response to a similar question from David.
(In reply to comment #0) > The "jst" prefix in the id of the Java Facet is a WTP-specific designation. In > order to make the Java Facet more portable, the facet needs to be renamed. The > plan is to rename it from "jst.java" to just "java". > > In order to assure backwards compatibility with projects created with prior > versions of WTP, an aliasing system will be created such that anyone attempting > to resolve "jst.java" facet will resolve the renamed "java" facet. This change > should be completely invisible to users and largely invisible to downstream > plugins. The only way that this change could impact downstream plugins is if > they are comparing the id of project facet returned by getProjectFacet call to > the value that was passed in (a very unlikely scenario) or if they are reading > the project metadata file directly (also rather unlikely and not supported). > > Note that compatibility is only in one direction. If the user creates a project > in Helios and then opens it in Galileo or earlier, they will get errors in the > problems view regarding an unrecognized facet. If this ends up being > problematic for any adopter, we can issue a patch for Galileo that does reverse > aliasing. We do have an issue with backward compatibility, as our adopting products require sharing projects between older versions. Would it be possible to allow adopters to continue creating the java facet with the old alias? Especially in the Helios release? Scanning through our code, we would need to change several places where this facet name is referenced.
> We do have an issue with backward compatibility, as our adopting products > require sharing projects between older versions. The best way to handle this situation is to issue a patch to Galileo that does reverse aliasing. That would be a fairly straightforward task. > Would it be possible to allow adopters to continue creating the java facet with > the old alias? Especially in the Helios release? The complexity of such selective behavior is well in excess of what it would take to prepare a reverse aliasing patch or even a series of patches. > Scanning through our code, we would need to change several places where this > facet name is referenced. Could you be more specific? Unless you are doing string comparison on ids stashed in your code with what's returned by framework API, you will not have to change a thing. I am testing these changes right now and haven't had to touch any part of WTP besides the java facet implementation.
Created attachment 155462 [details] Combined Patch v1 The attached patch contains combined work on this item as well as a few other related changes to the Java facet that have been announced. Feel free to review and give it a try. What I'd like to do is release these changes after this week's integration build as that will give these changes broader exposure and will let us flush out any problems sooner. I have tried project creation use cases and WAR import wizard. The framework unit tests all pass for me locally. I'd like to run Java EE unit tests locally, but it's been years since I've been able to achieve that feat. Will likely have to wait for build results on that. Let me know if there are other scenarios you'd like me to try.
Created attachment 155463 [details] Combined Patch v1 Previous patch was a partial for some reason.
Per our agreement at last week's team call, I have waiting through Tuesday of this week for technical comments on this patch from Chuck's team. Having received no comments, I proceeded to release these changes to 3.2 M5 code stream and fproj. With the change more easily accessible to a broader community, we move to the next phase of testing. Regarding compatibility patches for prior releases... If any adopter (or any other community member) requires such a patch, please make a formal request by opening a bug (one per code line). You can assign it to me directly. Chuck, As I was releasing these changes, I noticed that there was a mess of unreleased changes in wst.common.modulecore. I had no choice but to release them along with mine as I do know if there is a way to partially release changes in one project. Could you guys take a look and make sure that all JEE team's changes have been released for this week's integration build?
