Split package caused by DisableStrictChecks

[Volker Lamp <vl...@apache.org>]

Hello, Tapestry developers,

The @DisableStrictChecks annotation 
(https://issues.apache.org/jira/browse/TAP5-2655) causes a split package 
(in terms of Java 9 modules) with tapestry-core.

In my opinion, the best fix is to move it into tapestry-core. While the 
jar would change, the package would stay the same, causing fewer to no 
migration issues - hopefully.

Keeping it in tapestry5-annotations would imply moving it to another 
package, definitely causing some sort of migration efforts.

Keen to hear your thoughts.

Thanks,

Volker

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

Re: Split package caused by DisableStrictChecks

[Volker Lamp <vl...@apache.org>]

Hello Thiago

> Volker, have you been using Tapestry in a fully modular webapp? I'm
> curious to know how you noticed the unintended split package.

The compiler complained about the split package as I was looking into what it would take to make our webapp use Java 9 modules.

Cheers,

Volker

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

Re: Split package caused by DisableStrictChecks

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

I tried moving the annotations from tapestry-core to
tapestry5-annotations and got a number of compilation errors due to
the annotations using tapestry-core classes, so I reached the
conclusion that it's not really feasible to do it for all annotations.
I moved @DisableStrictChecks to tapestry-core.

Volker, have you been using Tapestry in a fully modular webapp? I'm
curious to know how you noticed the unintended split package.

What about a release next week? I've just committed CORS support and
I'm looking forward to get it released. :) In addition, we already
have 10 tickets in 5.8.2:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20TAP5%20AND%20fixVersion%20%3D%205.8.2.

Cheers!

On Tue, May 24, 2022 at 2:38 PM Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
>
> On Sat, May 21, 2022 at 9:12 AM Volker Lamp <vl...@apache.org> wrote:
> > Hello Thiago and Ben,
>
> Hello!
>
> > I think you got that confused, Thiago. At this time, @DisableStrictChecks is in org.apache.tapestry5.annotations within tapestry5-annotations (not tapestry-core). All other annotation of package org.apache.tapestry5.annotations are in tapestry-core.
>
> Oh, sorry, I definitely got it the wrong way around.
>
> > From the discussion so far I understand the consensus is to have all annotations in tapestry5-annotations. That is, the 54 files (53 annotations + package-info.java) currently living in tapestry-core would stay in the org.apache.tapestry5.annotations package but would move to tapestry5-annotations. This should be smooth for users, as tapestry-core has a transitive dependency on tapestry5-annotations (through tapestry-ioc) already. For clarity, a direct dependency to tapestry5-annotations should be added to tapestry-core.
> >
> > I created https://issues.apache.org/jira/browse/TAP5-2724 to take care of this.
>
> Agreed and thanks for creating the ticket and raising this issue in first place.
>
> >
> > Thanks,
> >
> > Volker
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
>
>
> --
> Thiago



-- 
Thiago

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

Re: Split package caused by DisableStrictChecks

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

On Sat, May 21, 2022 at 9:12 AM Volker Lamp <vl...@apache.org> wrote:
> Hello Thiago and Ben,

Hello!

> I think you got that confused, Thiago. At this time, @DisableStrictChecks is in org.apache.tapestry5.annotations within tapestry5-annotations (not tapestry-core). All other annotation of package org.apache.tapestry5.annotations are in tapestry-core.

Oh, sorry, I definitely got it the wrong way around.

> From the discussion so far I understand the consensus is to have all annotations in tapestry5-annotations. That is, the 54 files (53 annotations + package-info.java) currently living in tapestry-core would stay in the org.apache.tapestry5.annotations package but would move to tapestry5-annotations. This should be smooth for users, as tapestry-core has a transitive dependency on tapestry5-annotations (through tapestry-ioc) already. For clarity, a direct dependency to tapestry5-annotations should be added to tapestry-core.
>
> I created https://issues.apache.org/jira/browse/TAP5-2724 to take care of this.

Agreed and thanks for creating the ticket and raising this issue in first place.

>
> Thanks,
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>


-- 
Thiago

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

Re: Split package caused by DisableStrictChecks

[Volker Lamp <vl...@apache.org>]

Hello Thiago and Ben,

Thank you for picking this up and sharing your views.

> Oh, I should have thought of this before: since @DisableStrictChecks
> is in org.apache.tapestry5.annotations, but in tapestry-core, we can
> just move it to the same package in tapestry5-annotations. No
> backward-incompatible changes. Win-win! Other tapestry-core
> annotations like @InjectComponents are already there, so there's no
> need to create a org.apache.tapestry5.*core*.annotations package.

I think you got that confused, Thiago. At this time, @DisableStrictChecks is in org.apache.tapestry5.annotations within tapestry5-annotations (not tapestry-core). All other annotation of package org.apache.tapestry5.annotations are in tapestry-core.

From the discussion so far I understand the consensus is to have all annotations in tapestry5-annotations. That is, the 54 files (53 annotations + package-info.java) currently living in tapestry-core would stay in the org.apache.tapestry5.annotations package but would move to tapestry5-annotations. This should be smooth for users, as tapestry-core has a transitive dependency on tapestry5-annotations (through tapestry-ioc) already. For clarity, a direct dependency to tapestry5-annotations should be added to tapestry-core.

I created https://issues.apache.org/jira/browse/TAP5-2724 to take care of this.

Thanks,

Volker

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

Re: Split package caused by DisableStrictChecks

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

On Thu, May 19, 2022 at 4:33 AM Ben Weidig <be...@netzgut.net> wrote:

> Hi,

Hi!

> > It won't be backward compatible, but on the other hand it's just one
> annotation,
> > it's very new and I suppose there aren't many people using it,
> > if any (except my day job, which uses it in a handful of places).
>
> I'm using it, too!
> It really helps replacing some older stuff that needs to be extended
> without breaking everything else.

Oh, nice!

> But how do you deal with @InjectComponent in base classes?
> Maybe a boolean "allowMissing() default false" could be added to
> @InjectComponent,

I really like this idea.

> or @DisableStrictChecks could also target fields.

Hmm, I'm not sure I like this one. I really prefer adding something to
@InjectComponent like you suggested.

> I digress, that's another discussion.
>
> Moving just @DisableStrictChecks annotation to
> org.apache.tapestry5.*core*.annotations would still split the annotations

Well, it would in the sense of not having all annotations in a single
package, but we already don't have that, so I think this wouldn't be a
problem. Also, it's not a split in the Java module split package
sense, since it wouldn't be a package that appears in more than one
JAR.

> because all other core annotations are in org.apache.tapestry5.annotations.

Oh, I should have thought of this before: since @DisableStrictChecks
is in org.apache.tapestry5.annotations, but in tapestry-core, we can
just move it to the same package in tapestry5-annotations. No
backward-incompatible changes. Win-win! Other tapestry-core
annotations like @InjectComponents are already there, so there's no
need to create a org.apache.tapestry5.*core*.annotations package.

Cheers!

-- 
Thiago

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

Re: Split package caused by DisableStrictChecks

[Ben Weidig <be...@netzgut.net>]

Hi,

> It won't be backward compatible, but on the other hand it's just one
annotation,
> it's very new and I suppose there aren't many people using it,
> if any (except my day job, which uses it in a handful of places).

I'm using it, too!
It really helps replacing some older stuff that needs to be extended
without breaking everything else.
But how do you deal with @InjectComponent in base classes?
Maybe a boolean "allowMissing() default false" could be added to
@InjectComponent, or @DisableStrictChecks could also target fields.
I digress, that's another discussion.

Moving just @DisableStrictChecks annotation to
org.apache.tapestry5.*core*.annotations would still split the annotations
because all other core annotations are in org.apache.tapestry5.annotations.
But moving them would affect everyone, so it makes more sense to leave them
there for now.

Maybe wait until the next big update with more breaking changes, like
removing some deprecations or tweaking a few things (method signatures with
type bounds, functional interfaces, streams, etc.), and then move the rest
to have all annotations in a single jar.

Cheers
Ben

Re: Split package caused by DisableStrictChecks

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

On Fri, May 13, 2022 at 12:45 PM Volker Lamp <vl...@apache.org> wrote:

> Hello, Tapestry developers,

Hello, everyone!

> The @DisableStrictChecks annotation
> (https://issues.apache.org/jira/browse/TAP5-2655) causes a split package
> (in terms of Java 9 modules) with tapestry-core.

Oh, argh, I should have thought of that while creating that
annotation, specially because I had already done the work of avoiding
the way too many split packages Tapestry had before 5.7.0. Thanks so
much for spotting this!

> In my opinion, the best fix is to move it into tapestry-core. While the
> jar would change, the package would stay the same, causing fewer to no
> migration issues - hopefully.

Hmm, I think the best option is to move it to keep it in
tapestry5-annotations and move it to
org.apache.tapestry5.core.annotations. It won't be backward
compatible, but on the other hand it's just one annotation, it's very
new and I suppose there aren't many people using it, if any (except my
day job, which uses it in a handful of places). Also, we do have a
migration tool introduced with 5.7.0 for this kind of stuff, even if I
don't think it's necessary in this case. I do agree with Ben that
keeping annotations in the annotations JAR is the best way to go for
consistency.
-- 
Thiago

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

Re: Split package caused by DisableStrictChecks

[Ben Weidig <be...@netzgut.net>]

Hi Volker,

I'm not that versed in the Java module system, but as far as I understand,
the problem lies in using the same package
"org.apache.tapestry5.annotations" in tapestry-core and
tapestry-annotations?

* Moving @DisableStrictChecks to tapestry-core: As you wrote already, this
should be the least intrusive option. tapestry-core already has its
annotations in the package, and only a single class has to be moved without
any migration needed.

* Moving tapestry-core annotations to tapestry5-annotations: That might
makes sense from an organizational point of view.
But tapestry-annotation would need a .core.* package, maximizing the
migration effort. Leaving out the core-intermediate package wouldn't
require migration but would weaken the overall structure.

Both options have a certain appeal.

Moving a single file to its brethren in tapestry-core is the most
straightforward fix for the split package issue, and using an annotation
that is only available through the tapestry-ioc dependency if I read the
build.gradle correctly.
But being able to use tapestry-core annotations without including
tapestry-core itself might have advantages, too.

I think I'd prefer moving all annotations to tapestry5-annotations (without
an additional core package to minimize the migration effort) and including
tapestry5-annotations as a direct dependency.
That way, the org.apache.tapestry5.annotations package exists only in a
single project.

But I wouldn't be against just moving @DisableStrictChecks to
tapestry-core, either.

Cheers
Ben

On Fri, May 13, 2022 at 5:44 PM Volker Lamp <vl...@apache.org> wrote:

> Hello, Tapestry developers,
>
> The @DisableStrictChecks annotation
> (https://issues.apache.org/jira/browse/TAP5-2655) causes a split package
> (in terms of Java 9 modules) with tapestry-core.
>
> In my opinion, the best fix is to move it into tapestry-core. While the
> jar would change, the package would stay the same, causing fewer to no
> migration issues - hopefully.
>
> Keeping it in tapestry5-annotations would imply moving it to another
> package, definitely causing some sort of migration efforts.
>
> Keen to hear your thoughts.
>
> Thanks,
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>