Skip to content

Make Jetty version configurable via command line for testing new version or snapshot #44660

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

olamy
Copy link
Contributor

@olamy olamy commented Mar 11, 2025

Related to discussion around this jetty/jetty.project#12882

@olamy
Copy link
Contributor Author

olamy commented Mar 11, 2025

@wilkinsona ping.

@olamy olamy marked this pull request as ready for review March 11, 2025 03:39
@wilkinsona
Copy link
Member

wilkinsona commented Mar 11, 2025

As already discussed in the Jetty issue, I don’t think we should do this. Our build doesn’t need it and we could accidentally break it or remove it as it appears to be unneeded.

@wilkinsona wilkinsona closed this Mar 11, 2025
@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 11, 2025
@olamy
Copy link
Contributor Author

olamy commented Mar 11, 2025

Sadly this will not really help the jetty project to test new release with spring projects :(

@wilkinsona
Copy link
Member

We’re more than happy to help but I think there’s a better approach that will be more robust. Please see my latest comment in the Jetty issue.

@olamy
Copy link
Contributor Author

olamy commented Mar 11, 2025

Sure but if the dsl change again in the future our usage of the init script will fail again without any way for us to notice it.

@wilkinsona
Copy link
Member

It's not a DSL change that caused your init script to fail. The problem was that it assumed that the dependency management plugin was being used. That used to be the case for Spring Framework's build but it has never been the case for Spring Boot's build. The approach that I am proposing makes no assumptions about plugins that have applied and makes use of standard Gradle APIs. As such, it should be robust. Should breaking changes be made to Gradle's API in the future, the init script will now fail noticeably rather than silently doing nothing due to a missing plugin as it does now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants