[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [glassfish-dev] Merge of 6.1 branch to master
|
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.
Kind regards,
Arjan
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?
Regards.
Gurkan
Hi,
Just an updated status:
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)
Kind regards,
Arjan
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