Jonah,

If I try your first set of steps, but *without *adding a JustJ JRE site, I can hit the "Next" button on the "Updates Available" dialog as many times as I like but I cannot proceed with the install.  No explanation is given why "Next" doesn't work, and nothing is in the error log to indicate what's gone wrong.   So such an IDE apparently can't be updated at all though for no apparent reason.

I know that Mickael added a JRE processing step that is supposed to determine if the current running JRE satisfies all the BREEs of all the IUs to be installed, so no doubt this is kicking in, but now without explaining to the user what's gone wrong.  Adding the JustJ JRE site indeed allows the install to proceed as you observed; no doubt the presence the JustJ fake a.jre.org.eclipse.justj.* IUs are not excluded like the fake a.jre.javase IUs (or the real JustJ ones for that matter) during this JRE processing step, allowing the install to proceed.  If the processing step did exclude the JustJ fake ones no doubt a real one would get installed like we saw before.  And one can't arbitrarily exclude the real ones too because that might be exactly what the user is about to update making the overall update valid after a restart.

Note that an unzipped CPP 2022-06 package's eclipse.ini contains this twice:

-Dosgi.requiredJavaVersion=11
-Dosgi.requiredJavaVersion=11

It seems we're stuck a bit between a rock and a hard place and even the current behavior of older installations (refuse to update but don't explain why) seems broken, though at least it never produces a somewhat broken updated installation.   That being said, in Jeff's case there was an explicit failure to update, though the reason why is not clear to the user...

I'm also not comfortable hard-coding a specific update site in the JustJ IUs because this takes control away from the consumer. E.g., if someone installs JustJ Java 11 they'd generally not want an update site added that would immediately allow updating to Java 17 because if they did want that, they would not have installed Java 11 in the first place but rather Java 17.   So while it would be reasonable/okay to add https://download.eclipse.org/justj/jres/XX/updates/release/latest/ when installing Java XX to allow updates to newer versions of XX, that would not solve the general EPP problem where eventually we'll want users to update to some LTS version > 17 and EPP itself will determine exactly when that is desired.   Even adding a  touchpoint to some EPP IU is questionable because with the installer one can install an EPP package using a JRE local on the machine, without using/installing a JustJ JRE.  Also one can uninstall the JustJ JRE.   So I just don't see a 100% ideal solution.

Maybe we should take the discussion offline to a bugzilla or issue?

Regards,
Ed

On 26.09.2022 02:08, Jonah Graham wrote:
> I also test installing Eierlegende Wollmilchsau for 2022-06 with a Java 11 JDK installed on my machine (not a JustJ one) and updating it to 2022-09 with https://download.eclipse.org/justj/jres/17/updates/release/latest visible/available. That too installed a.jre.org.eclipse.justj.openjdk.hotspot.jre.full.

I did a similar test - but ended up with different(?) results, and more importantly I ended up with a non-working IDE.

This is what I did:
1- System java is Java11
2- Install C/C++ using Oomph + system Java
3- In newly launched IDE add https://download.eclipse.org/justj/jres/17/updates/release/latest/ to software sites
4- Check for updates
5- Everything seems to install fine, including things requiring Java 17 (TM4E) 6- Restart IDE, my error log now full of framework errors like this (shortened for brevity, let me know if you need full log):

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.tm4e.ui [761]   Unresolved requirement: Require-Capability: osgi.ee <http://osgi.ee>; filter:="(&(osgi.ee <http://osgi.ee>=JavaSE)(version=17))"

That is because I am still using Java 11, but Eclipse (with JustJ update site) allowed me to install items requiring Java 17.

I can get the same error as above like this:
1- System java is Java11
2- unzip/untar eclipse-platform 4.25 and launch
3- In Install New Software, choose "Wild web developer"
4- Wizard will fail due to insufficient Java version
5- Close wizard and add https://download.eclipse.org/justj/jres/17/updates/release/latest/ to software sites
6- In Install New Software, choose "Wild web developer"
7- Everything seems to install fine, including things requiring Java 17 (TM4E)
8- Restart IDE, my error log now full of framework errors like the above.

I tried some other combinations of things, but overall simply adding the URL seems unsatisfactory if the user isn't using JustJ already. If JustJ was in use, it seems to do a perfectly fine job (on the one test I did)

BTW - you may be asking how the IDE was even able to launch with the wrong Java version, I think it is because the eclipse.ini gets updated to look like this (shortened for brevity again):

-vmargs
-Dosgi.requiredJavaVersion=17
-Dosgi.requiredJavaVersion=11

So with the old osgi.requiredJavaVersion left in the file, the launching steps don't warn the user as to what may be wrong. Ironically, if the eclipse.ini update had worked, then the user would have an unlaunchable IDE instead, until they updated to Java 17.

Are you able to reproduce my above issues? If not, I can try again to make sure I haven't done anything unexpected.

Jonah



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>


On Sun, 25 Sept 2022 at 04:44, Ed Merks <ed.me...@gmail.com> wrote:

    Jonah,

    I had some time to do additional testing and I believe the problem
    of unintentionally installing a real JustJ JRE is no longer a
    problem.  See the details below the line.

    Therefore, I suspect the simplest solution is to compose
    https://download.eclipse.org/justj/jres/XX/updates/release/lates
    into https://download.eclipse.org/releases/latest where XX is the
    highest BREE of any IU in SimRel, currently 17.  One advantage
    here is that we can change this site to impact existing
    installations even today, e.g., older installations that have
    JustJ JRE < 17 installed and are trying to update to the latest.  
    It also means that anyone using JustJ JREs can choose the source
    of the updates themselves (perhaps a site within a corporate
    firewall or one of the JustJ sites) rather a specific site that I
    decide and hard-code, via touchpoints in the IUs, as the good one
    for everyone using JustJ.

    What do you think?

    _____________________________________________________

    One thing that's changed since the bug reports, specifically the
    following about JustJ being installed simply because the IUs are
    visible:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=569871

    is that each site now contains its own "fake" a.jre IUs. E.g.,

    
https://download.eclipse.org/oomph/archive/reports-extra/justj-jres-17/download.eclipse.org/justj/jres/17/updates/release/latest/https___download.eclipse.org_justj_jres_17_updates_release_17.0.4.v20220903-1038/a.jre.org.eclipse.justj.openjdk.hotspot.jre.full_17.0.0.html

    which provides the same capabilities as the real JRE IU:

    
https://download.eclipse.org/oomph/archive/reports-extra/justj-jres-17/download.eclipse.org/justj/jres/17/updates/release/latest/https___download.eclipse.org_justj_jres_17_updates_release_17.0.4.v20220903-1038/org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_17.0.4.v20220903-1038.html

    When I tried installing the Eierlegende Wollmilchsau for 2022-09,
    i.e., all IUs on the train, with
    https://download.eclipse.org/justj/jres/17/updates/release/latest
    as an available update site, the install log shows this:

      Installing a.jre.org.eclipse.justj.openjdk.hotspot.jre.full [17.0.0]

    So yes, a JustJ IU is installed, but it's the fake one just like
    the fake a.jre.javase IU that would otherwise be installed,  so
    there are no associated artifacts and no -vm touchpoint is applied.

    I also test installing Eierlegende Wollmilchsau for 2022-06 with a
    Java 11 JDK installed on my machine (not a JustJ one) and updating
    it to 2022-09 with
    https://download.eclipse.org/justj/jres/17/updates/release/latest
    visible/available.   That too installed
    a.jre.org.eclipse.justj.openjdk.hotspot.jre.full.

    Then finally I tested installing Eierlegende Wollmilchsau for
    2022-06 with JustJ JRE 11 and the updating it with
    https://download.eclipse.org/justj/jres/17/updates/release/latest
    visible.  As expected, it does install JustJ JRE 17 in that case,
    which is exactly the problem we are trying to solve. (Rather
    unexpected is that very few other things update, but that's a
    different problem of poor coordination of duplicates bundles).

    Note that this fake a.ajre JustJ IU was added so it can be used
    like this in a Tycho build to ensure that the build resolves the
    actual capabilities of the JRE that will be used by the built product:

    
<executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full_17-17</executionEnvironment>

    In any case, I believe there are no issues to come back. Either
    the JustJ fake IU satisfies the requirements or, if a real JustJ
    JRE IU is installed, the real JustJ JRE is updated if updates are
    available.

    Regards,
    Ed


    On 22.09.2022 15:39, Jonah Graham wrote:
    Hi folks,

    We do certainly need a solution to people who upgrade their IDE
    installs, but keep in mind there was pushback in the past of
    including JustJ in the SimRel*. It was related to p2 choosing to
    install JustJ when it wasn't needed (e.g. because already
    available on the user's machine) and that would cause unexpected
    results for the user. See
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=570899#c8

    Perhaps if JustJ is included in an install, then JustJ should add
    its own p2 URLs to available sites - sort of how we do it for
    CDT:
    
https://github.com/eclipse-cdt/cdt/blob/main/releng/org.eclipse.cdt-feature/p2.inf
    - that would mean only JustJ users have JustJ included in their
    available update sites. It won't resolve existing installs, but
    should help going forward when we upgrade past Java 17.

    I think installing an LTS JustJ should only upgrade to future LTS
    JustJs, so some of the discussions about what JustJ p2 URLs are
    still relevant.

    * I don't think it matters if it is in a composite or directly in
    the simrel repo, as long as it is visible in the simrel URL(s)
    then certainly these issues come back again.

    Jonah

    ~~~
    Jonah Graham
    Kichwa Coders
    www.kichwacoders.com <http://www.kichwacoders.com>


    On Thu, 22 Sept 2022 at 03:04, Matthias Sohn
    <matthias.s...@gmail.com> wrote:

        On Thu, Sep 22, 2022 at 8:17 AM Ed Merks <ed.me...@gmail.com>
        wrote:

            Jeff,

            Given the regular release schedule of Adoptium/Temurin
            versions, often fixing security-related issues, baking a
            particular version into each release train repository,
            fixed to the particular version available at that time,
            doesn't seem like the best solution to this problem. 
            Note too that it's highly unlikely the user was just
            updating 2022-06 but rather from something much older
            that was previously updated to 2022-06 because 2022-06
            shipped with JustJ 17.0.x.

            Having an update site that is automatically added by EPP
            to each package and points to the desired current version
            would seem like a better solution.  I vaguely recall
            having such discussions but obviously we didn't conclude
            that...

            There is also a question of which version should a JustJ
            update site specify?  We could use this one:

            https://download.eclipse.org/justj/jres/

            But that includes the 18.x release and soon the 19.x
            release.   We probably don't want people updating to those.

            We could also compose this one:

            https://download.eclipse.org/justj/jres/17/updates/release/latest

            and update to some future LTS version eventually.

            Or maybe we should just compose the above into this site
            which I believe is already automatically added to all EPP
            packages:

            https://download.eclipse.org/releases/latest

            That would seem the simplest approach and would address
            the issue for existing installations already...

        +1, this looks like the best approach

            Regards,
            Ed


            On 21.09.2022 23:45, Jeff Johnston wrote:
            A user recently opened an issue against JDT UI because
            they were trying to update their 2022-06 Eclipse IDE for
            Java Developers and it fails because the current JustJ
            they had: 15.0.1 is not sufficient to update components
            which now require Java 17.

            While they can manually add the needed JustJ updates
            site would it not make sense to make a JustJ update
            available automatically for such end-users at least in
            the case where Eclipse increases minimum JVM requirements?

            -- Jeff J.

            _______________________________________________
            cross-project-issues-dev mailing list
            cross-project-issues-dev@eclipse.org
            To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
            _______________________________________________
            cross-project-issues-dev mailing list
            cross-project-issues-dev@eclipse.org
            To unsubscribe from this list, visit
            https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

        _______________________________________________
        cross-project-issues-dev mailing list
        cross-project-issues-dev@eclipse.org
        To unsubscribe from this list, visit
        https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


    _______________________________________________
    cross-project-issues-dev mailing list
    cross-project-issues-dev@eclipse.org
    To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
    _______________________________________________
    cross-project-issues-dev mailing list
    cross-project-issues-dev@eclipse.org
    To unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to