You assumed wrong. I think there is always a chance that we, the platform, or some adopters, _might_ end up putting the new javax.servlet 2.6 in the IDE stack. Hence, you should be sure to test that scenario, and probably widen your ranges. If it works with either level, fine, If it doesn't, then that's when you'll need to decide what's best ... remove option if the required pre-req isn't there, or fix the code so it works with either.
I also think you should probably use "import package" if possible, instead of "require bundle", if you don't already, to be consistent and to drag in as few assumptions as possible. On the general issue of _us_ including these runtime bundles in our features, I've decided that no, we should not. See bug 278469 [1] for a long discussions on why this is a bad thing to do. I mentioned the reasons in the status call yesterday ... but mostly comes down to that if something does not purposely contribute to the IDE, it should not be included in the IDE package, and most "runtimes" do not contribute to the IDE. Some exceptions, as mentioned in status call, might be: A. There may be some part of our code that depend on, say, a parser function that we re-use from a bundle that just happens to be part of a runtime package. In these cases, its ok to depend on it and maybe even re-ship it, but we'd want to make that coupling as loose, and small, and optional as possible. We probably would not need the _whole_ runtime for that one parser function. B. "preview", as in our preview server, or wysiwyg editor preview page. Again, while these are "IDE" functions, (sort of) we'd want to minimize assumptions and have very loose assumptions and not re-ship a runtime in IDE. And hopefully just work with whatever happened to be there. So ... let's add smoke tests where we test with the the newer versions added to the IDE, in case someone does that, but we in WTP won't plan on shiping them. If any of us find some specific function can not be implemented without them, we can re-discuss at that time. The ideal is that we "get" any runtime function based on what runtime is associated with a project, or target environment, and not what happens to be in the IDE stack. Hope that's clear. Feel free to discuss further, but this is my current understanding of best design practices. And adding new dependencies or features or bundles to our distribution is a very big deal, might impact adopters and users, so it not something I want to do "just in case". Let's at least wait and see if there's some specific problem or function where we need them. Thanks, [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278469 From: Angel Vera <[email protected]> To: "General discussion of project-wide or architectural issues." <[email protected]> Cc: [email protected], [email protected] Date: 04/01/2010 03:52 PM Subject: Re: [wtp-dev] Who needs javax.servlet.jsp 2.1? Sent by: [email protected] David, I wanted to bring up that the preview server, has a direct plugin dependancy on javax.servlet and we are currently setting the requirements as [2.5, 2.6). I didn't see javax.servlet being mentioned anywhere directly, so I am still in doubt whether there is an impact here or not. But I am assuming no at this point. Best Regards, -- -- Mr. Angel Vera Server Tools Developer E-Mail: [email protected] Tel: 905-413-5919 ----- Those who think that something is impossible, should not interfere with those who are willing to do it. - Angel Vera From: David M Williams <[email protected]> To: [email protected] Date: 03/31/2010 09:12 PM Subject: [wtp-dev] Who needs javax.servlet.jsp 2.1? Sent by: [email protected] Anyone? If so, there's a few issues to work out and test, etc. 1. The bundle in orbit was "split up" from what 2.0 used to be. So to "get it all" we'll need to get several new bundles. For details, see http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg01739.html I'll need you experts (Nitin?, Raghu?) to tell me what you need (all? none?) 2. Currently we get javax.servlet.jsp "for free" from the platform, and do not reship it, per se. I do not think the platform plans to move up to 2.1, so we'd have to reship. So, we've have to figure out which feature should include it ... jsp? jsf? both? 3. more/new CQs should be open to be sure we document all uses of all related bundles. 4. I think some of our bundles use "require bundle" and some "import package". We should all "import package", I believe. I don't think we can change anything this week, but I'll soon promoted an Orbit I-build, so developers can get the bundles to experiment/test if that helps with any of the above decisions. Thanks, _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
