[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] [glassfish-dev] Ongoing GlassFish testing
|
I'm very much in favor of GlassFish, as a compatible
implementation, becoming self-sufficient with respect to
compatibility testing.
There are two things to consider
- Testing at existing and legacy compatibility levels, and
- Supporting evolution of the Jakarta EE Platform.
To date, GlassFish and the platform evolution have gone
hand-in-hand. That shouldn't be presumed, moving forward, but we
shouldn't do anything that will preclude this.
Additionally, the Platform API and Component committer groups
have their own obligation to evolve their TCKs and it they must do
that with an implementation that's willing and staffed to
undertake that effort -- as a collaboration. No Spec. can evolve
without a compatible implementation to go along with it.
I'd be in favor of expanding the Jenkins test array for GlassFish
to support the version(s) of TCK validation and other environment
changes (i.e. JDKs, OSes, Databases, etc.) that are necessary for
GlassFish releases.
I do not think these should be assumed to replace the
requirements of the various Platform and component API team
responsibilities. So, I think this starts out that GlassFish would
copy over what's in the Jakarta EE TCK project -- but Jakarta EE
TCK project still has it's own operational requirements. (Over
time, hopefully, the EE TCK project requirements may diminish, but
for now, it looks to me like it's almost strictly and additional
effort.)
In an ideal world, GlassFish compatibility testing would include
the Platform TCK -- as well as validation that all included
technologies are compatible. This would suggest that GlassFish
should run the Platform TCK and all the stand-alone TCKs that
cover content included.
Moving these out of the TCK project should be straight-forward
though I don't know if the TCK team is planning any "high
priority" maintenance that they'd want to bring over to the
GlassFish CI/Jenkins. Maintaining them could be a more complex
chore, especially as it's likely the TCK content and structure may
evolve over the course of the next couple of releases. But that's
a future problem.
I'll can probably find someone who can copy the appropriate jobs
over to the GlassFish Jenkins instances. We will need to generate
some project specific expertise over time though. And, maybe we
can actually make some improvements in how it runs, for the
GlassFish project.
More that likely, we'll need to be judicious about how and when
we use the CI resources since GlassFish does not have as many
systems at it's disposal as the Jakarta EE TCK -- if available
resources becomes an issue, we can certainly take it up to the
Working Group steering committee and see if resources can be
shuffled around.
-- Ed
On 11/24/2020 10:44 AM, Gurkan Erdogdu
wrote:
Hi
+1 to move into GlassFish Jenkins instance
Regards.
Gurkan
All,
As we move to getting a
GlassFish final released. I’ve a question on TCK
testing. Up to the release of Jakarta EE we’ve been
using the TCK project Jenkins jobs to test GlassFish
compatibility. Now that the TCK has been released some
questions come to mind.
Should we move testing
over to the GlassFish Jenkins instance or keep it at
the TCK Jenkins?
If we decide to move to
the GlassFish instance can somebody help with updating
the TCK jobs here or create new testing jobs?
If we decide to keep
GlassFish testing on the TCK instance can somebody
help kick off jobs periodically?
Thanks
Steve
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list,
visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!LjQWpZTlhq0fAlH1abySOcZTk0d0NBqgBQr-6JEAA4tFLL5m7evvFqyb6Utaoxc$
