Bugzilla – Full Text Bug Listing
| Summary: | PTP would like to join EPP | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Beth Tibbitts <beth> | ||||||||||||||||
| Component: | parallel-package | Assignee: | Project Inbox <epp.packager-inbox> | ||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | P3 | CC: | beth, com-eclipse-dot-org, david_williams, eh.toussaint, g.watson, ian.skerrett, mknauer, nathan, overholt, roland | ||||||||||||||||
| Version: | 1.4.0 | ||||||||||||||||||
| Target Milestone: | 1.4.0 M4 | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Bug Depends on: | 347311 | ||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Beth Tibbitts
(In reply to comment #0) > The Parallel Tools Platform (http://eclipse.org/ptp) would like to have an epp > package for PTP. > We envision it will contain: > 1. cpp package > 2. All ptp features > 3. RSE > Far be it from me to poo-poo anyone's desire to have a package ... they are very handy for fresh installs. But ... the original/main purpose of EPP packages are to satisfy the majority of most popularly desired download requests (sort of an easy entry point, for majority of users, especially new users) [And, least that's my memory, and impression ... others may have other "purpose of EPP"] ... and we could not have a package for every combination of desired functionality. And not that I would know, but my intuition for PTP is that it would not be "frequently requested". Am I wrong? Any rough ideas, say, in proportion to CPP by itself? And, don't get me wrong ... I'm not saying we should not have one ... just that it'd be good to discuss it from several angles. 1. Does CPP already have RSE? I'm just wondering (and, really, just wondering) if it is as all feasible to include PTP with the existing CPP package? How much extra megabytes would that take up? Could PTP functionality be "hidden" by using capabilities, so legacy CPP users don't have to "see" it, if they are not interested? Is PTP for all the same OS Platforms as CPP? 2. I too am interested in "how to create a package" instructions. Perhaps (and, I really do just mean perhaps ... for discussion) we will (eventually) need better abilities for individual projects to provide their own packages, on their own download sites, and not have to put all packages on the main Eclipse downloads page. (We've always talked about having a "secondary" page for less used packages ... rather then just have a growing list of more and more packages on one page ... but, not sure if a decision was made not to, or if just involves extra work no one has signed up for). So, I'm mostly saying there's two needs here at Eclipse ... one is to have packages, for easy installs, and the other is to have the most frequently requested ones at one common site. I'd say 75% of the time they "go together" ... but, not always. Don't let my questions put you off ... I'm just asking for discussion and my own enlightenment. Thanks for suggesting it. (In reply to comment #1) > > 1. Does CPP already have RSE? I'm just wondering (and, really, just wondering) > if it is as all feasible to include PTP with the existing CPP package? How much > extra megabytes would that take up? Could PTP functionality be "hidden" by > using capabilities, so legacy CPP users don't have to "see" it, if they are not > interested? Is PTP for all the same OS Platforms as CPP? Another way of asking the same question, is 'what is the target audience of a ptp package and is it sufficiently different from a C/C++ developer?' Also, could the CPP package create a discovery connector that allows developer to optionally install PTP after the CPP package has been installed? > > 2. I too am interested in "how to create a package" instructions. Perhaps (and, > I really do just mean perhaps ... for discussion) we will (eventually) need > better abilities for individual projects to provide their own packages, on > their own download sites, and not have to put all packages on the main Eclipse > downloads page. (We've always talked about having a "secondary" page for less > used packages ... rather then just have a growing list of more and more > packages on one page ... but, not sure if a decision was made not to, or if > just involves extra work no one has signed up for). So, I'm mostly saying > there's two needs here at Eclipse ... one is to have packages, for easy > installs, and the other is to have the most frequently requested ones at one > common site. I'd say 75% of the time they "go together" ... but, not always. I agree we need to look at the download page, it is getting a bit long. A secondary page is probably the direction we will have to take if we get a lot of new packages. Right now I think we are okay but we are getting close to the limit. I would have no problem with having it on a secondary page. I'd say in the big picture of % of eclipse installs, it belongs there. But installation simplicity is our primary motivation. PTP users, usually highly experienced folks in using traditional command-line tools, are put off by the complexity of the installation. Invariably we run into some dependency glitches in installing in a variety of platforms during a tutorial. We can always tweak and retry to get it to work, but it never makes sense, and it is not a good initial experience for our users. Being part of Helios made it much simpler. But it still needs to be even simpler. The repository (formerly known as update site) management just isn't as simple as it should be, IMHO. We NEED the initial experience to be reliable and simple. (In reply to comment #3) > Being part of Helios made it much simpler. But it still needs to be even > simpler. > The repository (formerly known as update site) management just isn't as simple > as it should be, IMHO. > We NEED the initial experience to be reliable and simple. Have you considered add PTP to the Eclipse Marketplace. Your users could then download one of the existing packages and then install PTP from the Marketplace Client? Some other Eclipse projects, like eGit, are doing this. More information about Marketplace Client is available at http://marketplace.eclipse.org/marketplace-client-intro I don't think a discovery connector would solve our problem, because it would still require additional installation steps. The main issue we have at the moment is that multiple steps required to install PTP. Users want to be able to download a single package and that's it. Anything else is seen as too complicated and they may as well stick with emacs or whatever. Adding PTP to CPP would be possible, but I think you'll find the CDT people would object, even if it was hidden in some way (which also has problems similar to the above). PTP is fairly large so it would increase the download size with no gain for CDT users. I strongly believe there is a need to support EPP packages regardless of the size of the audience. I understand that the current packages are there because of the large numbers of users of those packages, but this should not prevent any project also having one, and it being available for download. This seems to me more an issue of how the downloads page is organized more than anything, so perhaps it needs to be project-based rather than a single list as it is at the moment, or a combination of a single list for heavily used packages, and a separate section for project packages? More detail... We envision it will contain: 1. cpp package 1a. Optional CDT features not in the cpp package, e.g. UPC support 2. All ptp features 2a. This includes RDT - Remote Development Tools - which provides support for many CDT features on a remote project - e.g. hosted, built, and run on a remote large cluster. 2b. This also includes Photran - support for Fortran in Eclipse. 3. RSE (no it's not part of cpp package or CDT) I don't really care where it's hosted - it could be on a specifically PTP download page. I just need a reliable way to build it for all platforms. (In reply to comment #5) > I strongly believe there is a need to support EPP packages regardless of the > size of the audience. I understand that the current packages are there because > of the large numbers of users of those packages, but this should not prevent > any project also having one, and it being available for download. > > This seems to me more an issue of how the downloads page is organized more than > anything, so perhaps it needs to be project-based rather than a single list as > it is at the moment, or a combination of a single list for heavily used > packages, and a separate section for project packages? I agree the main issue is the organization of the download page. Like David, I just wanted to make some suggestions but I fundamentally don't have a problem with you guys having a package. Once we get an idea of how many packages we will have for Indigo we will work on a design for the download page. FWIW, I think any committer should be able to create a package, as long as they agree to test and maintain it. How we organize the download page is a separate issue. So, back to my original question: what do I do next? The config file pointed to on the wiki page at http://wiki.eclipse.org/EPP/Configuration_File_Format has comments "NOT USED ANY MORE" throughout it. Is this still accurate? Where is the config file for CPP? It might help to see that. (In reply to comment #8) > > Is this still accurate? > Where is the config file for CPP? It might help to see that. I don't believe this is still accurate. Markus is the person that can help make this happen. He is already cc on this bug so I will ask him to answer. Any more information available? I would like to get an initial package built next week for M4 if possible. Please advise on how to specify a config file (the CPP file location would be a good start) Well, I'm not Markus :) ... but I can give a little tiny bit of info ... I can point you to the existing package definitions. For each package, there is a feature, and a bundle. The feature is where you define what to include in your package. the bundle is a branding plugin. Naturally, you might try looking at or following the following two as examples: org.eclipse.epp.package.cpp org.eclipse.epp.package.cpp.feature The cvs repository is at :extssh:yourCmmitterId@dev.eclipse.org:/cvsroot/technology And once there, look under the org.eclipse.epp directory, and then navigate to the "packages" directory ... and from there checkout the packages you'd like to look at as examples. That might give you enough info to provide a feature and bundle pair as starting point, which Markus would have to add to the master build set and/or provide more "how to ..." information for projects to construct their own. HTH First, the CVS location for the CPP package is correct: :pserver:anonymous@dev.eclipse.org:/cvsroot/technology Submodule: org.eclipse.epp/packages Projects: org.eclipse.epp.package.cpp org.eclipse.epp.package.cpp.feature Then, yes, the wiki pages need updates and more attention. Maybe the best and most up-to-date information is included in the slides here: http://www.slideshare.net/mknauer23/eclipsecon-2010-eclipse-packaging-project-3528399 Markus, I read your slides and looked at the CPP samples. I have take the cpp two projects and cloned them for PTP. Basically we want all of CPP, plus the UPC features of CPP, plus all of ptp-master (which is all of PTP, where CPP doesn't include *all* of the optional features of CDT), plus RSE. It looks like the other features are included as dependencies instead of included features in the feature.xml of the package feature project. So that's what I did: added more to those that cpp had. I have also subscribed to epp-dev. I've probably forgotten something, but I will attach these two projects to this bug. named org.eclipse.epp.package.parallel and org.eclipse.epp.package.parallel.feature The former I believe is the "branding" plugin (which I haven't changed much from CPP yet) and the latter is the feature that includes all the details of the subprojects we want to include in our package. Let me know what is the next step... when you are likely to try a build for this (or can I?) how I debug the build (optimistic aren't I? :-) ) etc. in the org.eclipse.epp.package.parallel.feature/epp.product file I could not determine what to do for a parallel "product" (it's now org.eclipse.epp.package.cpp.product, from cpp) Do I need to make a "New" one? Created attachment 185096 [details]
initial versions of package projects
Thanks, the two projects are now in CVS. There were some concerns that (a) there could be some overlap between the regular CPP package (or maybe with the Linux Tools package) and (b) we could end up with too many packages on the download page. Regarding (b) I don't think this is going to be a problem. My position was always that the Eclipse Foundation owns the download page eclipse.org/downloads and *chooses* which packages they make available for download from this place. IMO eclipse.org/downloads/packages should be the place where we always list all packages and then there is bug 313887 where I was trying to find an easy way for projects to link to one of the packages. The first one, (a), is a bit more complicated. Ideally the output from PTP could be integrated into these packages, but the main reason for not including it there is probably the size of the contribution. (In reply to comment #13) > Basically we want all of CPP, plus the UPC features of CPP, plus all of > ptp-master (which is all of PTP, where CPP doesn't include *all* of the > optional features of CDT), plus RSE. - I changed/updated some version numbers in your feature.xml; some of them were hard dependencies to a specific build version instead of a match="greaterOrEqual" - I couldn't find any org.eclipse.cdt.bupc feature in the Indigo release (maybe a typo) and added org.eclipse.ptp.pldt.upc instead. Maybe you can review and send me an updated list of the features to include. > Let me know what is the next step... when you are likely to try a build for > this (or can I?) how I debug the build (optimistic aren't I? :-) ) etc. I'll give it a try and let you know on the epp-dev mailing list. > in the org.eclipse.epp.package.parallel.feature/epp.product file I could not > determine what to do for a parallel "product" (it's now > org.eclipse.epp.package.cpp.product, from cpp) Do I need to make a "New" one? I fixed this. You already 'created' one in your branding plug-in. Thanks Markus! org.eclipse.cdt.bupc feature is in CDT but it's not in the cpp package, it's an optional feature only available on the cdt-specific repository at http://download.eclipse.org/tools/cdt/releases/helios. we can live w/o it on an initial try though. org.eclipse.ptp.pldt.upc I meant to include, so thanks for adding it. Next problem... it turns out that the feature org.eclipse.cdt.core.parser.upc.sdk is not in the Indigo staging repository. I am not sure what it is worth for, but I will try another build without this dependency later today because I think that we should have a package available for further discussions, even if it does not yet contain all necessary things. we can live without upc.sdk at least on an initial build. It, like org.eclipse.cdt.bupc, isn't in the indigo build. It's an optional feature only available on teh cdt update site. We'll investigate these later. the org.eclipse.ptp.pldt.upc feature should have been within the big all-inclusive ptp-master feature. Thanks. Here is an initial build based on the M4 Indigo /releases/staging repository: http://build.eclipse.org/technology/epp/epp_build/indigo/download/20101216-1856/ Unfortunately, the only ptp feature included appears to be org.eclipse.ptp.pldt.upc. Created attachment 185365 [details]
feature.xml
Here's a new version of the parallel.feature feature.xml that removes upc and adds a ptp.platform feature. I think this is the right way to do it (at least that's how CDT does it.)
Unfortunately there is no org.eclipse.ptp.platform feature in the Indigo repository. My guess is that it should be org.eclipse.ptp only.
I am going to replace it with
<import feature="org.eclipse.ptp" version="5.0.0" match="greaterOrEqual"/>
and will try again.
With the last change the new Parallel Packages can be build... :) http://build.eclipse.org/technology/epp/epp_build/indigo/download/20101217-0919/ I've got a better build: http://build.eclipse.org/technology/epp/epp_build/indigo/download/20101217-1103/ The older build contained some unreachable dependencies to the initial CPP package which was used as a template for the Parallel Package. Specifically it was linked to the wrong product ID. This build looks a lot better, thanks! Unfortunately, using org.eclipse.ptp includes *every* PTP plugin, which is probably not what we want but is fine for now. I'll add the org.eclipse.ptp.platform feature to the indigo build so we'll be able to use it for M5. While your experiences of "providing a new EPP Package" are fresh in your minds, it'd be great to outline the steps required ... maybe with hints and tips. Doesn't have to be perfect. If you have the time to do even a little, it would help the next new packagers. Good idea, David. I have added an initial addendum to http://wiki.eclipse.org/EPP/How_to_create_a_package since that is where folks will look. Please feel free to expand and correct me. I know Markus made some changes to my initial contribution and he can probably better describe them. (In reply to comment #16) > org.eclipse.cdt.bupc feature is in CDT but it's not in the cpp package, it's an > optional feature only available on the cdt-specific repository at > http://download.eclipse.org/tools/cdt/releases/helios. we can live w/o it on an > initial try though. I've asked that CDT include the BUPC feature in their indigo build so we can include it in ours. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=333052 We're in the process of updating our included features, because what's there now isn't complete. It's missing some Fortran and RDT components. http://dev.eclipse.org/mhonarc/lists/ptp-dev/msg04482.html Markus, is there any way we can do a build ourselves to test our theories? We had thought of introducing new features to bundle other features for the epp, but then thought that this would probably mess up updating, since anyone who didn't install from the bundled-for-epp features would be out of luck. I think the answer is just to list, the very long list, of all the features we want to include. I think this is what CDT did. If we can't build it ourselves can we request a trial build or two well before M6, which is next week? Hi Beth, I am updating the EPP config files, features, etc. to M6 today and will start a test build later today or over the weekend. I haven't done it in the past one or two years, but it should be possible to run a local build on your own machine. In the end it is enough to use the epp.product file in your o.e...parallel.feature project with a well-defined target environment and export it. BUT the problem will be to find an easy way to create the target environment (which is the simultaneous release repository in the EPP build at eclipse.org). I would suggest you ping me and I'll start a new build. Created attachment 191169 [details]
add feature
added org.eclipse.cdt.xlc.feature other features were added via email to markus - they are also included in the above attachment. We are still investigating why the most recent epp build at http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110314-0805/ gives an error when you try to create a remote project. It could be that the above added feature is causing the problem but it shouldn't be. Created attachment 191171 [details]
add linuxtools
this feature adds the linuxtools features to epp-parallel build as well.
While some (most?) parallel users will install the epp-parallel package on linux, not all will,
but we assume their presence will not hinder platforms that don't support them?
* first "add feature" patch (191169): After using this modified feature.xml, the following new feature gets added to the package: org.eclipse.cdt.xlc.feature_6.1.0.201103111317 - a full build is available here http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110315-0811/ * second "add linuxtools" patch (191171): I don't think that this is going to work at all and maybe we need to find another solution if these Linux-only features are required. Since the LinuxTools features are for Linux only, the addition of these features make it impossible to build the package on platforms other than Linux. Therefore I didn't apply this patch so far. * add xlc patch thanks, i should have remembered the cdt.xlc too. * add linuxtools OK, I was afraid of that. We need to rethink. The xlc addition seems to have fixed my remote project creation error. On to more testing... Please add another feature: org.eclipse.ptp.rdt.xlc.feature (In reply to comment #36) > Please add another feature: org.eclipse.ptp.rdt.xlc.feature Couldn't find this one and added org.eclipse.ptp.rdt.xlc instead - I guess that's what you meant anyway. The new build, this time for the PTP packages only, can be found here: http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110315-1600/ (Note: Whenever I am adding a URL - these are pointers to a specific build on the build server and these 'nightly' builds are *not* archived, i.e. they are removed after some days.) we have a problem with epp-parallel. currently looking at it. Try to create a remote project and we get Internal Error: org.eclipse.cdt.managedbuilder.ui.wizards.CfgHolder.getToolChain()Ljava/lang/Object; Trying to see what's missing. I don't think it's anything missing. Turns out we get the error in our M6 build even without epp-parallel. Will try to see if we can fix and respin but not sure... Is there a way to have OS-specific features? Just to keep this bug up to date, We found the M6 problem ( we weren't building with the most recent CDT at the time) and fixed it. Fix is in the epp-parallel build for M6 (but not in the Indigo update site) Via separate emails to Markus I requested adding jGit(done) and jaxb to epp-parallel. FYI Andrew's question about OS-specific features is in reference to our request to include Linux Tools - comment below by Markus on 3/15: (In reply to comment #34) > * second "add linuxtools" patch (191171): > > I don't think that this is going to work at all and maybe we need to find > another solution if these Linux-only features are required. Since the > LinuxTools features are for Linux only, the addition of these features make it > impossible to build the package on platforms other than Linux. Therefore I > didn't apply this patch so far. Please add to epp-parallel build: JAXB for new resource manager infrastructure > javax.xml;bundle-version="1.3.4", > javax.xml.stream;bundle-version="1.0.1", > javax.xml.bind;bundle-version="2.1.9", > com.sun.xml.bind;bundle-version="2.1.9", > javax.activation;bundle-version="1.1.0" >These are all available via Orbit. (In reply to comment #43) > Please add to epp-parallel build: JAXB for new resource manager infrastructure > > > javax.xml;bundle-version="1.3.4", > > javax.xml.stream;bundle-version="1.0.1", > > javax.xml.bind;bundle-version="2.1.9", > > com.sun.xml.bind;bundle-version="2.1.9", > > javax.activation;bundle-version="1.1.0" > > >These are all available via Orbit. Usually all these bundles will be pulled in by p2 if there are dependencies to them. I had a quick look into the last build (20110503-0953) and found them in your package as expected with the exception of com.sun.xml.bind: unzip -l 20110503-0953_eclipse-parallel-indigo-M7-win32.win32.x86_64.zip | grep plugins | grep javax eclipse/plugins/javax.xml_1.3.4.v201005080400.jar eclipse/plugins/javax.xml.stream_1.0.1.v201004272200.jar eclipse/plugins/javax.xml.bind_2.2.0.v201103041518.jar eclipse/plugins/javax.activation_1.1.0.v201005080500.jar What about the missing com.sun.xml.bind bundle? Is it really required? And if yes is the dependency structure correct? (In reply to comment #40) > Is there a way to have OS-specific features? Maybe... but I didn't try this yet. We could try to mark a feature as optional (or pull the installable unit in via the p2.inf file). The feature itself would be platform specific and p2 could install it if and only if the platform filters match. At least that would be my strategy, but I don't know if this has any side effects. (In reply to comment #44) > (In reply to comment #43) > > Please add to epp-parallel build: JAXB for new resource manager infrastructure > > > > > javax.xml;bundle-version="1.3.4", > > > javax.xml.stream;bundle-version="1.0.1", > > > javax.xml.bind;bundle-version="2.1.9", > > > com.sun.xml.bind;bundle-version="2.1.9", > > > javax.activation;bundle-version="1.1.0" > > > > >These are all available via Orbit. > > Usually all these bundles will be pulled in by p2 if there are dependencies to > them. I had a quick look into the last build (20110503-0953) and found them in > your package as expected with the exception of com.sun.xml.bind: > > unzip -l 20110503-0953_eclipse-parallel-indigo-M7-win32.win32.x86_64.zip | grep > plugins | grep javax > eclipse/plugins/javax.xml_1.3.4.v201005080400.jar > eclipse/plugins/javax.xml.stream_1.0.1.v201004272200.jar > eclipse/plugins/javax.xml.bind_2.2.0.v201103041518.jar > eclipse/plugins/javax.activation_1.1.0.v201005080500.jar > > What about the missing com.sun.xml.bind bundle? Is it really required? And if > yes is the dependency structure correct? Yes, com.sun.xml.bind is required. We also now need org.eclipse.jgit;bundle-version="0.12.1" Markus, the jaxb requirements (from Orbit) are now in our M7 build so perhaps it will work. (In reply to comment #47) > Markus, the jaxb requirements (from Orbit) are now in our M7 build so perhaps > it will work. Yepp, that's the way to go. It looks like your change worked, I am now able to find eclipse/plugins/com.sun.xml.bind_2.1.9.v200905260854.jar in the latest build output (I had to restart the build because I introduced another dependency error). "parallel-package" Bugzilla component created in EPP. (Each package has its own component there.) Created attachment 194946 [details]
PTP logo for package download page
Markus, can you put the attached logo on the package download page? Thanks. Nathan, can you upload the attached icon? I've updated the xml file pointing to a new icon URL: iconurl="http://www.eclipse.org/downloads/images/parallel.png" Thanks! Image Uploaded and Linked. Add ptp update site to the repos in discovery
### Eclipse Workspace Patch 1.0
#P org.eclipse.epp.package.parallel.feature
Index: feature.xml
===================================================================
RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel.feature/feature.xml,v
retrieving revision 1.14
diff -u -r1.14 feature.xml
--- feature.xml 3 May 2011 16:32:21 -0000 1.14
+++ feature.xml 18 May 2011 11:32:56 -0000
@@ -17,6 +17,7 @@
<url>
<discovery label="Indigo" url="http://download.eclipse.org/releases/indigo/"/>
<discovery label="Eclipse Platform 3.7" url="http://download.eclipse.org/eclipse/updates/3.7"/>
+ <discovery label="PTP" url="http://download.eclipse.org/tools/ptp/updates/indigo/"/>
</url>
<includes
I would like to add the following features to epp-parallel:
linuxtools.autoconf (I don't think it requires linux, are in git repository)
org.eclipse.linuxtools.cdt.autotools
org.eclipse.linuxtools.cdt.autotools.core
org.eclipse.linuxtools.cdt.autotools.ui
org.eclipse.linuxtools.cdt.autotools-docs
org.eclipse.linuxtools.cdt.autotools-feature probably includes all of the above
(list is from http://www.eclipse.org/linuxtools/projectPages/autotools/, i hope it's up to date)
org.eclipse.cdt.bupc.feature (i think it's now in indigo repo)
"Unified Parallel C Berkeley UPC Toolchain Support"
> linuxtools.autoconf (I don't think it requires linux, are in git repository) Correct, this functionality is OS-agnostic. > org.eclipse.linuxtools.cdt.autotools > org.eclipse.linuxtools.cdt.autotools.core > org.eclipse.linuxtools.cdt.autotools.ui > org.eclipse.linuxtools.cdt.autotools-docs > org.eclipse.linuxtools.cdt.autotools-feature Yes, this last feature should include everything. It's what we use to generate our p2 repository. (In reply to comment #55) > I would like to add the following features to epp-parallel: > > linuxtools.autoconf (I don't think it requires linux, are in git repository) > org.eclipse.linuxtools.cdt.autotools > org.eclipse.linuxtools.cdt.autotools.core > org.eclipse.linuxtools.cdt.autotools.ui > org.eclipse.linuxtools.cdt.autotools-docs > org.eclipse.linuxtools.cdt.autotools-feature probably includes all of the > above > (list is from http://www.eclipse.org/linuxtools/projectPages/autotools/, i > hope it's up to date) > > org.eclipse.cdt.bupc.feature (i think it's now in indigo repo) > "Unified Parallel C Berkeley UPC Toolchain Support" I added <import feature="org.eclipse.linuxtools.cdt.autotools"/> <import feature="org.eclipse.cdt.bupc"/> to the parallel package. It looks like the correct name of the feature does not include the "-feature" at the end of the name, at least this is the only feature that I could find in /releases/staging. (In reply to comment #54) > Add ptp update site to the repos in discovery > > + <discovery label="PTP" > url="http://download.eclipse.org/tools/ptp/updates/indigo/"/> > </url> I added this one as well, but I don't think it will do what you expect. You may have a look into the Java package, they are adding their p2 repository in a p2.inf file (org.eclipse.epp.package.java.feature/p2.inf). That all looks good, thanks Markus. The update site discovery tag -- the existing epp build has tags like that for the other two update sites that DO show up, so that was my guess. We'll see what happens. *** Bug 318513 has been marked as a duplicate of this bug. *** patch to p2.info to preload the PTP update site, modeled after java package per Markus' suggestion.
### Eclipse Workspace Patch 1.0
#P org.eclipse.epp.package.parallel.feature
Index: p2.inf
===================================================================
RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel.feature/p2.inf,v
retrieving revision 1.3
diff -u -r1.3 p2.inf
--- p2.inf 5 May 2011 08:22:01 -0000 1.3
+++ p2.inf 20 May 2011 16:54:29 -0000
@@ -6,3 +6,8 @@
requires.1.name=org.eclipse.platform.ide
#requires.1.range=[3.5.0.I20090522-1710,3.5.0.I20090522-1710]
requires.1.greedy=true
+
+# Preload ptp update site / repository
+instructions.configure=\
+org.eclipse.equinox.p2.touchpoint.eclipse.addRepository(type:0,location:http${#58}//download.eclipse.org/tools/ptp/updates/indigo/,name:PTP);\
+
Preload the perspective switcher bar with Parallel runtime perspective ### Eclipse Workspace Patch 1.0 #P org.eclipse.epp.package.parallel Index: plugin_customization.ini =================================================================== RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel/plugin_customization.ini,v retrieving revision 1.1 diff -u -r1.1 plugin_customization.ini --- plugin_customization.ini 14 Dec 2010 15:30:31 -0000 1.1 +++ plugin_customization.ini 20 May 2011 16:57:55 -0000 @@ -34,4 +34,7 @@ org.eclipse.ui.intro.universal/INTRO_DATA = product:introData.xml # Order help books in table of contents -org.eclipse.help/HELP_DATA = helpData.xml \ No newline at end of file +org.eclipse.help/HELP_DATA = helpData.xml + +# Preload perspective switcher bar +org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=org.eclipse.ptp.ui.PTPRunPerspective \ No newline at end of file Attaching ptp_logo_icon32.png for featureImage in about.ini Created attachment 196239 [details]
Icon for about.ini
icon attached
build.properties patch to add ptp_logo_icon32.png to bin.includes
### Eclipse Workspace Patch 1.0
#P org.eclipse.epp.package.parallel
Index: build.properties
===================================================================
RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel/build.properties,v
retrieving revision 1.4
diff -u -r1.4 build.properties
--- build.properties 5 May 2011 08:22:01 -0000 1.4
+++ build.properties 20 May 2011 18:04:35 -0000
@@ -12,5 +12,6 @@
about.mappings,\
intro-eclipse.png,\
about.ini,\
- about.properties
+ about.properties,\
+ ptp_logo_icon32.png
in about.ini, use featureImage=ptp_logo_icon32.png ### Eclipse Workspace Patch 1.0 #P org.eclipse.epp.package.parallel Index: about.ini =================================================================== RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel/about.ini,v retrieving revision 1.1 diff -u -r1.1 about.ini --- about.ini 14 Dec 2010 15:30:31 -0000 1.1 +++ about.ini 20 May 2011 18:05:38 -0000 @@ -9,7 +9,7 @@ aboutText=%blurb # Property "featureImage" contains path to feature image (32x32) -featureImage=eclipse32.png +featureImage=ptp_logo_icon32.png # Property "windowImage" contains path to window icon (16x16) # needed for primary features only More features to add, please. I think i have the feature IDs correct... Please add more Linux Tools features as follows. These are not specific to Linux. C/C++ Library API Documentation Hover Help org.eclipse.linuxtools.cdt.libhover. ChangeLog Management Tools org.eclipse.linuxtools.changelog GCov Integration org.eclipse.linuxtools.gcov GProf Integration org.eclipse.linuxtools.gprof And XML editor: Eclipse XML Editors and Tools org.eclipse.wst.xml_ui.feature. (In reply to comment #61) > patch to p2.info to preload the PTP update site, modeled after java package per > Markus' suggestion. I've added the new p2 repository, but modified the proposed solution a bit. First, if we configure something in a p2.inf we need to make sure that we unconfigure it when we uninstall the feature. Therefore I added the unconfigure operation as well. The other modification that was necessary: You need to add both, artifact repository and metadata repository; that's why there are always two entries, one with type:0, the other one with type:1. (In reply to comment #62) > Preload the perspective switcher bar with Parallel runtime perspective I added that one. Have you seen the default perspective? Is this something that you need to change? # Property "org.eclipse.ui/defaultPerspectiveId" controls the # perspective that the workbench opens initially org.eclipse.ui/defaultPerspectiveId=org.eclipse.cdt.ui.CPerspective (In reply to comment #64) > Created attachment 196239 [details] Icon copied to org.eclipse.epp.package.parallel (In reply to comment #65) > build.properties patch to add ptp_logo_icon32.png to bin.includes added. (In reply to comment #66) > in about.ini, use featureImage=ptp_logo_icon32.png > +featureImage=ptp_logo_icon32.png done. (In reply to comment #67) > org.eclipse.linuxtools.cdt.libhover > org.eclipse.linuxtools.changelog > org.eclipse.linuxtools.gcov > org.eclipse.linuxtools.gprof > org.eclipse.wst.xml_ui.feature IDs look good. I've added them to the feature.xml. >Have you seen the default perspective?
Yes, CDT perspective is what we want, as it is now.
Thanks Markus!!
Any chance we could get a build to see how these work? (I can't kick one off, can I?)
(In reply to comment #70) > Any chance we could get a build to see how these work? I started a build immediately after I did my changes and updates for RC2 yesterday, but unfortunately there were some "java.io.IOException: No space left on device" on build.eclipse.org. I need to have a look into this first. > (I can't kick one off, can I?) Not yet :( According to his mail on cross-projects, Denis did clean up the /tmp on the build server. I started a new build a few minutes ago (http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110522-0918/ - still running) and the packages are building again. Let's see if the newly introduced dependencies in the Parallel Package can be solved and the packages are building. Please update bundle vendor. Thanks! ### Eclipse Workspace Patch 1.0 #P org.eclipse.epp.package.parallel Index: META-INF/MANIFEST.MF =================================================================== RCS file: /cvsroot/technology/org.eclipse.epp/packages/org.eclipse.epp.package.parallel/META-INF/MANIFEST.MF,v retrieving revision 1.2 diff -u -r1.2 MANIFEST.MF --- META-INF/MANIFEST.MF 3 May 2011 16:32:22 -0000 1.2 +++ META-INF/MANIFEST.MF 23 May 2011 22:30:10 -0000 @@ -3,7 +3,7 @@ Bundle-Name: EPP Parallel Bundle Bundle-SymbolicName: org.eclipse.epp.package.parallel;singleton:=true Bundle-Version: 1.4.0.qualifier -Bundle-Vendor: Eclipse.org - EPP +Bundle-Vendor: Eclipse.org Bundle-RequiredExecutionEnvironment: J2SE-1.5 Require-Bundle: org.eclipse.platform, org.eclipse.equinox.app There was a longer discussion about the Bundle-Vendor string last year, and as far as I can remember it was decided to use either 'Eclipse.org' or something like 'Eclipse.org - EPP' (short form) or 'Eclipse Packaging Project' (long form). Unfortunately I couldn't find a reference on the web, but all EPP bundles are named like that (Eclipse.org - EPP) and I hope you understand that I don't want to change this in a single package. The problem is that it now shows two icons on the "About" page: one for the EPP feature and one for the PTP features. The icons are keyed off the provider name and the image name, so if the provider is different from the other features then the user will see two icons which seems a bit confusing to me. Now I see and understand your problem. See bug 347307 which is my proposed solution. Update: See build http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110531-2005/ where only two out of 6 Parallel Package could be build. The build log tells me that... Missing requirement: EPP Parallel Feature 1.4.0.20110527-1517 (org.eclipse.epp.package.parallel.feature.feature.group 1.4.0.20110527-1517) requires 'org.eclipse.photran.intel.feature.group 0.0.0' but it could not be found On the other hand the Linux packages are looking good, it is only the Windows and MacOSX platform that seems to be in trouble. Is the Photran feature platform specific or only available on Linux? (I haven't had a closer look into the issue, but maybe you already know what's going on. I just wanted to draw your attention to this.) org.eclipse.photran.intel.feature.group (that one feature in Photran) is for Linux... so why has it worked so far? That *is* a good question I am a little bit lost. I checked all *photran* features and tried to find a difference but couldn't find any... photran_7.0.0.201105250903 photran_7.0.0.201105301002 photran.intel_7.0.0.201105250903 photran.intel_7.0.0.201105301002 photran.xlf_7.0.0.201105250903 photran.xlf_7.0.0.201105301002 I checked the EPP feature/plugin org.eclipse.epp.package.parallel, org.eclipse.epp.package.parallel.feature - no change since RC2 that could cause this. Next thing to look into is the p2 metadata. Markus, I have added Jeff Overbey, Photran lead, to this bug cc: list. You could also try building again; we have a new ptp build for rc3 now. (In reply to comment #80) > You could also try building again; we have a new ptp build for rc3 now. Your contribution is not yet available from /releases/staging. indigo.runAggregator is still running in Hudson and there were several unsuccessful builds. A complete new build of the EPP metadata is triggered when David updates /releases/staging - you can see this whenever indigo.epp-repository-build is running. Back to the problem: I've checked everything I can think of, especially the content.jar's. Some <filter>(osgi.os=linux)</filter> look suspicious, but not too different compared to last week. I remember that the Parallel Packages did not build at all last week and I had to re-add your p2 repository http://download.eclipse.org/tools/ptp/updates/indigo to the p2 director call in order to get the build running. At that time the o.e.photran.*.features were not available from /releases/staging but that looks like fixed. Then I tried several things locally... (1) Running a local win32/win32/x86_64 director build with the latest repositories (EPP+/releases/staging+/tools/ptp/updates/indigo); this setup should be similar to last weeks setup but with the updated content (the EPP repository location is only a temporary location!); this p2 director call is expected to create the package in the eclipse/ subdirectory: /path/to/your/eclipse -nosplash -consoleLog -application org.eclipse.equinox.p2.director -m http://download.eclipse.org/releases/staging,http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110601-1916/repository,http://download.eclipse.org/tools/ptp/updates/indigo -a http://download.eclipse.org/releases/staging,http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110601-1916/repository,http://download.eclipse.org/tools/ptp/updates/indigo -installIU epp.package.parallel -destination eclipse -profile epp.package.parallel -flavor tooling -profileproperties org.eclipse.update.install.features=true -bundlepool eclipse -purgeHistory -p2.os win32 -p2.ws win32 -p2.arch x86_64 -roaming -vmargs -Declipse.p2.mirrors=false (2) Running the same build with last weeks RC2 repositories (EPP+/releases/indigo) and the latest PTP repository (/tools/ptp/updates/indigo). (Again, the EPP repository location is only a temporary location, it won't work in a few weeks time!): /path/to/your/eclipse -nosplash -consoleLog -application org.eclipse.equinox.p2.director -m http://download.eclipse.org/releases/indigo,http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110526-1100/repository,http://download.eclipse.org/tools/ptp/updates/indigo -a http://download.eclipse.org/releases/indigo,http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110526-1100/repository,http://download.eclipse.org/tools/ptp/updates/indigo -installIU epp.package.parallel -destination eclipse -profile epp.package.parallel -flavor tooling -profileproperties org.eclipse.update.install.features=true -bundlepool eclipse -purgeHistory -p2.os win32 -p2.ws win32 -p2.arch x86_64 -roaming -vmargs -Declipse.p2.mirrors=false Since both versions did not work I think/hope/guess that the error is not in EPP but in something that has changed in the PTP feature structure. Created attachment 197179 [details] Dependency Change 'Optional' (In reply to comment #78) > so why has it worked so far? That *is* a good question That's the question that I am unable to answer. No idea at all (which is not good). In the meantime I started a Windows on another computer and tried to install the OS specific Photran features on top of a Classic/SDK RC3 download. Of course, this was not possible (which is the expected behaviour since these feature are filtered by p2 but not in the install dialog). The attached patch is already applied to CVS HEAD. It contains a small change of the feature.xml and the p2.inf. I removed both OS specific Photran features from the feature.xml and created the very same information in the p2.inf with one difference: Here I am able to define these features as optional. I've never tested this before and it will be the first EPP package that has a different content on different operating systems, but I am positive that it will be working. Can you please test the latest builds, e.g. the Parallel Package only build http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110601-2046/ - it is important to get some feedback as soon as possible if it looks good on Linux with photran.intel, and on Windows/MacOSX without photran.intel. > - it is important to get some feedback as soon as possible if it looks good on
> Linux with photran.intel, and on Windows/MacOSX without photran.intel.
I'm out of town at the moment and only could get (remote) access to a Linux machine and a Mac, but the Intel compiler support works fine in the latest EPP package (20110602?) for Linux and was omitted, as expected, on Mac. So, everything looks like it's working fine to me.
Jeff
Closing as FIXED. The new Parallel package is available and online with Indigo. Thanks for contributing this new package! |
