Community
Participate
Working Groups
I thought we'd gotten rid of this back in bug 304451, but ... seem back in Indigo. Could have been for a long time? I saw in RC3 and re-checked RC2 and it was there too. Seems to be in none of the other packages I've looked at (Java, LinuxTools, and JavaScript). Might be Dali itself "causing" this? As far as I know, it does not cause any user-observable problems ... but ... doesn't seem right we in Java EE package would have a "different behavior" than other packages during out startup, so wanted to at least capture this. I'll attach "console log" that shows it starting up.
Created attachment 197286 [details] excerpt from console log when starting up Java EE IDE
I'm going to move to Dali. I suspect is sucked in through some eclipselink dependency. I noticed if I create an installation, unzipping all WTP prereqs, and then install WTP itself via p2, this same "extra startup" behavior is observed. But, if I just unzip everything, including WTP, in same directory, then I do not see this "extra startup" behavior. So, that's what I think is odd. People can have "different installs" using same bits, so I think its important to at least understand what this "extra startup" is for. Is it critical for correct behavior? In which case just unzipping is no good. Or, is it extraneous in IDE environment, perhaps only applicable in eclipselink runtime? In that case, installing WTP should not cause it to happen. I'll leave to you, Neil, to investigate and work with EclipseLink team if some changes are needed? I'm assuming a "minor" problem if merely extraneous ... but, I know it'll bite us some day :)
Taking a look.
It appears that this is coming from the optional dependency that org.eclipse.persistence.core has on javax.transaction. This is not required, and is not useful in the context of the IDE. It would be nice if we could figure out a way for it to not be installed. I would guess that some sort of refactoring of EclipseLink bundles would be necessary to isolate this dependency in a fragment that would not be referenced by Dali. Unfortunately I wouldn't think there is any way that this refactoring could be done for Indigo. Would it be possible to set up an exclusion rule for the EE and Reporting package to exclude this file for Indigo builds? If so, that would only solve the issue for the packages, we would still experience the problem with hosted p2 installs.
> > Would it be possible to set up an exclusion rule for the EE and Reporting > package to exclude this file for Indigo builds? If so, that would only solve > the issue for the packages, we would still experience the problem with hosted > p2 installs. Doubt it ... well, that is ... not worth it :) At least right now. I'd be happy just knowing what it was for, what possible impact it might have, and what plan there'd be to remove it (either through some sort of exclusion during our build or more directly from EclipesLink changes ... but, since there is not a known problem, per se, I don't think it is worth any risk changing anything ... unless you know something I don't. We'd have to see if anyone else needed this javax.transaction bundle, but one easy solution might be just to leave it out of our Orbit.map file ... if no one directly _requires_ it?
(In reply to comment #5) > > > > Would it be possible to set up an exclusion rule for the EE and Reporting > > package to exclude this file for Indigo builds? If so, that would only solve > > the issue for the packages, we would still experience the problem with hosted > > p2 installs. > > Doubt it ... well, that is ... not worth it :) > > At least right now. I'd be happy just knowing what it was for, what possible > impact it might have, and what plan there'd be to remove it (either through The jar contents define the API for JTA - http://java.sun.com/products/jta/. It is a collection of interfaces that are implemented by a given application server. I'm guessing that for runtime applications this API needs to be on the boot classpath and hence the definition as an extension bundle. I don't think this would have any impact on the IDE, but I agree that it would be nice if it wasn't lurking out there. The longer term fix for removing it would be refactoring EclipseLink as a mentioned. > > We'd have to see if anyone else needed this javax.transaction bundle, but one > easy solution might be just to leave it out of our Orbit.map file ... if no one > directly _requires_ it? The only projects that require it are in RT or SOA, so I don't think there would be any implications on the IDE. There are certainly those that require this bundle outside of the scope of the IDE though.
I've opened bug 348357 in EPP, since I've changed my mind. I do think part of the problem is EPP should not pull in optional bundles, not named in features or touch point instructions. At first I thought there was something that existed in our WTP metadata (due to our use of eclipse link bundle) that instructed p2 to do something if this bundle was available, but ... I do not see anything like that. And, am now wondering if it is merely the fact that its listed as "optional" by a bundle that EPP picks it up. I changed my mind, after combing though out metadata, features, and our distributions ... and concluding there was no javax.transaction and no "hidden" instructions to install it ... that I could find. Then I went back and repeated my install scenarios in comment #2. I found even if I install WTP (a local repo) via p2, and disable other repositories, then javax.transaction is not installed. Hence, it is installed merely be being in a repository. Guess that'd normally be desired? But, not for EPP packages. So, even if bug 348357 gets solved it will be specific to EPP packages, so I'll leave this bug here, and I think we should still get an "IDE friendly version" of what ever code it is you are using from EclipseLink, so that users don't in inadvertently turn their IDE into an app server :) To cover all bases ... I'm assuming its impossible for us to remove "org.eclipse.persistence.core" at this point? Thanks,
(In reply to comment #7) > To cover all bases ... I'm assuming its impossible for us to remove > "org.eclipse.persistence.core" at this point? > That is the correct assumption. We require persistence.core to support our new database web services functionality. I would guess that if you chose not to install this feature (o.e.jpt.dbsw.eclipselink.feature) that you perhaps would not get the javax.transaction bundle.
While I was looking into this, I found that there are two plugins in the JavaEE package that define some kind of dependency to javax.transaction: (1) org.eclipse.persistence.core_2.3.0.v20110429-r9282.jar <unit id='org.eclipse.persistence.core' version='2.3.0.v20110528-r9473' singleton='false'> <requires size='41'> ... <required namespace='java.package' name='javax.transaction' range='1.1.0' optional='true'/> (2) org.eclipse.persistence.jpa_2.3.0.v20110429-r9282.jar <unit id='org.eclipse.persistence.jpa' version='2.3.0.v20110528-r9473' singleton='false'> <requires size='77'> ... <required namespace='java.package' name='javax.transaction' range='1.1.0' optional='true'/> <required namespace='java.package' name='javax.transaction.xa' range='1.1.0' optional='true'/> Both requirements are provided by <unit id='javax.transaction' version='1.1.1.v201105210645' singleton='false'>... and both requirements are greedy, correct? Would it be possible to mark them as non-greedy with a p2.inf file? That would be my first question. The other one is, without knowing too much about javax.transaction: This package is provided by the above IU javax.transaction, but it is also provided from <unit id='a.jre.javase' version='1.6.0' singleton='false'>. Would it be possible to create a workaround by using a 1.6.0 execution environment?
Thanks for the analysis, Markus. I've learned a lot from it. Most of all how much I have yet to learn. :) According to http://wiki.eclipse.org/Equinox_P2_Resolution#Requirements_greed all requirements are greedy by default, and as far as I know, we don't do anything special to make anything of ours non-greedy. (And, funny, I would have thought "optional" would be published as non-greedy ... but, guess not ... and not sure how that's supposed to be handled ... everyone who wants something optional to be non-greedy has to have a p2.inf file to specify non-greedy? I'm can see some advantage to that (since, often, users would want "optional" dependencies installed, whether named in a feature or not? Now I'm even wondering if related to the VM we use to do our PDE builds ... maybe if we used a 1.5 version, it would be included in our distributions? So much to learn ... :) ... but, thanks for beginning my (our) education.
(In reply to comment #9) > While I was looking into this, I found that there are two plugins in the JavaEE > package that define some kind of dependency to javax.transaction: > > (1) org.eclipse.persistence.core_2.3.0.v20110429-r9282.jar > > (2) org.eclipse.persistence.jpa_2.3.0.v20110429-r9282.jar > > <unit id='org.eclipse.persistence.jpa' version='2.3.0.v20110528-r9473' > singleton='false'> This is a bit unrelated but I'm trying to figure out why o.e.persistence.jpa is being pulled in, not that it would change this discussion. There must be some sort of optional dependency that is picking it up, but at a glance, I'm not seeing it.
It sounds like the advice from bug 251477 comment #7 is to "edit" the p2 content metadata to add greedy=false, to those cases where it is desired. Anyone think that's worth doing? (We'd do my hand, now, but the feature that includes this bundle could add a p2.inf file, for maintenance, etc. ... though I think a better long term solution should still sought).
(In reply to comment #12) > It sounds like the advice from bug 251477 comment #7 is to "edit" the p2 > content metadata to add greedy=false, to those cases where it is desired. > > Anyone think that's worth doing? Not me ... I've actually looked at this a little, and have zero confidence I could do this in a way that would work, much less be confident it'd be safe. So ... too bad not noticed sooner in time to do something "at the source", but ... at least doesn't cause any user impacting problems (none know yet, yet is :) Just wanted to be explicit that as far as I'm concerned, this issue is done for Indigo release ... unless anyone else has some insight that make some change quick, and safe. Thanks for all the investigations, discussions.
Hi All, Looks I am facing same problem. I am migrated ti indigo and when I am doing my Add required plugins it adding javax.transaction where for my project I dont think it is required and on the top when I am generating build of RCP application in headless mode it throwing error. Unable to find plug-in: javax.transaction_0.0.0. Please check the error log for more details. and the default plugin in eclipse is: javax.transaction_1.1.1.v201105210645.jar Can any one please respond on this
