RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles
> DTP will pull these plugins in source form from WTP repository and > build them as part of their build. This is similar to how Orbit > plugins are handled. Not to be overly picky on exact wording ... but the techniques of Orbit bundle handling is specifically not to rebuild it (form source or otherwise). It just uses what's already been built, conditioned, and signed. This not only saves build time, but is safer in the sense of making sure such bundles are exactly the same, down to each bit. Then, also similar to Orbit, WTP and DTP would both distribute the bundle, and in most circumstances it would not be reinstalled if either DTP or WTP had already installed it. The other important procedural thing to document is that in cases like this, there will have to be a clear agreement between WTP and DTP that these jointly used bundles would have to be "done" earlier than the normal +2 date, so that DTP could get an "early" version, and be assured that it would be the same as the +2 version. (well ... normally ... unless blocking defect is found or something exceptional). I've started some WTP specific documentation on the bundle consuming techniques, and will be glad to expand it when anyone is ready to start giving it a try or has questions. See http://wiki.eclipse.org/WTP/Build/Consuming_plugins_directly_from_others_builds and feel free to ask questions or open enhancement requests. Thanks, ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
Re: [wtp-dev] How to get (existing) API baseline's?
You need to set up a Baseline project. Under Preferences->PDE->API Tools you point to an eclipse installation that has all of the baseline items. In my case, I downloaded the Java EE package, and added the XSL Tools 0.5 release to it. This set up my baseline, and then I pointed the preference page setting to that installation. Dave David M Williams wrote: For those of you that have started using API Tools, maybe you can explain ... how come I don't have the baselines? I would have thought I'd get them simply by synching up with the projects, but apparently not. Is there something else I am to do? Are they tucked away in some new project? Is there some import/export that I must go through? Description Resource LocationType An API baseline has not been set for the current workspace. org.eclipse.jst.common.project.facet.ui Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xml.xpath.core Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xml.xpath.ui Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.core Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.debug.ui Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.jaxp.debug Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.jaxp.debug.uiUnknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.jaxp.launching Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.launchingUnknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.ui Unknown API Baseline Problem An API baseline has not been set for the current workspace. org.eclipse.wst.xsl.xalanUnknown API Baseline Problem Thanks ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles
Thanks for clarifying, David. That makes a lot more sense than the way I thought it was going to work. :) On a somewhat related subject, I didn’t occur to me to bring this up at the meeting, but does it make sense to put these plugins into WTP Common project rather than Server Tools since they “out-bound pieces”? Just asking. Konstantin Komissarchik | Consulting Member of Technical Staff Phone: +1 425 201 1795 | Mobile: +1 206 898 0611 Oracle Eclipse Tooling 411 108th Ave NE, Suite 2100 | Bellevue, WA 98004 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David M Williams Sent: Wednesday, October 22, 2008 1:24 AM To: wtp-dev@eclipse.org Subject: RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles > DTP will pull these plugins in source form from WTP repository and > build them as part of their build. This is similar to how Orbit > plugins are handled. Not to be overly picky on exact wording ... but the techniques of Orbit bundle handling is specifically not to rebuild it (form source or otherwise). It just uses what's already been built, conditioned, and signed. This not only saves build time, but is safer in the sense of making sure such bundles are exactly the same, down to each bit. Then, also similar to Orbit, WTP and DTP would both distribute the bundle, and in most circumstances it would not be reinstalled if either DTP or WTP had already installed it. The other important procedural thing to document is that in cases like this, there will have to be a clear agreement between WTP and DTP that these jointly used bundles would have to be "done" earlier than the normal +2 date, so that DTP could get an "early" version, and be assured that it would be the same as the +2 version. (well ... normally ... unless blocking defect is found or something exceptional). I've started some WTP specific documentation on the bundle consuming techniques, and will be glad to expand it when anyone is ready to start giving it a try or has questions. See http://wiki.eclipse.org/WTP/Build/Consuming_plugins_directly_from_others_builds and feel free to ask questions or open enhancement requests. Thanks, ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles
> On a somewhat related subject, I didn?t occur to me to bring this up > at the meeting, but does it make sense to put these plugins into WTP > Common project rather than Server Tools since they ?out-bound > pieces?? Just asking. Offhand I don't think so. My concept of projects is that they are based on teams of committers, not so much architecture or "level" or even "re-use by other projects" ... so the code would belong where the team of committers are (small as they are in this case :). Depending on the purpose and vision of where Common Project is headed, I could imagine other outcomes, but that's my view given the way things stand right now. I thought you wanted to dismantle the Common Project? :) ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles
David, I do not believe that your concept of a project lines up with Eclipse Development Process which states that project scope is the primary defining characteristic of a project. So it’s not (or at least it shouldn’t be) about who is working on the feature that determines it’s placement, but rather which project’s scope the feature falls under. I realize that in reality it often goes the other way, but let’s at least acknowledge that that’s due to convenience rather doing what’s “right”. Further, the people involved in this are not all server tools project committers. Depending on how the work is organized, I am sure we are going to see some committer elections take place one way or the other. I don’t see that as a big issue. Having said all that, I did not bring this up to start some sort of a turf war. I don’t view it as a personal goal to pad Common Project with more features. As I’ve stated before, as we learn how to better manage the cost of creating micro-project, we should be able to re-shuffle code around and make do without Common Project. I am not a big fan of projects with vague scopes. I only brought this up to see if placing this code in the Common Project in the short term makes better organizational sense to people involved, especially since this code will have to shut down earlier than the rest of WTP and cannot have any dependencies on anything else in WTP. In the end, it doesn’t matter that much which project code is placed in the near term. For this to be successful in becoming more than just a collaboration between WTP and DTP, this code will without a doubt have to move elsewhere. - Konstantin Konstantin Komissarchik | Consulting Member of Technical Staff Phone: +1 425 201 1795 | Mobile: +1 206 898 0611 Oracle Eclipse Tooling 411 108th Ave NE, Suite 2100 | Bellevue, WA 98004 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David M Williams Sent: Wednesday, October 22, 2008 9:23 AM To: wtp-dev@eclipse.org Subject: RE: [wtp-dev] WTP and DTP collaboration and re-using pre-compiled bundles > On a somewhat related subject, I didn’t occur to me to bring this up > at the meeting, but does it make sense to put these plugins into WTP > Common project rather than Server Tools since they “out-bound > pieces”? Just asking. Offhand I don't think so. My concept of projects is that they are based on teams of committers, not so much architecture or "level" or even "re-use by other projects" ... so the code would belong where the team of committers are (small as they are in this case :). Depending on the purpose and vision of where Common Project is headed, I could imagine other outcomes, but that's my view given the way things stand right now. I thought you wanted to dismantle the Common Project? :) ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
[wtp-dev] Project meta data is out of date for webtools.ejbtools
Kaloyan, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page is not a Phoenix-style page. (projecturl = http://www.eclipse.org) ___ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
