| Summary: | stax-ex wouldn't build without jsr173 -- Possible missing dep? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | John Crist <johncrist88> |
| Component: | [OLD] Java | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi, cornicx, flameeyes, johncrist88 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 388113 | ||
| Bug Blocks: | |||
| Attachments: | Revision of the stax-ex ebuild to pull in jsr173 as a dep. | ||
|
Description
John Crist
2011-09-16 02:59:39 UTC
Created attachment 286617 [details]
Revision of the stax-ex ebuild to pull in jsr173 as a dep.
I've added jsr173 as a dep to stax-ex. I'm not sure if it should be a dep to something else in the world, but it certainly kept stax-ex from building for me.
The proper solution is not that. This happened after jdk7 and virtuals bump in tree? Dunno what the real reason is though. I noticed the virtuals for the first time today and thought them odd. I didn't dig to hard as to their purpose. Should this be pulled in when the jre or jdk get pulled in then? @John Sync and use stax-api-1-r3. I'm leaving this open for java-config investigation. @Java java-config seems to be confused by hardcoded 1.6 slot in stax-api-1-r1. Any ideas? java-virtuals/stax-api is a virtual for jsr173. Java 1.6 actually includes it. I don't quite understand the "No provider is available" error. Sorry, didn't see the comments here because I forgot to refresh the page this morning. :) (In reply to comment #4) > @Java > java-config seems to be confused by hardcoded 1.6 slot in stax-api-1-r1. Any > ideas? The error happens if neither jsr173 nor a VM providing type JRE and version 1.6 is installed / visible to java-config when instantiating the virtual. Going by the dependencies portage shouldn't have allowed this. Even with the VM installed the build would have failed later when obtaining the classpath. Telling the user to switch VM or to install jsr173. *** Bug 384047 has been marked as a duplicate of this bug. *** Flameeyes: was this the reason why you added jsr173 depend in freemind? Seems like that. Honestly when you find the ebuild could not have reached that stage, it sounded more like an ebuild issue than a dep (the usex usage was off as well). Maybe not the same:
* Using following ANT_TASKS: jibx
!!! ERROR: No providers are available, please ensure you have one of the following VM's or Package's;
VM's (Your active vm must be one of these): >=virtual/jre1.6
Packages's: jsr173
!!! ERROR: No providers are available, please ensure you have one of the following VM's or Package's;
VM's (Your active vm must be one of these): >=virtual/jre1.6
Packages's: jsr173
(In reply to comment #11) > Maybe not the same: > > > * Using following ANT_TASKS: jibx > !!! ERROR: No providers are available, please ensure you have one of the > following VM's or Package's; > VM's (Your active vm must be one of these): >=virtual/jre1.6 > Packages's: jsr173 > > !!! ERROR: No providers are available, please ensure you have one of the > following VM's or Package's; > VM's (Your active vm must be one of these): >=virtual/jre1.6 > Packages's: jsr173 This is the intended behaviour. It allows to drop dependencies for newer vms, but means you might have to install jsr173 or switch vm later. It's not elegant, I know. Btw, thanks for the usex one. Ehm sorry but for Gentoo QA if you add an ebuild to the tree that does that, the ebuild is broken, missing dep. So if it was intended behaviour, it's time to fix it... (In reply to comment #13) > Ehm sorry but for Gentoo QA if you add an ebuild to the tree that does that, > the ebuild is broken, missing dep. > > So if it was intended behaviour, it's time to fix it... This is only supposed to happen if you pull in stax-api while >=jdk-1.6 is the active system vm. What this means is downgrading of the system vm isn't perfectly supported. You may need to install a few additional packages. Users usually don't do that though. "Fixing" it would basically mean to remove the vm providers in java-virtuals/*, which is done for years and comes with some benefits for users. Obviously someone thought of it as being worth it and went as far as to implement it likely knowing the consequences. Anyway, I assumed first you used an jdk < 1.6. However after some investigation it turned out the latest stax-api ebuild has a typo which will reject valid vm providers. See bug 388113 This still leaves the issue of vm providers in general. Personally, I'm not against removing the vm providers and requiring >=jdk-1.6 here and there. So it comes at a prize and should certainly be discussed first. (In reply to comment #14) > (In reply to comment #13) > > Ehm sorry but for Gentoo QA if you add an ebuild to the tree that does that, > > the ebuild is broken, missing dep. > > > > So if it was intended behaviour, it's time to fix it... > > This is only supposed to happen if you pull in stax-api while >=jdk-1.6 is the > active system vm. What this means is downgrading of the system vm isn't > perfectly supported. You may need to install a few additional packages. > Users usually don't do that though. I think the is no issue for building as the VM will be switched to a one that satisfies all the deps and virtuals, even if the system vm set is not the one. The error message should not appear during build at all, only outside at runtime if you actually try to use such package with an older VM. Which is kinda impossible to prevent. > Anyway, I assumed first you used an jdk < 1.6. However after some investigation > it turned out the latest stax-api ebuild has a typo which will reject valid vm > providers. See bug 388113 Yes hopefully all is fixed with stax-api-1-r4 that fixes a typo which was supposedly fixed already in -r3 according to changelog, but actually there was no difference from -r2 (I'm looking at you Serkan :) |
