Roadmap proposal

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

Hello, Tapestry community!

I have some ideas for Tapestry's next steps and I'd like to receive your
input about them.

Tapestry 5.5 supports Java 12 bytecode. This is done through an embedded
copy of the ASM bytecode library. We change the package names so they don't
clash with the ASM version eventually used by other dependencies of your
project. A few other changes are also needed, the only one I recall right
now is changing one specific method visibility to public so it can be used
in Plastic.

For 5.6, since Java 14, a long term support release, was released last week
and I guess lots of people are eager to try it, I was thinking of grabbing
the latest stable version of ASM to pick up its support for Java 14
bytecode. We could have 5.6 released next month just for that and then have
later minor versions for fixes and improvements or wait a bit and have a
single release for everything. I prefer the first option.

For 5.7, I was thinking of implementing something suggested by more than
one people (I apologize for not recalling who): separating the page library
(i.e. all the support for pages, components and mixins) from the rest of
tapestry-core (i.e. the request handling part: HttpServletRequestFilter,
RequestFilter, Dispatcher, asset support, etc). Ilya also suggested the
possibility of separating corelib (the component library provided by
Tapestry out of the box) from the rest of the framework, an interesting
idea, but I'm not sure that's really needed. If you need you own version of
some components, you can use the ComponentOverride service. This way, for
example, you can have your own implementation of Grid and have it
automatically used in all <t:grid> or <div t:type="Grid"> usages. But I'm
open to different opinions. I'm actually inviting them, and I may even
change my opinions.  :)

Also for 5.7, I'm planning to make the Tapestry JARs proper Java 9 modules.
This will require moving classes, maybe a lot of them, from one package to
another, since a package cannot be in more than one module and Tapestry has
a number of cases of this.

Also for 5.7, build Tapestry with Java 11 instead of 8, which has mostly
reached its end of life already, not getting more updates and fixes from
Oracle unless you have a support contract. I don't want anyone sticking to
old Tapestry versions because they're still stuck with an old Java version,
but I guess we can agree Java 8 is pretty old by now. 2 major (i.e. LTS
releases) behind.

Comments? Suggestions? Ideas? Please post them here!

Cheers!

-- 
Thiago

Re: Roadmap proposal

["Vangel V. Ajanovski" <aj...@gmail.com>]

On 28.3.20 11:07, Dmitry Gusev wrote:
> It would definitely be nice to provide intermediate releases that support
> byte code for non-LTS versions to let us use newest language features.

+1 for ability to use newer Java versions

I would also like to see ability to use new Hibernate versions

If these two things are not too complicated to do on you own, then maybe 
a guide how to do it yourself would server many.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Roadmap proposal

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Sat, Mar 28, 2020 at 7:07 AM Dmitry Gusev <dm...@gmail.com> wrote:

> Hi Thiago,
>

Hello!


> Just a small correct, the next LTS is Java 17 to be released in 2021.
>

Thanks for the info!


> It would definitely be nice to provide intermediate releases that support
> byte code for non-LTS versions to let us use newest language features.
>

Indeed. It was never out of my plans, though. It's just a case of updating
the embedded ASM version and cut a new release.


> Not sure about java 9 modules though, will tapestry development actually
> benefit from them?
>

I believe so. We can actually prevent anyone from using internal classes
directly, something that improves modularity and backward compatibility.


> Or end projects built on top of/with tapestry?
>

Projects which are already modules themselves would benefit from it.


> Are there any projects apart from JDK itself benefiting from modules?
>

I don't have a list right now, but I guess there's definitely a number of
other projects out there already modularized.


> Would be nice to hear users feedback here.
>

Yup!

One idea that crossed my mind few times is adding support for ByteBuddy in
> favour of, or in addition to tapestry-plastic.
> Mostly to improve generics support in proxies, but may also benefit from
> other latest language features, not existing and newcoming.
>

We already have genericsresolver-guava that deals with generics better than
Tapestry-IoC itself does. Dmitry, is this what you're talking about? If
yes, then we can create a ByteBuddy version of that, but it's not in my own
plans. Or is it about replacing Plastic or replacing ASM in Plastic? That
would a huuuuuuuuuuuuuuuuge project I definitely don't have the time for
that nor I believe that would be a good priority. Also, we embed ASM into
Tapestry-IoC for avoiding clashes with other ASM versions eventually used
by other dependencies of end user projects, so we would need to embed
ByteBuddy too for the same reason and that would still need a release for
dealing with newer bytecode.


>
> Regards,
> Dmitry
>
> On Fri, Mar 27, 2020 at 7:44 PM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > Hello, Tapestry community!
> >
> > I have some ideas for Tapestry's next steps and I'd like to receive your
> > input about them.
> >
> > Tapestry 5.5 supports Java 12 bytecode. This is done through an embedded
> > copy of the ASM bytecode library. We change the package names so they
> don't
> > clash with the ASM version eventually used by other dependencies of your
> > project. A few other changes are also needed, the only one I recall right
> > now is changing one specific method visibility to public so it can be
> used
> > in Plastic.
> >
> > For 5.6, since Java 14, a long term support release, was released last
> week
> > and I guess lots of people are eager to try it, I was thinking of
> grabbing
> > the latest stable version of ASM to pick up its support for Java 14
> > bytecode. We could have 5.6 released next month just for that and then
> have
> > later minor versions for fixes and improvements or wait a bit and have a
> > single release for everything. I prefer the first option.
> >
> > For 5.7, I was thinking of implementing something suggested by more than
> > one people (I apologize for not recalling who): separating the page
> library
> > (i.e. all the support for pages, components and mixins) from the rest of
> > tapestry-core (i.e. the request handling part: HttpServletRequestFilter,
> > RequestFilter, Dispatcher, asset support, etc). Ilya also suggested the
> > possibility of separating corelib (the component library provided by
> > Tapestry out of the box) from the rest of the framework, an interesting
> > idea, but I'm not sure that's really needed. If you need you own version
> of
> > some components, you can use the ComponentOverride service. This way, for
> > example, you can have your own implementation of Grid and have it
> > automatically used in all <t:grid> or <div t:type="Grid"> usages. But I'm
> > open to different opinions. I'm actually inviting them, and I may even
> > change my opinions.  :)
> >
> > Also for 5.7, I'm planning to make the Tapestry JARs proper Java 9
> modules.
> > This will require moving classes, maybe a lot of them, from one package
> to
> > another, since a package cannot be in more than one module and Tapestry
> has
> > a number of cases of this.
> >
> > Also for 5.7, build Tapestry with Java 11 instead of 8, which has mostly
> > reached its end of life already, not getting more updates and fixes from
> > Oracle unless you have a support contract. I don't want anyone sticking
> to
> > old Tapestry versions because they're still stuck with an old Java
> version,
> > but I guess we can agree Java 8 is pretty old by now. 2 major (i.e. LTS
> > releases) behind.
> >
> > Comments? Suggestions? Ideas? Please post them here!
> >
> > Cheers!
> >
> > --
> > Thiago
> >
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>


-- 
Thiago

Re: Roadmap proposal

[Charles Roth <cr...@thedance.net>]

We've had some problems with java 9 modules and building our (large) app 
with Tapestry 5.5.

They may be *our* problems, but we would definitely welcome Tapestry 
"rationalizing" the package & module structure as suggested by the java 
9 modules.

Thanks!

On 3/28/2020 6:07 AM, Dmitry Gusev wrote:
> Hi Thiago,
>
> Just a small correct, the next LTS is Java 17 to be released in 2021.
>
> It would definitely be nice to provide intermediate releases that support
> byte code for non-LTS versions to let us use newest language features.
>
> Not sure about java 9 modules though, will tapestry development actually
> benefit from them?
> Or end projects built on top of/with tapestry?
> Are there any projects apart from JDK itself benefiting from modules?
> Would be nice to hear users feedback here.
>
> One idea that crossed my mind few times is adding support for ByteBuddy in
> favour of, or in addition to tapestry-plastic.
> Mostly to improve generics support in proxies, but may also benefit from
> other latest language features, not existing and newcoming.
>
> Regards,
> Dmitry
>
> On Fri, Mar 27, 2020 at 7:44 PM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> Hello, Tapestry community!
>>
>> I have some ideas for Tapestry's next steps and I'd like to receive your
>> input about them.
>>
>> Tapestry 5.5 supports Java 12 bytecode. This is done through an embedded
>> copy of the ASM bytecode library. We change the package names so they don't
>> clash with the ASM version eventually used by other dependencies of your
>> project. A few other changes are also needed, the only one I recall right
>> now is changing one specific method visibility to public so it can be used
>> in Plastic.
>>
>> For 5.6, since Java 14, a long term support release, was released last week
>> and I guess lots of people are eager to try it, I was thinking of grabbing
>> the latest stable version of ASM to pick up its support for Java 14
>> bytecode. We could have 5.6 released next month just for that and then have
>> later minor versions for fixes and improvements or wait a bit and have a
>> single release for everything. I prefer the first option.
>>
>> For 5.7, I was thinking of implementing something suggested by more than
>> one people (I apologize for not recalling who): separating the page library
>> (i.e. all the support for pages, components and mixins) from the rest of
>> tapestry-core (i.e. the request handling part: HttpServletRequestFilter,
>> RequestFilter, Dispatcher, asset support, etc). Ilya also suggested the
>> possibility of separating corelib (the component library provided by
>> Tapestry out of the box) from the rest of the framework, an interesting
>> idea, but I'm not sure that's really needed. If you need you own version of
>> some components, you can use the ComponentOverride service. This way, for
>> example, you can have your own implementation of Grid and have it
>> automatically used in all <t:grid> or <div t:type="Grid"> usages. But I'm
>> open to different opinions. I'm actually inviting them, and I may even
>> change my opinions.  :)
>>
>> Also for 5.7, I'm planning to make the Tapestry JARs proper Java 9 modules.
>> This will require moving classes, maybe a lot of them, from one package to
>> another, since a package cannot be in more than one module and Tapestry has
>> a number of cases of this.
>>
>> Also for 5.7, build Tapestry with Java 11 instead of 8, which has mostly
>> reached its end of life already, not getting more updates and fixes from
>> Oracle unless you have a support contract. I don't want anyone sticking to
>> old Tapestry versions because they're still stuck with an old Java version,
>> but I guess we can agree Java 8 is pretty old by now. 2 major (i.e. LTS
>> releases) behind.
>>
>> Comments? Suggestions? Ideas? Please post them here!
>>
>> Cheers!
>>
>> --
>> Thiago
>>
>
-- 
Charles Roth
he.him.his
734-717-6803
lookfar.caucus.com <http://lookfar.caucus.com>
Software Architect & Political activist
	
	<http://aavotes.org>

Re: Roadmap proposal

[Dmitry Gusev <dm...@gmail.com>]

Hi Thiago,

Just a small correct, the next LTS is Java 17 to be released in 2021.

It would definitely be nice to provide intermediate releases that support
byte code for non-LTS versions to let us use newest language features.

Not sure about java 9 modules though, will tapestry development actually
benefit from them?
Or end projects built on top of/with tapestry?
Are there any projects apart from JDK itself benefiting from modules?
Would be nice to hear users feedback here.

One idea that crossed my mind few times is adding support for ByteBuddy in
favour of, or in addition to tapestry-plastic.
Mostly to improve generics support in proxies, but may also benefit from
other latest language features, not existing and newcoming.

Regards,
Dmitry

On Fri, Mar 27, 2020 at 7:44 PM Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:

> Hello, Tapestry community!
>
> I have some ideas for Tapestry's next steps and I'd like to receive your
> input about them.
>
> Tapestry 5.5 supports Java 12 bytecode. This is done through an embedded
> copy of the ASM bytecode library. We change the package names so they don't
> clash with the ASM version eventually used by other dependencies of your
> project. A few other changes are also needed, the only one I recall right
> now is changing one specific method visibility to public so it can be used
> in Plastic.
>
> For 5.6, since Java 14, a long term support release, was released last week
> and I guess lots of people are eager to try it, I was thinking of grabbing
> the latest stable version of ASM to pick up its support for Java 14
> bytecode. We could have 5.6 released next month just for that and then have
> later minor versions for fixes and improvements or wait a bit and have a
> single release for everything. I prefer the first option.
>
> For 5.7, I was thinking of implementing something suggested by more than
> one people (I apologize for not recalling who): separating the page library
> (i.e. all the support for pages, components and mixins) from the rest of
> tapestry-core (i.e. the request handling part: HttpServletRequestFilter,
> RequestFilter, Dispatcher, asset support, etc). Ilya also suggested the
> possibility of separating corelib (the component library provided by
> Tapestry out of the box) from the rest of the framework, an interesting
> idea, but I'm not sure that's really needed. If you need you own version of
> some components, you can use the ComponentOverride service. This way, for
> example, you can have your own implementation of Grid and have it
> automatically used in all <t:grid> or <div t:type="Grid"> usages. But I'm
> open to different opinions. I'm actually inviting them, and I may even
> change my opinions.  :)
>
> Also for 5.7, I'm planning to make the Tapestry JARs proper Java 9 modules.
> This will require moving classes, maybe a lot of them, from one package to
> another, since a package cannot be in more than one module and Tapestry has
> a number of cases of this.
>
> Also for 5.7, build Tapestry with Java 11 instead of 8, which has mostly
> reached its end of life already, not getting more updates and fixes from
> Oracle unless you have a support contract. I don't want anyone sticking to
> old Tapestry versions because they're still stuck with an old Java version,
> but I guess we can agree Java 8 is pretty old by now. 2 major (i.e. LTS
> releases) behind.
>
> Comments? Suggestions? Ideas? Please post them here!
>
> Cheers!
>
> --
> Thiago
>


-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com