Community
Participate
Working Groups
As I was building a patch for M6 for Bug 340175, I ran into a blocking issue. It looks like during recent refacturing of Dali features, some common plugins were assigned to several features instead of creating a common feature. In particular, plugin org.eclipse.jpt.common.ui is owned by both org.eclipse.jpt.jpa.feature and org.eclipse.jpt.jaxb.feature features. There are probably other similar examples. This arrangement has potential to create a number of problems as p2, pde, and pde build aren't setup to handle this will. The problem that I ran into is that the "feature patch" construct can patch one feature at a time, but in this case two features must be patched to patch a single plugin. Creating two separate feature patches doesn't work as p2 tries to install them one at a time and fails. To resolve this, a common feature should be created such that other features can reference the common feature instead of the individual plugins. In the end only one feature should ever own a given plugin. Note that the common feature does not need to be "categorized" in the repository. It can be left to install implicitly via user installing features that represent concrete features.
I guess I was being naive in thinking I could structure the Dali features in this way. Also patching would be inconvenient as you mention. We will add the Dali Common feature and make sure it does not get categorized.
To elaborate on my previous comment, we will need to add the following features: -org.eclipse.jpt.common.feature -org.eclipse.jpt.common_sdk.feature -org.eclipse.jpt.common.eclipselink.feature -org.eclipse.jpt.common.eclipselink_sdk.feature -org.eclipse.jpt.common.tests.feature Feature dependencies in existing features will need to be updated include the common feature and remove existing reference to "common" plugins. When this work has been completed I think Java EE package will need to be updated to grab the new features. I will enter a bug against the Java EE package for this.
!ENTRY org.eclipse.equinox.p2.director.app 4 0 2011-04-05 04:44:45.534 !MESSAGE The installable unit org.eclipse.jpt.common_sdk.feature.feature.group has not been found. David, I am not sure what I missed here. I have added org.eclipse.jpt.common_sdk.feature to the wtpFeatureIUs list, and I updated category.xml in components/dali-sdk Thanks. http://build.eclipse.org/webtools/committers/wtp-R3.3.0-I/20110405014410/I-3.3.0-20110405014410/
From looking in the "raw" repository, built during the build, I don't see any of the "common" ones in /I-3.3.0-20110405014410/buildrepository/dali-sdk/features Off hand, this makes it sounds like they are never built. Never "included" (by either the assembly feature, or some other feature ... if you want the "real" features to merely "require" it (a good thing), then it must be "included" by the assembly feature. Right? Or am I seeing something wrong. (I've only taken the briefest look -- and am not completely in synch). It still appears some 'common' plugins are listed in compile logs, so someone is including those ... could that indicate a "release" problem? ... in either case, not sure how the features are getting included?
PMC review needed as this is a change to the Dali features in M7. See initial bug comments as justification for the change.
(In reply to comment #4) > Off hand, this makes it sounds like they are never built. Never "included" (by > either the assembly feature, or some other feature ... if you want the "real" > features to merely "require" it (a good thing), then it must be "included" by > the assembly feature. Right? Or am I seeing something wrong. (I've only taken > the briefest look -- and am not completely in synch). > > It still appears some 'common' plugins are listed in compile logs, so someone > is including those ... could that indicate a "release" problem? ... in either > case, not sure how the features are getting included? I have verified that the common features was included in the assembly feature, and referenced from the other features. I have forced releasing of assembly and common features.
I'm fine with this, sounds important to avoid "double patches". I will remind you, though, when you provide patch for JEE IDE package feature to remember to provide similar one for the "Reporting Package" feature ... as part of their package just duplicates ours.
> I have verified that the common features was included in the assembly feature, I see that now ... I didn't have HEAD version loaded. > I have forced releasing of assembly > and common features. That should help, I see according to history, the previous version of dali.map had org.eclipse.jpt.assembly.feature=v201103020000 which was "old" version of assembly feature should work better now that is has org.eclipse.jpt.assembly.feature=v201104050000 But (or, is it "and") the latest build broke with No repository found at http://download.eclipse.org/rt/eclipselink/nightly-updates/2.3.0.v20110326-r9173/.. I think Neil told me ... and I forgot ... but, you all have a plan to move off "nightly" eclipselink builds, right?
(In reply to comment #8) Oops, I was intending to update the EclipseLink repositories yesterday but I saw that the build from the weekend was not clean, and I know that we are expecting new functionalities. I decided to wait on last night build, but it looks like it is not clean either, so I have updated to 03/31 build. Can you restart the build, or it about to fail anyway. Thanks.
closer ... latest failure said "The installable unit org.eclipse.jpt.common.tests.feature.feature.group has not been found." It appears that one is being built, but not included in dali.tests/category.xml file so it not mirrored to final distribution repos.
(In reply to comment #10) Thanks David, I've just committed the changes. It may still go in the current build since it just started 25 minutes ago.
It seems that the falling tests are due to a glitch, you can restart the build at your convenience.
The last build failure is due to an attempt to remove the jpt common features from the list of installable features from the repository. I have reverted the previous changes until we find a solution.
(In reply to comment #13) > ... until we find a solution. Who's we? :) There's a few levels to consider. One, the "mirror scripts" at the end of the build use the categories to select what to mirror. That was done as a short-cut, since before discovering that, we had to maintain yet-another-list of exactly what we wanted mirrored (which was error prone). So, there is a number of way sot solve that ... just a matter of programming. But, also, I've never been quiet sure of what to list in category or not. We (obviously) have way too much already, but without some "meta-package" (or, perhaps "sub-category") implementation, not sure how simple we could make it. Again, both are "doable", if someone had the time/ability. Last, I'm not sure how to "patch" an install, if the feature is not there. If someone does net explicitly install "common.jpt", then would they be out of luck to install a patch? Of course, it's pretty hard to patch "every installation" anyway, since it depends so much on how they installed it. So, perhaps we just wouldn't worry about that up front? IMHO, having the "extra" common.jpt there along with so many other "extra" things isn't all that bad. Not sure what effort it'd be worth to fix. That is, the way it is, someone pretty much as to "select everything" anyway, to make 100% sure they get everything ... kind of hard to tell from our current feature names and lists. HTH (sorry I didn't mention it early)
If someone does not explicitly install a feature, but they do install a feature that requires it, the feature does get installed whether or not it has been "categorized". It just needs to be available in the repository. Patching works whether or not a feature was installed "explicitly". The rule of thumb for categorizing features is that you only want to categorize features that represent functionality that repository consumer may reasonably want to install explicitly (aka by itself). This generally rules out "common" features that contain re-usable code, but don't in themselves represent end-point functionality. > the "mirror scripts" at the end of the build use the categories to select > what to mirror. This sounds like a pretty big problem as it takes away the ability of component producers to use categorization for what it was intended for.
I should have clarified Tran's comments yesterday, but what we are looking to do, as Konstantin points out, is to not categorize the Dali Common features (as is done with many other features in WTP - WST Common Core / UI as an example.) The features should be installable and mirrored, etc. We just want to make it so that when you check the "Group items by category" checkbox in the Install dialog the Dali Common features don't show up because they don't have a category. I am fairly sure WTP can handle this, we just need to get the p2 repository meta-data right to make it happen. This is what Tran is trying to change.
This work is completed. Would be nice to omit the category from these features but this appears to be a build challenge so leaving as is for now.
