Gaurav is picking up the blocker from my team as he did the similar fix in Payara a couple of years back.
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms
Sent: 19 February 2021 11:14
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Merge of 6.1 branch to master
Hi everyone,
Next on the list is getting the two quickview tests suites (Full & Web) to run again.
Hi Gurkan,
The dependencies are in staging. Meaning you need to build with either mvn clean install -Pstaging or add the staging repo (see referenced 1.0.6 parent Pom) to a local settings.xml.
On Sunday, February 14, 2021, Gurkan Erdogdu <gerdogdu@xxxxxxxxxxxxx> wrote:
Hi
I checked-out master but when starting domain1 it throws several OSGI errors.
Did you build ORB and HK2 locally?
Hi,
Master now builds. GlassFish starts up without exceptions, and the admin console boots and works without exceptions as well.
We're currently waiting on GlassFish ORB 4.2.4 to be staged, and a build error in HK2 to be fixed (likely caused by an overeager bot). There's a variety of components that could/should be updated, not in the least
because they contain their own JDK 11+ fixes.
Next step is running the integrated tests (quicklook + CDI all)
On 2/11/21 12:55 PM, Steve Millidge (Payara) wrote:
I like the idea of GlassFish doing its own TCK testing when the TCK is finalised and the Jakarta EE version we are testing is released. I think if the TCK is a moving target and GlassFish is a moving target e.g. during platform development e.g. 9.1 it becomes
more problematic.
The TCK will not be changing as much as it did for the EE 9 release. I think that some TCK changes are expected (e.g. rename javamail => jakartamail, update some schemas to Jakarta EE 9 that we missed, signature test fixes as
needed, script changes for Java 11).
We also would like to remove the last (GlassFish) hard dependency in the Platform TCK. The `com.sun.ts.lib.implementation.sun.javaee.SunRILoginContext` which implements the TCK porting com.sun.ts.lib.porting.TSLoginContextInterface
depends on the GlassFish com.sun.enterprise.security.auth.login.* classes. At a minimum, we *should* stop building the (GlassFish TCK porting kit) SunRILoginContext class in the TCK build. Wherever we do build that, it needs to have the TCK TSLoginContextInterface
class on its classpath. Since the TCK doesn't publish a maven artifact for the TSLoginContextInterface class, we likely need an interim solution for 9.1. Although if anyone knows where the GlassFish TCK porting kit code (including SunRILoginContext class)
should live, please speak up. :-)
I found the way of working for the 9 release whereby the TCK was doing GlassFish testing good as GlassFish project lead I could worry about fixing the GlassFish bugs and not have to worry about which release of the TCK to test and where the TCK was in its development
cycle. However I understand that may push the burden to the TCK team
😊
If the TCK team makes a change, we will test our change on
https://ci.eclipse.org/jakartaee-tck which should reduce the frequency of updating the GlassFish CI to use a new release/version/build of the TCK to test with. We did just create
https://ci.eclipse.org/jakartaee-tck/job/9.1/job/build-glassfish so we can build the GlassFish 6.1.0 branch as needed also.
Anyway someone with knowledge of getting the TCK up and running on GlassFish will need to step up to create the Jenkins jobs on the GlassFish project as I have no idea how to do it.
I think that Guru started with the
https://ci.eclipse.org/glassfish/job/jakartaeetck-certification-gf +
https://ci.eclipse.org/glassfish/job/standalonetck-certification jobs.
Scott
Steve
Are we planning to run the TCK on the GlassFish Jenkins still?
That's a very good question. I like the idea of kicking off a basic TCK test from the GF project. On the other hand, the GF CI, due to it being a collection of many projects, not just the AS, is already a little complicated (perhaps that's an understatement
even).
Also, the GF CI probably has less resources provisioned for it right now?
Steve
Hi,
Thanks! The status is as follows:
The PR includes the work done earlier by Fujitsu and my work where I updated the command security plugin to support JDK 11 and replaced all usages of sun.* classes that either disappeared entirely, or were made invisible.
I tried to replace as much as possible with public alternatives. Eg “jarsigner” moved to a public API, and “FilePolicy” could be obtained via a public API. For some other code, like PropertyExpander I had to replace it with new code of myself.
The code compiles, and the unit tests pass. GF starts up enough to generate the domains during the build, but beyond that no tests have been done.
* Start GF manually and inspect logs
* Start admin console and test if it all works
* Run TCK and fix failures (likely fix in both TCK and GF)
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev
|
