search

gretty-gradle-plugin / gretty

Advanced gradle plugin for running web-apps on jetty and tomcat.
MIT License
128 stars 36 forks source link

Release Gretty 4 #183

Closed boris-petrov closed 3 years ago

boris-petrov commented 3 years ago

Jakarta EE Platform 9 will be released two weeks from now - on 20th of November. We have to wait for an official Tomcat 10 release after that. Also, Jersey support has to be fixed (hopefully it will be simple enough - check the issue). Perhaps Spring support too - although I have no idea if the Spring people are going to release a Jakarta-enabled version soon - I haven't checked. Then we have a few options:

1) Release Gretty 4 with only support for Tomcat 10. We can do that requiring JDK 8. 1) Fix support for Jetty 10 before releasing. Not sure how difficult that's going to be. That means requiring JDK 11 for Gretty 4.

All of these issues are part of a milestone but I'm not sure that we have to resolve all issues in it for an initial Gretty 4 release.

@f4lco, @henrik242, @javabrett - thoughts?

f4lco commented 3 years ago
boris-petrov commented 3 years ago

We'll release without Spring support for now until they fix it.

As for the deployment - I also don't have any experience, @javabrett is the man for that. I'll ping him when the time comes. :smile: You suggest we do some release-candidates at some point?

boris-petrov commented 3 years ago

@f4lco - both Tomcat 10 and Jetty 11 have final releases. There are branches for both. I suggest we merge them (once they are passing the tests) and then release Gretty 4, what do you think?

P.S. I've merged the Tomcat 10 branch because it seems to pass the tests.

f4lco commented 3 years ago

@boris-petrov yes, let's do that, I'm working on the test failure on the Jetty 11 release branch.

boris-petrov commented 3 years ago

@f4lco - also, I tried rebasing the gretty4 branch on top of master (or merging master in gretty4, I don't care that much) but there are some conflicts - could you also take a look at those? We'll have to do that before the release because I think we agreed on making master the latest and creating a gretty3 branch, right?

f4lco commented 3 years ago

I think we agreed on making master the latest and creating a gretty3 branch, right?

Yes, that sounds good. Does it truly matter to rebase / merge? I started cherry-picking relevant commits from master a while ago and resolving conflicts as I went. To me it's just relabelling branches rather than merging one into the other. If there's any benefit to it that I've missed, I'll look into it.

Also, is it possible to migrate to travis-ci.com? Looks like they are already shutting down parts of travis-ci.org, that's why the recent builds queue for so long. Their deadline for this migration appears to be end-of-year, which is soon. From the FAQ

we are announcing that travis-ci.org will be officially closed down completely no later than December 31st, 2020

wolfs commented 3 years ago

Do you also plan to do some work on the tasks for Gretty 4? Some of the tasks fail validation with Gradle 6.8, which will cause the build to fail in Gradle 7.0, which is around the corner. It would also be an opportunity to make the plugin configuration cache compatible, though I don't know what the state is there.

boris-petrov commented 3 years ago

@f4lco - well, I continued to push some small things to master (updates to packages and the likes) while the gretty4 branch was going on. I'm not sure what other changes we have on master that are incompatible with the gretty4 branch? I don't understand why there are conflicts at all. I was thinking that gretty4 is just master with a few containers removed and a few new ones added. So yes, I would prefer to rebase it on top of master if that's not too difficult. As otherwise we might miss some important fix from there.

I remember now that we merged a couple of external contributions - maybe they're the ones causing a conflict. And they are important for Gretty 4. So it would be nice to rebase.

@wolfs - I definitely intend to support Gradle 6.8 and Gradle 7 on Gretty, just haven't got there. Can you show my where you've seen that "tasks fail validation"? Also, if you have knowledge on Gradle, you could save us a lot of time by submitting a PR. :smile:

f4lco commented 3 years ago

@boris-petrov I doubly checked - all commits from master have found their equivalent in gretty4.

I'm in favour of doing a beta release of Gretty. Remember, the logging broke down in #186 (980affbfe0bf06bf432bfe86ad28a7e44136961c, respectively), and Gretty still waits for releases of slf4j and logback. So it is not really feature-complete because of that and users will have to cope with too much logging output.

boris-petrov commented 3 years ago

@f4lco - thanks for picking all the commits!

Ah, right, I forgot about the logging issue of course. OK, I'll coordinate with @javabrett to release a beta in the next few days (he'll show me how to do it so we don't have to go through him every time). I guess we have to "fix" the branches before that, right? That is, rename the gretty4 branch and create a new gretty3 one? Any ideas if this can be done in GitHub or we'll have to do normal git stuff?

As a side note - here and here are the only places I see where we use non-final versions of packages. Is there a final release of this one?

wolfs commented 3 years ago

@boris-petrov I think this issue covers most of them: https://github.com/gretty-gradle-plugin/gretty/issues/133

I don't know if and when I'll gonna look at the plugin, though given that Gradle promotes the plugin as a Jetty replacement, we want to make it work with Gradle 7 as well.

boris-petrov commented 3 years ago

@f4lco - sorry, I forgot to answer about Travis CI. Do you know how does the migration work?

@wolfs - I'm not that familiar with Gretty's source code, unfortunately, that's why I'm unsure how to approach this. I'm also not that familiar with writing Gradle plugins. A few questions for you - 1) is this as simple as adding an @Input or an @Output annotation on all these properties to fix the warnings? 2) these annotations might be needed on methods too? 3) when exactly is such an annotation needed? That is, when does Gradle decide that something must be annotated? 4) If I put @Input on all of them and some are actually for output, what's the worst that could happen - some caching not working or the whole thing will fall apart and the plugin will be unusable?

f4lco commented 3 years ago

@boris-petrov yes, there is, I upgraded accordingly in 6c24e1ac55631fc99f621630ad3f. I'm normally not in the business of given git advice 😜 but anyway, I suggest using the CLI, and creating "gretty3" from master first. Then follows checking out gretty4, and force-pushing that to master on the remote side, replacing master with the contents of gretty4. Migration to travis-ci.com consists of pushing a few buttons in the Travis CI admin console as described here.

boris-petrov commented 3 years ago

@f4lco - thanks for the update.

I migrated the branches so now master is officially Gretty 4. Yay!

I'll see about the migration of Travis CI. Not sure who has the access keys, probably @javabrett.

javabrett commented 3 years ago

Hi all - I've created the (fake, no-merge) PR #190 for branch release-4-0-0 which adds the normal release docs/text and version-bumps. This is the candidate for push to master for 4.0.0 then tagging/releasing.

Thanks largely to the efforts of @f4lco and @boris-petrov , we have a candidate for the Gretty 4.0.0 release. I propose that testers test this release via the CI/CD 4.0.0-SNAPSHOT versions that are available and are being built from master. This can be achieved by resolving Gretty via https://github.com/gretty-gradle-plugin/gretty/blob/master/pluginScripts/gretty-SNAPSHOT.plugin - let me know if you don't know how to do this. Currently this is built from master via GitHub Actions (thanks @boris-petrov for the migration from Travis).

Please test and comment here, thumbs up/down etc.

Note that as part of this release I am trying to move to org-style repos, so core-team members other than myself can be rostered to run a release as-required.

CC @henrik242 @wolfs

boris-petrov commented 3 years ago

To expand on what @javabrett said, the way I tried the SNAPSHOT version was to remove id 'org.gretty' version '3.0.3' from build.gradle and add:

buildscript {
        repositories {
                maven {
                        url 'https://oss.jfrog.org/artifactory/oss-snapshot-local'
                }
        }
        dependencies {
                classpath 'org.gretty:gretty:4.0.0-SNAPSHOT'
        }
}

apply plugin: 'org.gretty'

Also, add:

maven {
    url 'https://oss.jfrog.org/artifactory/oss-snapshot-local'
}

To every repositories block.

Try out version 4 and let us know if there are any troubles.

My personal experience is that there's a bunch of other dependencies that still don't have Jakarta-enabled releases. We're one of the first. :smile: @f4lco was so fast!

boris-petrov commented 3 years ago

Just a note here. I've uploaded a new snapshot of 4.0.0 to Maven Central. This build.gradle script seems to work:

buildscript {
    repositories {
        mavenCentral()
        maven {
            url 'https://oss.sonatype.org/content/repositories/snapshots'
        }
    }

    dependencies {
        classpath 'org.gretty:gretty:4.0.0-SNAPSHOT'
    }
}

plugins {
    id 'java'
}

repositories {
    mavenCentral()
    maven {
        url 'https://oss.sonatype.org/content/repositories/snapshots'
    }
}

apply plugin: 'org.gretty'
lipnitsk commented 3 years ago

@boris-petrov thanks, the SNAPSHOT worked for me (needed 4.0 to test Tomcat 10). Are there any blockers still? If not, maybe you could cut an official 4.0 release soon?

boris-petrov commented 3 years ago

@lipnitsk - thanks for the heads-up. I don't believe there are any blockers, we were mainly waiting for someone to test it "for real" to say if it's working or not. If you think it is, we could cut a release. @f4lco - thoughts?

f4lco commented 3 years ago

Please, cut a release 👍 any version will do, but I do recommend a beta or RC. I think most people will just want to use a fixed version, and will not want to follow the moving target of a -SNAPSHOT release.

My https://github.com/gretty-gradle-plugin/gretty/issues/183#issuecomment-741860048 from Dec '20 is still valid. In the end, the current Groovy scripts for configuring logging will have no effect, and Gretty will be a little verbose. Logback does not seem to have made progress since. Other than that, Gretty 4.x should be in a usable state!

boris-petrov commented 3 years ago

@f4lco, @lipnitsk - version 4.0.0 is released. I decided to not do a beta or RC because I don't know how. :smile: If there are any issues, we can always release a 4.0.1. Thanks all!