Community
Participate
Working Groups
Now that we've fixed bug 400518, we should not longer need to "restriction" in the org.eclipse.equinox.http pom, since we now specify the exact version of the bundle we want, from Orbit. <dependency-resolution> <extraRequirements> <!-- new methods were introduced in ServletContext and possibly other interfaces implemented by this bundle in javax.servlet 3.0. Because of this we need to make sure to compile against earlier version. --> <requirement> <type>eclipse-plugin</type> <id>javax.servlet</id> <versionRange>[2.4.0,2.6.0)</versionRange> </requirement> </extraRequirements> </dependency-resolution> That exact version, in eclipse-sdk-prereqs.target is 3.0.0.v201112011016 And, now that I look at this, I'm not sure how this works or if working as expected. i.e. not sure if the section can be removed ... or if target file should change? The javax.servlet in Orbit, as a bundle, is version 3.0.0.v201112011016, but the packages are exported at "2.6.0" level. Should we be specifying a different version in eclipse-sdk-prereqs.target? Or, is this org.eclipse.equinox.http picking up the lower level bundle from some other repository or pre-req (such as jetty pre-req?) Or, is this no longer an issue?
I see, according to bug 389050 that this bundle is deprecated, and is in fact "commented out" of the repository POM's list of "modules". Hence, I'll "transform" this bug into a request to remove it from "master" (and R4_3_maintenance branch) along with the "jetty5" and "jetty6" bundles (and any others which are not <modules> we build ... I believe our goal should be that anyone can "import the repository" with minimal fuss and not have to figure out which are "irrelevant" and should be "closed" and which are "relevant" and need some other sort of adjustment in IDE to compile (such as, perhaps define EE or something).
I removed the following: org.eclipse.equinox.http org.eclipse.equinox.http.jetty5 org.eclipse.equinox.http.jetty6 with commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=def1c2c2f9784decdc5d23d3a7e3839604852e41 There are still a number of modules commented out of the root pom.xml. After the nightly build I will update the pom to reorder it alphabetically to more easily tell what "extra" projects are in the repo that we do not build. So far this is the list I have in addition to the ones I just removed: Console tests: org.eclipse.equinox.console.ssh.tests org.eclipse.equinox.console.tests I don't really want to remove these since they could be resurrected at some point. Old log tests: org.eclipse.equinox.log.test Could remove the old log tests, but should also consider not build the old log implementation also (org.eclipse.equinox.log). As long as we have the old log impl, I think we should leave the tests around. Servlet bridge extension bundle and servlet bridge feature: org.eclipse.equinox.servletbridge.extensionbundle features/org.eclipse.equinox.server.servletbridge I think we need to keep these around for folks that may want to build these themselves.
(In reply to Thomas Watson from comment #2) > I removed the following: > > org.eclipse.equinox.http > org.eclipse.equinox.http.jetty5 > org.eclipse.equinox.http.jetty6 > Thank you. > > I think we need to keep these around for folks that may want to build these > themselves. I don't really object or see your plan as too "bad" ... but an alternative I'd consider better, is that you (and others) create a (persistent) branch named "inactive" (or similar name) then branch these modules into "inactive", and then remove from master. The advantage is it makes it obvious to others that "they are not part of the normal deliverables and not actively maintained" and (my selfish reason :) it better supports the use case that caused me to open this in the first place: often I want to "search everything", say to see who is adding "extra restrictions" or mentions some particular package in their MANIFEST.MF file, then all these old, "not active" bundles are potential "hits" (if in master) ... but I don't particularly care about those, since we are not actively building or delivering those. Make sense? I'm CC'ing Dani, Paul, and John to see if any of them think this worth making "Eclipse Platform policy" (that is, to have a branch with a consistent name for things that are currently "inactive" (but, which might be wanted by others, or might have loose plans to merge back into master in some distant future). I believe many of the repositories have a number of these type of "inactive" modules. Seems it would not be too much effort and little risk, but makes the "barrier to entry" a little lower to un-clutter the main branches -- as well as make my job a little easier :)
For bundles that are definitely no longer being maintained simply deleting them from master sounds like the right approach to me. For bundles that we keep around because others may consume them I like leaving them in master. For example when doing refactoring you want to make sure you keep them in sync with any other changes going on in that component, and putting them in a side branch makes that harder (or likely it will be forgotten and accidentally broken by changes). I am tempted to say we should just delete such bundles from the root pom.xml to make it clear we are not building them. Leaving them there in commented out form is a bit misleading - it suggests to me that we intend to build them but temporarily are removing them.
I'm fine doing this for 'master', but would not touch the maintenance branch.
(In reply to John Arthorne from comment #4) > For bundles that are definitely no longer being maintained simply deleting > them from master sounds like the right approach to me. For bundles that we > keep around because others may consume them I like leaving them in master. > For example when doing refactoring you want to make sure you keep them in > sync with any other changes going on in that component, and putting them in > a side branch makes that harder (or likely it will be forgotten and > accidentally broken by changes). > > I am tempted to say we should just delete such bundles from the root pom.xml > to make it clear we are not building them. Leaving them there in commented > out form is a bit misleading - it suggests to me that we intend to build > them but temporarily are removing them. I agree with John, I would prefer to keep these bundles in the repo if they are used by others. Perhaps moving them out of the "bundles" folder would help. This way we can make it clear that all projects from "features" and "bundles" are the built things?
(In reply to Thomas Watson from comment #6) > (In reply to John Arthorne from comment #4) > I agree with John, I would prefer to keep these bundles in the repo if they > are used by others. Perhaps moving them out of the "bundles" folder would > help. This way we can make it clear that all projects from "features" and > "bundles" are the built things? I can see John's point too. Though am concerned if we carry along "half supported" things "used by others" ... it just adds to the confusion, clutter, and work load of many people, for little gain. I am not disagreeing, just urging caution. One person's "might be useful" module is another persons "junk" :) Separate folders might help. Another repository, as a submodule of the "main" repository might help too? (And then "casual users", like me :) could clone it or not. Since this likely won't be solved, in the general case, any time soon, I've opened bug 423186 to carry on a longer term discussion about the general case for all repos in Eclipse Platform project (and Equinox :)
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.
