Community
Participate
Working Groups
The Linux Tools project's Valgrind bundle requires org.mozilla.rhino. In the Helios SR releases, this was re-named to org.mozilla.javascript. Is there a reason for the change? I looked through BIRT bugs but didn't see anything related to the name change. We can adapt but I want to be sure this change was intentional. Thanks.
I should clarify where I got this information on the re-name: $ ./eclipse -nosplash -consolelog -application \ org.eclipse.equinox.p2.director -repository \ http://download.eclipse.org/birt/update-site/2.6-interim -list \ > /tmp/birt-interim $ ./eclipse -nosplash -consolelog -application \ org.eclipse.equinox.p2.director -repository \ http://download.eclipse.org/birt/update-site/2.6 -list \ > /tmp/birt-release $ diff -u /tmp/birt-{release,interim} | grep org.mozilla -org.mozilla.rhino=1.7.1.v20090608 -org.mozilla.rhino.source=1.7.1.v20090608 +org.mozilla.javascript=1.7.2.v201005080400 +org.mozilla.javascript.source=1.7.2.v201005080400
Andrew, pardon my ignorance ... but are you using org.mozilla.rhino from BIRT specifically because you use BIRT? Or was that just a handy place to get it from? If the later, you really should be "packaging" your own and be independent of what BIRT decides to do. (In general, not sure what to do about maintenance release). Plus, you should be using what is in Orbit ... which is org.mozilla.javascript. BIRT team, dropping and adding a bundle is a pretty big change. At a minimum, should be communicated via Cross-project list to see if any impacts/concerns. If a "solution" is needed, so that you could use/ship org.mozilla.javascript, but for compatibility still have an org.mozilla.rhino bundle, one possibility is to have a "fake" org.mozilla.rhino bundle, which just imports and exports the entire org.mozilla.javascript bundle. I think that'd work (that is, give you what you need from newer, Orbit version, but still appear compatible to anyone depending on "your" org.mozilla.rhino bundle. There might be some negatives to doing this way ... a) adopters _might_ need to know to "pick up" both (maybe? depends on how you, and they, do their packaging) and b) "org.mozilla.rhino" isn't really our namespace, so might be "confusing" if there were other bundles that existed with that name? But ... thought I'd mention the possibility. Maybe you'd get better feedback or suggestions on "cross-project" list?
I'll let Elliott respond regarding the requirement on Rhino since knows the situation better than I do.
(In reply to comment #2) > Andrew, pardon my ignorance ... but are you using org.mozilla.rhino from BIRT > specifically because you use BIRT? Or was that just a handy place to get it > from? If the later, you really should be "packaging" your own and be > independent of what BIRT decides to do. (In general, not sure what to do about > maintenance release). Plus, you should be using what is in Orbit ... which is > org.mozilla.javascript. We have org.mozilla.rhino as a dependency solely because BIRT requires it. The dependencies for the Valgrind feature are computed using the feature.xml editor, plus whatever entire features should be installed (CDT, profiling framework). My concern about switching to org.mozilla.javascript at the moment is that it would break nightly builds for non-SR1 users.
> ... The > dependencies for the Valgrind feature are computed using the feature.xml > editor ... > Ah, you know you don't really need to do that any longer? Well, maybe you have some special case. Are your adopters using "update manager"? In most cases, p2 does all this for you "real time" ... just goes and figures out whole tree of what's needed. But ... that doesn't help your current problem. And do think the BIRT team needs to help figure out a solution that's more "compatible" between release and SR1. Thank you very much,
(In reply to comment #4) > We have org.mozilla.rhino as a dependency solely because BIRT requires it. The > dependencies for the Valgrind feature are computed using the feature.xml > editor, plus whatever entire features should be installed (CDT, profiling > framework). > My concern about switching to org.mozilla.javascript at the moment is that it > would break nightly builds for non-SR1 users. Which birt feature is required by your projects? It's strange that org.mozilla.rhino is NOT required by BIRT features. It was included in BIRT feature as other BIRT plugins since Helios. So I think org.mozilla.rhino/org.mozilla.javascript should not be added to the require list of your features if you have already added birt features?
(In reply to comment #6) > (In reply to comment #4) > > We have org.mozilla.rhino as a dependency solely because BIRT requires it. The > > dependencies for the Valgrind feature are computed using the feature.xml > > editor, plus whatever entire features should be installed (CDT, profiling > > framework). > > My concern about switching to org.mozilla.javascript at the moment is that it > > would break nightly builds for non-SR1 users. > > Which birt feature is required by your projects? It's strange that > org.mozilla.rhino is NOT required by BIRT features. It was included in BIRT > feature as other BIRT plugins since Helios. > > So I think org.mozilla.rhino/org.mozilla.javascript should not be added to the > require list of your features if you have already added birt features? I currently have a dependency on only the BIRT charting plugins. Perhaps listing only the chart feature as a dependency and not the plugins would be the best solution.
Perhaps. I don't know your component, so will just speak in general terms. Normal, for one feature to "require" another feature is discouraged. Because, features are restructured/reorganized release to release, so best not to make to many assumptions. Normally, the prereqs specified in bundle manifests suffices to get everything needed. But, there's a few cases where you do need to specify what features you require: 1. If none of your bundles pre-req bundles from the feature you want. They would not get pulled in then, unless you pre-req the feature. This case happens often when someone wants some other tools/features present, for their users, but their code does not call out to the other code. For example, in WTP, we want users to have (most) of the features of datatools, but our code does not have very many dependencies on their code. We just know JEE users also use Data Tools. 2. Even if your bundles do have some dependencies via prereqs, you might have to specify a feature if the feature has things needed by your users, but which are not (maybe never) specified via bundle manifests. For example, in WTP we need many code plugins from JDT, but we also want the Java IDE Documentation too ... so that has to be obtained via feature-to-feature relationships. If neither of those cases apply, you probably just want to let the bundle manifests to their job, and stop trying to help them :) Hope this helps ... I'm sure there's other cases and considerations I haven't though of ... so do ask again, if more questions.
Hi all, what's the status of this bug now? Shall I close this bug as won't fix or reassign back to Linux Tools project? Since it seems there will be no change from BIRT side.
(In reply to comment #9) > Hi all, > > what's the status of this bug now? > > Shall I close this bug as won't fix or reassign back to Linux Tools project? > Since it seems there will be no change from BIRT side. I have reassigned the bug to Linux Tools.
I have removed the dependency on Rhino from the Valgrind feature. I have confirmed the Valgrind feature is installable using both BIRT's 2.6 release and interim update sites. For the former org.mozilla.rhino is installed, and for the latter org.mozilla.javascript is installed.
