Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [External] : Re: Preparing to hack with ReWrite...


On Wed, Dec 7, 2022 at 2:26 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Tue, Dec 6, 2022 at 12:35 AM Olivier Lamy <olamy@xxxxxxxxxxx> wrote:


On Tue, Dec 6, 2022 at 3:25 PM Alwin Joseph <alwin.joseph@xxxxxxxxxx> wrote:

Hi Olivier,

 

Regarding the artifact jakarta.ws.rs:jakarta-restful-ws-tck:jar:3.1.1 , the standalone Jakarta REST TCK is found at [1] and not available at maven repositories.

 

From my understanding, this TCK is referred only at glassfish-runner/jaxrs-tck/pom.xml (?).
This is a module that is created to run the standalone Jakarta REST TCK against glassfish. It requires us to download the [1] (which is built from repo [2]) and do mvn install to run the TCK as configured at Jenkins job [3].



doesn't look right to me to reference some release artifacts which doesn't exist. 


I moved this module to a profile not activated per default.

I removed the draft status from the PR https://github.com/jakartaee/platform-tck/pull/1152 
 
 
this not really using Maven features of distributed artifacts.

https://github.com/jakartaee/platform-tck/tree/tckrefactor/glassfish-runner is expecting the maven repo to include staged artifacts for which I the workaround is to download https://download.eclipse.org/jakartaee/restful-ws/3.1/jakarta-restful-ws-tck-3.1.1.zip and install that in the local repo (big hack) but better to just not build the `glassfish-runner` module.
 
If there is a zip (which is a release I suppose) why not deploy the Maven artifacts (jar) as well?

Currently, we cannot push final releases of TCK archives to Maven public repositories (we only are pushing (EPL) Eclipse Public License TCKs to Maven repos).  TCK zips with EPL cannot be used when certifying implementations as compatible (https://www.eclipse.org/legal/tck.php EFTL license must be used). 

The TCK archive https://download.eclipse.org/jakartaee/restful-ws/3.1/jakarta-restful-ws-tck-3.1.1.zip is EFTL licensed and can be used for certifying implementations as compatible. 

Hope this helps.

Scott

 
This will simplify a lot of the Jenkins job and make it even faster (as no need to rebuild something which is a release)
sorry I don't have access to link [3]
 

 

IMO the glassfish-runner module can remain independent or can be skipped while compiling the platform TCK source.

 

Thanks & Regards,
Alwin Joseph

 

[1] https://download.eclipse.org/jakartaee/restful-ws/3.1/jakarta-restful-ws-tck-3.1.1.zip

[2] https://github.com/jakartaee/rest/

[3] https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-rest-tck-glassfish-run/configure

 

 

From: Olivier Lamy <olamy@xxxxxxxxxxx>
Date: Sunday, 4 December 2022 at 11:41 AM
To: Scott Marlow <smarlow@xxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, david.matejcek@xxxxxxxxxxx <david.matejcek@xxxxxxxxxxx>, Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>, Alwin Joseph <alwin.joseph@xxxxxxxxxx>
Subject: [External] : Re: [jakartaee-tck-dev] Preparing to hack with ReWrite...

While keep working on this branch I wanted to integrate some modules in a complete build.

I discovered some usage of maven in master which looks wrong to me,

the poms are not using a -SNAPSHOT version which can be a potential problem when real release will happen.

 

I cannot this artifact jakarta.ws.rs:jakarta-restful-ws-tck:jar:3.1.1

So i have this error:

Error:  Failed to execute goal on project glassfish-rest-tck: Could not resolve dependencies for project jakarta:glassfish-rest-tck:jar:3.1.1: Could not find artifact jakarta.ws.rs:jakarta-restful-ws-tck:jar:3.1.1 in jakarta-snapshots (https://jakarta.oss.sonatype.org/content/repositories/staging/) -

Does someone know in which repository is it available?

 

 

Is this a repository for snapshots or not?

 

    <repositories>
        <repository>
            <id>jakarta-snapshots</id>
            <url>https://jakarta.oss.sonatype.org/content/repositories/staging/</url>
        </repository>
    </repositories>

 

Is it the goal to build everything all together? 

I would say yes :) but asking for confirmation.

 

 

 

On Sat, Dec 3, 2022 at 12:55 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

 

On 12/1/22 2:59 AM, Olivier Lamy wrote:

 

 

On Thu, Dec 1, 2022 at 1:49 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

Sorry for the delay in responding.  

 

No worries.

I have started a draft PR here https://github.com/jakartaee/platform-tck/pull/1152.

Thanks, will look soon (tried on github but its too large of course :-) which is typical for Platform TCK changes) .

 

I have a lot of modules now compiling (some content has been moved to a glassfishtck module for future removal)

Yay!!! Thanks Oliver!!!

 

 

yup it's an interface extending a class!

I don't even understand why this doesn't fail building master branch?

 

What should I do with such class?

It looks like Simple2HttpSvc is extending the jakarta.xml.ws.Service API in an application specific way.

are the modules webservices12 and webservices12 still used?

They are optional and still valid for EE 10 but not sure yet of what will be removed from EE 11.

Consider removing the webservice12 + webservices13 sub-module from the root pom (perhaps comment it out and have the comment indicate "TODO: implement or remove optional webservices12/webservices13 tests" or something like that). 

 

 

 

 

 

On Tue, Nov 22, 2022 at 4:03 AM Olivier Lamy <olamy@xxxxxxxxxxx> wrote:

 

 

On Tue, Nov 22, 2022 at 3:21 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

 

On 11/20/22 8:31 PM, Olivier Lamy wrote:

I have started some work. 

But is there any reason to split runtime and glassfishtck?

On a case by case basis, IMO we should move sources that we don't think are going to be needed by the actual refactored TCK tests, into a `to_be_deleted_later` folder.

It would also be good to isolate the GlassFish TCK into a separate folder that other test sources do not reference. 

Trying to have a clean (e.g at least compiling) I have to re enable those modules.

And there are some circular dependencies between both.

At the end of the day, those modules will be removed?

I think the test harness and other runtime sources will be removed as they serve no purpose. 

I'm not sure about the GlassFish TCK porting kit.  David, Guru, Alwin do you have a preference for where the GlassFish TCK porting kit should live? 

 

 

Can I assume to replace throws Fault by throws Exception (e,g replace all usage of Fault by Exception)?

 

That sounds like a reasonable change to me.

 

I did that in servlet refactoring.

 

Is everything from the runtime module supposed to go?

 

Yes, I think so. 

 

I think that some of the common module contents should also go except for parts needed for tests. 

 

There are a lot of circular dependencies currently.

 

Yes there are.  :)

 

Those packages from runtime com.sun.ts.lib.deliverable.* causes some issues.

Can I simply remove them?

 

Yes, I think that makes sense. 

 

Scott

 

 

 

 

 

Scott

 

 

On Sun, Nov 20, 2022 at 4:53 PM Olivier Lamy <olamy@xxxxxxxxxxx> wrote:

Hi,

I'm not sure adding more tooling will fix anything (except making it more complicated by adding more tooling :)).

I have some issues on how the current tckrefactor build structure (e.g pom content), I have some changes in my branch with the servlet tck using arquilian. [1]

But I didn't to fix too many things in this branch as the merge/rebase will be an even worst nightmare for me :) 

Some content I have in mind which looks wrong (or I don't understand the reason) to my (long) Maven experience.

Why having everything in <dependencies> [2] in parent pom, this mean by example servlet or jsp will have batch or jms as dependency?

Why having this section with m-enforcer-p [3] is every poms?

I don't understand the need of using of build-helper-m-p [4] in every poms? we probably only need to have the sources in the standard Maven location.

 

If your concern is about having a clean build (e.g no compile issue) in the tckrefactor branch if you need a volunteer I can have a try for the next few days.

 

cheers

Olivier 

 

 

 

On Sat, Nov 19, 2022 at 12:54 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

Hi,

I am finding that in order to use ReWrite [1] to make source changes in our `tckrefactor` branch, we need to first get to zero build failures.  My `rewrite` topic branch [2] has some changes but more changes are needed to resolve build failures such as [3].  My question for all of you is how can we best get the `tckrefactor` branch building cleanly? 

Is there anything that I can do to help others to participate in the clean up? 

Scott

[1] https://docs.openrewrite.org/getting-started
[2] https://github.com/scottmarlow/jakartaee-tck/tree/rewrite
[3] https://gist.github.com/scottmarlow/a2b388e0be13bb51c4b33f263ccd7ce7
[4] https://github.com/jakartaee/platform-tck/tree/tckrefactor

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev


 

--

Olivier


 

--

Olivier



_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev


 

--

Olivier


 

--

Olivier


 

--

Olivier



--
Olivier


--
Olivier

Back to the top