On Fri, Dec 11, 2020 at 10:32 PM Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
> Hi Thiago, > Hello! > 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. > Indeed. I ran into this problem with tapestry-geb. > So it is a major change according to semver. > Have you considered bumping the major version to 6.x? > For historical reasons, no. We've promised in the past there wouldn't be a Tapestry 6, since Tapestry 5 is a complete rewrite and completely incompatible with Tapestry 4, and other past versions are in the same situation. Tapestry had an image of a framework that rewrites itself after a few years and one major version. So, actually, 5.7.0 will actually be version 7.0 of the Tapestry 5 framework. This mass moving of classes won't need to happen again, so I think having 6 as the major version isn't necessary. > Also if we're doing this change, maybe flatten existing interfaces left > from previous releases, like Asset2, ServiceDef2, ServiceDef3, etc.? > I thought about that too, but didn't implement it. Good idea. Would you volunteer to do that? :) Cheers! > > 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 > -- Thiago
