Bugzilla – Full Text Bug Listing
| Summary: | [publisher] Enable publishing of products and features | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alf_s, bsd, bugs.eclipse.org, curtis.windatt.public, dj.houghton, gregory.amerson, gunnar, hmalphettes, igor, irbull, jan.sievers, jens.glander, john.arthorne, katya.stoycheva, kim.moir, kompiro, krasimir.semerdzhiev, manderse, matthias.gradl, nalinig, pascal, pwebster, s.yousouf, t-oberlies, tjwatson |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 220553, 268895, 275376, 313997, 314002, 314129, 316028, 327705, 327828, 332444, 338148, 352457, 390361 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Jeff McAffer
During the Equinox team call today we had a series of discussions and left off with a semi-concrete suggestion as follows. 0) Create a new bundle in the PDE namespace (e.g, org.eclipse.pde.publishing). This new bundle would host all of the "eclipse-specific" publishing bits required to get products, features, bundles, executables, ... in to a p2 repo. 1) move the *.eclipse packages from p2.publisher to pde.publishing 2) move the pde.build publishing enhancements to pde.publishing. This is a few actions and associated Ant tasks 3) ensure that the pde.publishing dependencies are as clean as possible (though it will likely need to be friends with a number of p2 bundles). 4) merge/fix the function accordingly so that the new setup is directly useful to both PDE Build and others. I did a 5 minute experiment doing 0 and 1 and it seems do-able. There are a few dangling references but most were messages or helper things that can/should move. In talking with Andrew the PDE Build elements should be reasonably cleanly separated as well. #4 will be the tricky part. Since the PDE Build code has seen by far the most use, where possible we should start with it and ensure that it can be used reasonably easily in other contexts. As Jeff mentioned in Comment#0,there are some real bugs (not blocking, but they are annoying). Some of them even have patches attached. I was hoping to get them in M4, but I ran out of time. I will review the patches and release them early in M5 (once we re-open head). Should we start dragging in references the bugs we know is killing us at the moment ? added bug 268895 (product 'includeLaunchers' attribute) to list of dependent bugs. As Ian mentioned, this one has a patch attached. I'd rather not see all high priority p2 bugs referenced here :-) but if they are directly related to enabling p2 publishing of features and products then sure. I figure we can get the big picture and see where to go from there. Couldn't find a way to add "Depends on" issues so writing it here hoping someone can add them the proper way (or tell me how ;) Most of these have to do with p2's publisher not being able to portable build across Linux. Windows and OSX: https://bugs.eclipse.org/bugs/show_bug.cgi?id=313997 https://bugs.eclipse.org/bugs/show_bug.cgi?id=316028 https://bugs.eclipse.org/bugs/show_bug.cgi?id=314129 https://bugs.eclipse.org/bugs/show_bug.cgi?id=314002 and for full disclosure these are rooted in the discussion about https://issues.sonatype.org/browse/TYCHO-520 Thanks Max. I added them to the list. You should be able to do that as well by clicking the "edit" button beside the "Depends on:" list. Consolidation is the way to go, as long as we get the dependencies right - which shouldn't be a problem with OSGi really :-) I can offer to try out prototypes to verify that they work for Tycho. I may also be able to help with the refactoring itself, though someone else needs to set up the collaboration infrastructure. (I only know how to do these things with Git...) As long as the publishing is a component in the p2 project, it can be used for defining various types of units and more fully utilize the wide range of options that p2 offers for provisioning. However, moving publishing closer to what PDE tools currently offer inevitably removes most of these options which is a kind of unexpected. Publishing must serve the tools only as a platform base on which the tools can evolve and extend rather than seeking the opposite effect – tools dictating what publishers are limited to do. Refer to bug 325622 as one example of such a limitation. Also, moving the *.eclipse packages out of the p2.publisher bundle would leave it mostly with a handful of abstractions. In a broader scope, it looks like p2 is not much of a use by its own - even for the basic provisioning of bundles if it has not the support of PDE for publishing bundles (which is also a part of the *.publsiher.eclipse packages). In this sense, what is the ultimate goal to move publisher and PDE packages into one bundle? Are we talking about a routine refactoring to isolate the "Eclipse-specific" functionality or are we aiming at a tighter integration of publishing with the PDE tools ? Secondly, how do you imagine the new bundle's dependencies to look like ? You mention about making them "as clean as possible" and it sounds reasonable. However, adding references to PDE packages will result in the fact that the tools that rely on the current publisher for headless build of repositories will now have to import PDE bundles too. Isn't it backwards incompatible ? (In reply to comment #9) I think there is some miscommunication here. Where this effort/function lives (PDE or p2) is more of an organizational topic than a technical one. In the end, I don't really care one way or the other. The same people can work on it regardless of where it is and the functional requirements (e.g, being reusable in multiple contexts) remain. The key point here is making product and feature publishing more broadly usable. Having said that, I will attempt to clarify some of the points mentioned... > As long as the publishing is a component in the p2 project, it can be used for > defining various types of units and more fully utilize the wide range of > options that p2 offers for provisioning. However, moving publishing closer to > what PDE tools currently offer inevitably removes most of these options which > is a kind of unexpected. Publishing must serve the tools only as a platform > base on which the tools can evolve and extend rather than seeking the opposite > effect – tools dictating what publishers are limited to do. Refer to bug > 325622 as one example of such a limitation. The relationship should be bi-directional. We can add function to the publisher and then seek to have it tooled (e.g., we added the p2.inf independent of any tooling). In other cases the publisher works with existing resources. The .product file is an example of a pre-existing (PDE) resource that we are using as input to the publisher. If we want more flexibility in publisher input, we should either work with the input owners or create our own input formats. > Also, moving the *.eclipse packages out of the p2.publisher bundle would leave > it mostly with a handful of abstractions. In a broader scope, it looks like p2 > is not much of a use by its own - even for the basic provisioning of bundles if > it has not the support of PDE for publishing bundles (which is also a part of > the *.publsiher.eclipse packages). p2 is a generic provisioning platform. I've no problem with the publisher being "not much use on its own". The Eclipse Platform is not much use on its own. RCP is not much use on its own. People add stuff to these platforms to adapt it to their needs. The current main usecase is the management of Eclipse/OSGi bits but that is by no means its limit. In this context building Eclipse-specific bits into the publisher is actually counter to the design principles of p2 -- being a generic provisioning platform. I'm NOT pushing hard for this but pointing out that the idea is not as whacky as it may seem. > Secondly, how do you imagine the new bundle's dependencies to look like ? You > mention about making them "as clean as possible" and it sounds reasonable. > However, adding references to PDE packages will result in the fact that the > tools that rely on the current publisher for headless build of repositories > will now have to import PDE bundles too. Isn't it backwards incompatible ? I believe the refactoring could be done in a backward compatible way. We (as a community) MUST be willing to refactor bundles as new information/uses come to light. We've done it many times in the past and will continue to do it in the future. The key it to design with refactoring in mind. For example, the "Eclipse stuff" in the publisher is, for the most part, in .eclipse packages. Those packages can just move. People using import-package won't even notice. Other steps are needed for people using require-bundle but this is doable. Summary: The refactoring/naming seems to be a distraction from the main goal of this bug. I propose that we shelve that element for now and work to get the functional part of this work done. We can then look at how to result should be structured. Pascal and I have set up an Equinox incubator workarea to facilitate this work. Created attachment 189302 [details]
Added import to resolve compile issue after refactoring
After the move of the package org.eclipse.equinox.p2.publisher.eclipse to the new bundle org.eclipse.pde.publishing, the JAR file containing the super class of BundlesAction missing on the compile classpath. This patch resolves this issue.
This patch is a trivial change and could be applied to HEAD immediately.
Created attachment 189303 [details]
Move helper method to only productive user - patch of projects not in the incubator branch
Within the bundle org.eclipse.equinox.p2.publisher, the method createEclipseIU in org.eclipse.equinox.spi.p2.publisher.PublisherHelper contained the only reference to the *.eclipse packages. This reference has to be removed because it would lead to a circular dependency between o.e.e.p2.publisher and o.e.pde.publishing.
A way to resolve this issue is to move the method to its only productive user in org.eclipse.equinox.p2.updatesite. This is proposed in this patch. The patch could be applied to HEAD immediately.
Note: The moved method is public because org.eclipse.equinox.p2.tests.touchpoint.eclipse.EclipseTouchpointTest also uses it.
We have just committed step 0 and 1 to the incubator branch. Everything works in eclipse (if you additionally apply the two patches), but we were wondering it it will also work in the headless build. The reason is that several p2 bundles import the *.eclipse packages that have been moved to the new bundle org.eclipse.pde.publishing. Is this a problem? Hey Tobias, great to see some progress on this front. I've just not had the time to mess around here. I suggest that we avoid patching head for now until we see the shape of things in the incubator. To make it easy for people to work in the incubator we can either - maintain a consolidated patch to things that are not in the incubator, or - branch those things needing mods and put them in the incubator as well The latter is easier to work with since patches can get stale but then the branch can get stale too. Since we don't have too many changes yet, I suggest just maintaining an easy to apply patch for all non-head things is the way to go. Are you going to look at the following steps as well? (In reply to comment #14) > Since we don't have too many changes yet, I suggest just maintaining an easy to > apply patch for all non-head things is the way to go. I'll provide the consolidated patch once we need more changes ouside the incubator. > Are you going to look at the following steps as well? We've started to consolidate the BrandingIron (effectively by using the PDE version of it), and plan to finish the remainder of step 2 to 4 in the coming two weeks. Contributions and feedback are welcome, but if people are too busy, we'll just see how far we'll get. Btw. if this is helpful to anyone, we could share the Git repository we are using internally to collaborate and to prepare CVS commits. (In reply to comment #15) > Btw. if this is helpful to anyone, we could share the Git repository we are > using internally to collaborate and to prepare CVS commits. That would be useful -- I'm planning to merge in some of my changes today (bug 331721 ) and some other fixes. Whatever make people more productive but please to be aware of the IP requirements. If you are doing a mess of development/collaboration outside eclipse.org infrastructure then submit a patch/commit you have to be careful that you know where all the code is coming from and that everyone has agreed to the right licenses and terms of use etc. For example, N people collaborate in your Git repo then 1 person commits to CVS. How do we reasonably track copyright ownership and contribution (Note: don't say class comments as they are not reliable or processed). (In reply to comment #17) > Whatever make people more productive but please to be aware of the IP > requirements. I realized that as I was eating lunch. > How do we reasonably track > copyright ownership and contribution (Note: don't say class comments as they > are not reliable or processed). That's actually simple: you get the authors from the log of the various commits made since the branch point. In bzr (which can read and write from git repositories) I'd say: $ bzr missing --outgoing http://location/of/original/git/branch I'm sure git must have its own impenetrable equivalent :) (In reply to comment #18) > > How do we reasonably track > > copyright ownership and contribution (Note: don't say class comments as they > > are not reliable or processed). > > That's actually simple: you get the authors from the log of the various commits > made since the branch point. In bzr (which can read and write from git > repositories) I'd say: > > $ bzr missing --outgoing http://location/of/original/git/branch I'm not sure quite how bzr relates here. What I really meant is that when the code gets committed to CVS there will be a particular user that is doing that commit. When we use the standard tools to go and see who contributed to p2 at eclipse.org, that user will show up. If in fact a group of say 5 people contributed to the content that went into CVS, that information is not tracked anywhere in eclipse.org infrastructure. While that may not be tragic, for example, we need to ensure that all 5 of those people have commit rights on the incubator and all the other IP i's and t's are dotted/crossed. Otherwise we'd be doing an end-run around the process. Stepping back from the details, I am completely sympathetic to making this easier. I'm also aware that the amount of change in existing bundles will be relatively small (at least that is the hope in this case) and the overhead of managing the IP issues and getting the existing related committers (Pascal, Ian, Andrew, me, DJ, ...) git-enabled and likely outweighs this benefit. Having said that, if someone wants to manage all the issues by monitoring the IP, getting committers up with git, ... then sure. Note, if you are going to do all that then you may as well make a git repo at eclipse.org for the incubator. I've just committed two changes around the BrandingIron to the incubator that fixes the problems reported in bug 313997 and its dupes. The first change modifies the EquinoxExecutableActionTests to cause full branding to occur, and uses a different launcher name (since things worked fine when the launcher name didn't change). The second change fixes the BrandingIron and EquinoxExecutableAction to correctly handle different launcher names, etc. [There appear to have been some changes made outside of the contents of the incubator that prevent running tests. Specifically some of the EclipseTouchpointTests are looking for org.eclipse.equinox.internal.p2.updatesite.RemoteFeaturesAction#createEclipseIU()?] Committed initial fix for Bug 338148: p2 product publisher does not rewrite important Info.plist values Enhance EquinoxExecutableAction and BrandingIron to set key values in Info.plist for MacOS X products. Specifically this sets CFBundleIdentifier CFBundleVersion CFBundleShortVersionString based on values from the .product file (In reply to comment #21) > Committed initial fix for Bug 338148: p2 product publisher does not rewrite > important Info.plist values One of the last issues I'd like to fix is to find some way to provide an preconfigured Info.plist file for MacOS X products. For those who aren't MacOS X users, the Info.plist is the analogue to Eclipse's plugin.xml. There are specific items that can only be added to the Info.plist for the app to integrate more deeply with the OS (e.g., Services). Currently the only way to do this is either (1) provide a custom version of the org.eclipse.equinox.executable feature, or (2) post-processing after the build. Option (1) seems to work ok, though it's a bit sucky to maintain. Option (2) is a pain with Tycho, and I'm sure with other build systems too. My thoughts were to augment the launcher section in the .product file as follows: <launcher name="Foo"> <macosx plist="path/to/Info.plist" icon="icons/Foo.icns" /> </launcher> When is the incubator code being considered for merge/release into HEAD? Are there any API/cross-bundle changes to consider? (In reply to comment #20) > [There appear to have been some changes made outside of the contents of the > incubator that prevent running tests. To make the tests run, import all non-incubator p2 bundles from CVS (see p2 releng for a plist) and apply the attahced patches. We have continued the consolidation by merging the BrandingIron. More precisely it was no more possible to merge them, but rather we had to use the p2 BrandingIron to not undo Brian's changes. @Brian: Since you seem to be the expert on the BrandingIron, could you please look through the CVS history of the deleted PDE branding iron (org.eclipse.pde.internal.build.BrandingIron) and check if there are more fixes that need to be ported to the p2 BrandingIron? Could you also have a look at the failing Mac-related test PublishingTests.testPublish_Brand_1? [To execute the PDE tests, configure a target platform with a single directory <dir>/eclipse containing an Eclipse SDK. Additionally extract the delta pack to <dir>/deltapack/eclipse.] As Tobias already suggested we'd like to share our internally used Git repository here https://github.com/jglander/eclipse-publisher-refactoring (+ /wiki for project setup) (In reply to comment #24) > @Brian: Since you seem to be the expert on the BrandingIron, could you please > look through the CVS history of the deleted PDE branding iron > (org.eclipse.pde.internal.build.BrandingIron) and check if there are more fixes > that need to be ported to the p2 BrandingIron? Oh dear, I'm not sure I want to be the expert :) The BrandingIron is pretty brittle: it's makes a half-hearted attempt to be independent of the layout of the org.eclipse.equinox.executable feature layout, but doesn't follow through. And I'm not sure I've fixed all the possible case-insensitive filesystem areas. > Could you also have a look at > the failing Mac-related test PublishingTests.testPublish_Brand_1? Thanks for pointing out that failure -- it identified a latent bug. I've committed a patch to the incubator. If it helps, I can attach a diff relative to the github mirror, though it feels weird attaching it to this meta-bug. > [To execute the PDE tests, configure a target platform with a single directory > <dir>/eclipse containing an Eclipse SDK. Additionally extract the delta pack to > <dir>/deltapack/eclipse.] I still have errors in my workspace that prevent me from running all the tests. The errors are from references to classes in org.eclipse.equinox.p2.metadata.generator, which no longer seems to exist. We tried to move the IFeatureRootAdvice implementation from the pde.build ant code to the pde.publishing bundle code, but it didn't work due to the Ant dependencies. Therefore, pde.publishing will not provide an IFeatureRootAdvice implementation in the short term. We'll discuss other options in bug #327828. There isn't a bug for this, but I discovered that there are discrepancies in how different publisher users handle paths within publishing-related artefacts. I think the only real place where this is an issue is with the product publisher, such as icon paths in a .product file.
In my exploration of the issue, I found that there are unfortunately three different ways in how these paths are interpreted (previously posted to the tycho mailing list):
1) Eclipse's product editor interprets these as plugin-relative paths (e.g., treating them as if they were prefixed with "platform:/plugin" [1]).
2) PDE/Build appears to interpret the paths relative to the workspace root (e.g., treating them as if they were prefixed with "platform:/base" [1]).
3) Tycho interprets them as paths in the local filesystem, relative to its current build location set by the tycho-p2-publisher-plugin, which is responsible for publishing the product definition to a p2 repository, uses "${project.build.directory}/products/${product-id}" as its current build location.
I guess PDE/Build somehow translates the product path names to the file system path names.
I'm not sure if there's anything we can really do though, but I thought it should be pointed out.
[1] http://lmap.blogspot.com/2008/03/platform-scheme-uri.html
(In reply to comment #26) > I still have errors in my workspace that prevent me from running all the tests. > The errors are from references to classes in > org.eclipse.equinox.p2.metadata.generator, which no longer seems to exist. The metadata.generator bundle was removed this week. I think there were some compile errors in the tests for a while but they should be good now. Logistically who is over-seeing the merge of this code back into HEAD? Jeff? Pascal? Ian? (please don't say me) Also I'm still wondering when it will happen and if there are any API changes or cross-bundle dependencies. More progress (-: We have just submitted a consolidation of ProductFile and FeatureEntry into the incubator. (In reply to comment #29) > Logistically who is over-seeing the merge of this code back into HEAD? Jeff? > Pascal? Ian? (please don't say me) > > Also I'm still wondering when it will happen and if there are any API changes > or cross-bundle dependencies. I know that the ProductFile class was also changed outside the incubator, so I propose to simply merge the changes into the incubator (I will do that later today) and then the transport should be easy. As far as I know, all changes in the incubator were only in internal packages. We have verified if the x-friends need changes, but other than the things attached as patch, there was nothing. Does this answer the question? (In reply to comment #30) > As far as I know, all changes in the incubator were only in internal packages. > We have verified if the x-friends need changes, but other than the things > attached as patch, there was nothing. Does this answer the question? Yep, thanks. The API freeze is fast approaching and I just want to make sure that we don't introduce any breaking changes to downstream bundles once the code is merged back into the main stream. Created attachment 190799 [details] Changes to projects not in the incubator Unites the previous two patches (see comment #11 and comment #12) into one patch. Minor additional change in copyright notice. The refactoring is finished :-) And just in time for M6 (?) (In reply to comment #1) > 0) Create a new bundle in the PDE namespace (e.g, org.eclipse.pde.publishing). org.eclipse.pde.publishing it is. > 1) move the *.eclipse packages from p2.publisher to pde.publishing Check. Additionally the p2.publisher.compatibility package and the ant tasks were moved. > 2) move the pde.build publishing enhancements to pde.publishing. This is a few > actions and associated Ant tasks The package pde.internal.build.publisher was moved, so re-use of the PDE's publisher actions (GatherBundleAction, ...) should be possible. Moving the corresponding ant tasks would have been too much effort; they are too tangled with pde.build. > 3) ensure that the pde.publishing dependencies are as clean as possible (though > it will likely need to be friends with a number of p2 bundles). All dependencies of pde.publishing are within Equinox. It uses quite a large number of internal packages of Equinox - declaring pde.build a friend of them should be done once the incubator is integrated. > 4) merge/fix the function accordingly so that the new setup is directly useful > to both PDE Build and others. This is probably the major benefit of this refactoring - lots of classes that were forked before are now merged back together: BrandingIron, IconExe, ProductFile, FeatureEntry, Feature, FeatureParser, and URLEntry. Which means that we'll have to fix future issues only once :-) Who will take care of merging the incubator branch back to HEAD? I've applied all changes from HEAD branch also in the incubator branch (which is no effort with our infrastructure), so the merge back to HEAD should be as easy as replacing everything in HEAD with the files from the incubator branch. Okay, we were too late for M6. But could a committer please merge the refactoring branch into HEAD now? I have just merged the last M6 changes from HEAD into the incubator branch, so the incubator only needs to be copied to HEAD. We need to have this integrated into HEAD now, because we need a nightly build in order to integrate the results into Tycho. In case you want to review changes and merges, this might help: https://github.com/jglander/eclipse-publisher-refactoring/network And just in case this wasn't obvious: all PDE and p2 Test also pass in the incubator. From discussions at EclipseCon, I've learned that we cannot trust the PDE build test suite. Therefore we need other ways to make sure that we do not make any functional changes in pde.build at this point in the release train. The only action that could have introduced functional changes was ther merger of forked classes (see comment #33). I have verified that this didn't happen for all merged classes except ProductFile and BrandingIron (because these files have been changed too much for both sides). Therefore we should restore the pde.build copies of ProductFile and BrandingIron, and then merge the incubator into the 3.7 HEAD. @Pascal: Thank you for volunteering for merging the incubator back. I'll let you know when I'm done with restoring the two classes - probably early next week. (In reply to comment #35) > Therefore we should restore the pde.build copies of ProductFile and > BrandingIron, ... Done. > ... and then merge the incubator into the 3.7 HEAD. Pascal, could you please do that now? The remaining changes to PDE build are very low risk. Don't forget the changes outside the incubator (attached as patch). I've just applied all changes from HEAD (up to now) to the incubator, so the merge should be easy. Created attachment 192369 [details]
patch for p2.sdk feature
When you add a source bundle to a feature, you need to update the build.properties for that feature to generate the source bundle.
The current build error ( https://hudson.eclipse.org/hudson/job/eclipse-equinox-test-N/338/consoleText ) is due to a mistake during the merge: the folder org.eclipse.equinox.p2.publisher/src/org/eclipse/equinox/p2/publisher/eclipse should be deleted. The package has been moved to org.eclipse.pde.publishing entirely. I have done the necessary cleanup. On top of that I have renamed the new bundle to be called org.eclipse.equinox.p2.publisher.eclipse Tobias, now that much that the work is done. Could you please close the appropriate bugs. I ran a test build today It failed with /opt/users/hudsonbuild/workspace/eclipse-equinox-test-N/builds/N201104011157/src/plugins/org.eclipse.equinox.p2.publisher/build.xml:341: srcdir "/opt/users/hudsonbuild/workspace/eclipse-equinox-test-N/builds/N201104011157/src/plugins/org.eclipse.equinox.p2.publisher/src_ant" does not exist! Please update the bundle's build.properties to fix this otherwise we'll have another build failure tonight. Ran another test build https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/eclipse-equinox-test-N/340/console /org.eclipse.pde.build_3.6.100.v20110310/scripts/genericTargets.xml:111: Processing inclusion from feature org.eclipse.equinox.p2.extras.feature: Bundle org.eclipse.equinox.p2.directorywatcher_1.0.300.N20110401-1720 failed to resolve.: Unsatisfied import package org.eclipse.equinox.p2.publisher.eclipse_0.0.0. Can you please fix this or we'll have another build failure tonight (In reply to comment #35) > Therefore we should restore the pde.build copies of ProductFile and > BrandingIron, and then merge the incubator into the 3.7 HEAD. I've created a follow-up for removing the two remaining duplicate classes in 3.8: bug 342550. (In reply to comment #39) > Tobias, now that much that the work is done. Could you please close the > appropriate bugs. I'll need help of the Tycho community for this because I don't have a Mac. Tycho still needs to consume the publisher refactorings (see bug 342554). Everything that we wanted to do directly for this bug (e.g. the publisher refactorings, with the exception of a few follow-ups) have been done in 3.7 M7, so we could mark it as RESOLVED FIXED for 3.7 M7.
On the other hand, we could also keep it open until the aim of this bug ("Enable publishing of products and features") has been achieved and all of the (critical) dependencies of the bug have been verified. In that case I would schedule it for 3.8.
I don't have a strong opinion on either option though...
If there is a significant block of work that was released for M7 and we want to call that out, then it makes sense to close this as FIXED with a M7 milestone and open a new bug for the remaining outstanding work. Although from a casual observer's point of view, it does seem strange that there are still 9 open bugs blocking this one from being complete. Keeping it open for now. (In reply to comment #42) > I've created a follow-up for removing the two remaining duplicate classes in > 3.8: bug 342550. The merge of the remaining changes now waits for a pde.build committer. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |