Hi Thiago, This release has a significant change in packages, none of the existing 3rd-party tapestry libraries will be compatible with this release -- they all will need recompilation and mentioned fixes, even if they don't use Java 9 modules.
So it is a major change according to semver. Have you considered bumping the major version to 6.x? Also if we're doing this change, maybe flatten existing interfaces left from previous releases, like Asset2, ServiceDef2, ServiceDef3, etc.? Regards, Dmitry On Wed, Dec 9, 2020 at 1:38 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, community! > > We're close to releasing Tapestry 5.7.0, which I'd love to have it released > before the end of year holidays to end this troubled year with something > nice. Since there's going to be larger changes than usual, I'd like to > invite the community to test it on their projects a bit to eventually catch > some regressions the team and the unit tests couldn't catch yet. You can > see a list of all changes in > > https://issues.apache.org/jira/issues/?jql=project%20=%20TAP5%20AND%20fixVersion%20=%205.7.0 > until a proper release notes page is added to the website. > > Tapestry 5.7.0-SNAPSHOT JARs were uploaded to the ASF's Maven snapshots > repository at https://repository.apache.org/content/groups/snapshots/. > > Biggest change is making Tapestry easier to use in modularized (i.e. Java > 9+ modules) projects. The work on this was done in 2 major parts and a > small one: > * Avoiding split packages. In other words, packages that are present in > more than one JAR. We had to move lots of Tapestry classes around > JARs/subprojects since there were many and populous split packages. > * Providing automatic module names, all using the formula > "org.apache.tapestry.[adapted JAR name]", where [adapted JAR name] is the > current JAR name with 'tapestry-', dashes and the character '5' removed. > For example, tapestry5-annotations automatic module name is > org.apache.tapestry.annotations. Creation of module-info.java files are > left for the future. > * A simple migration tool to update fully qualified class names in Java > source files for classes which were moved and/or renamed. It's basically a > search-and-replace using a table of (old class name -> new class name) > extracted out of Git commits. > > To run this migration tool, download the JAR at > > https://repository.apache.org/content/groups/snapshots/org/apache/tapestry/tapestry-version-migrator/5.7.0-SNAPSHOT/tapestry-version-migrator-5.7.0-20201208.195518-8.jar > and run "java > -jar tapestry-version-migrator-5.7.0-20201208.195518-8.jar upgrade 5.7.0" > (without quotes). It will process all .java files found in the current > folder and its subfolders, recursively. > > Since the stuff above was going to be needed anyway, I've also seized the > opportunity to separate the Tapestry request pipeline classes (i.d. > HttpServletRequestFilter, RequestFilter, Dispatcher, etc) into a new > subproject/JAR, tapestry-http, which can be used without tapestry-core, > which includes the page/component framework and the asset handling classes. > > The other breaking change in 5.7.0 is changing the TypeCoercer service from > having an unordered configuration to a mapped one. This was done so it's > very clear when a coercion is overriden. Here's a real example from > Tapestry itself: if you had a contribution method like this: > > @Contribute(TypeCoercer.class) > public static void provideCoercions(Configuration<CoercionTuple> > configuration) > { > configuration.add(CoercionTuple.create(String.class, > JSONObject.class, new StringToJSONObject())); > } > > it should be changed to this: > > public static void > provideCoercions(MappedConfiguration<CoercionTuple.Key, CoercionTuple> > configuration) > { > CoercionTuple<String, JSONObject> stringToJsonObject = > CoercionTuple.create(String.class, JSONObject.class, new > StringToJSONObject()); > configuration.add(stringToJsonObject.getKey(), stringToJsonObject); > } > > 5.7.0 is built with Java 11 (first long-term support version after Java 9), > but targeting Java 8 bytecode, so It should be able to run on Java 8 to 14. > > Please post your findings here in the mailing list so we can coordinate the > creation of Jira tickets and get this new version ready to be voted and > released in the next 2 weeks. > > Thanks in advance! Happy testing! > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
