Re: Dependencies on previous releases / Use of [8.0,) in examples
I think, that we need to totally avoid the range syntax in our
examples. We also use it for the EE API and some other things in there.
In total, it leads to (non) reproducable builds (as you described).
I am strongly +1 for replacing the range syntax by plain versions in
the examples.
Gruß
Richard
Am Sonntag, dem 20.02.2022 um 22:51 -0500 schrieb David Blevins:
> I've been digging through the build trying to eliminate dependencies
> older releases.
>
> We've been inconsistently updating the versions in the examples, so
> I've gone and fixed a few of those. We had some tools like the TomEE
> Patch Plugin indirectly pulling 8.0.0-M3 artifacts -- now fixed.
>
> One of the things adding to the issue is the use of
> `[8.0,)` as the TomEE version in our examples.
>
> This looks like a very well-intentioned way to get the latest version
> and avoid always having to update versions in examples. What I'm
> seeing in practice is that it behaves very inconsistently from
> example to example for reasons that are unclear.
>
> For example in the example `javamail-velocity` it downloads stuff
> from 8.0.7, 8.0.8, 8.0.9 and 8.0.10-SNAPSHOT. In fact if you build
> offline without those versions in your m2 repo, you'll get a build
> failure. If you'd like to try, here's a quick way to delete the last
> few releases while leaving your 8.0.11-SNAPSHOTs intact:
>
> $ rm -r ~/.m2/repository/org/apache/tomee/*/8.0.{7,8,9,10}*
> $ rm -r
> ~/.m2/repository/org/apache/tomee/bom/boms/8.0.{7,8,9,10}*
>
> Ultimately this means our build is actually dependent on previous
> releases. Here's the full list of old release binaries our build
> needs to function:
>
> - https://gist.github.com/dblevins/c86f302c8a5b2afa4fecea905ad583fb
>
> I don't see a way to eliminate these without eliminating our
> `[8.0,)` usage.
>
> Any thoughts?
>
>
smime.p7s
Description: S/MIME cryptographic signature
Dependencies on previous releases / Use of [8.0,) in examples
I've been digging through the build trying to eliminate dependencies older
releases.
We've been inconsistently updating the versions in the examples, so I've gone
and fixed a few of those. We had some tools like the TomEE Patch Plugin
indirectly pulling 8.0.0-M3 artifacts -- now fixed.
One of the things adding to the issue is the use of `[8.0,)`
as the TomEE version in our examples.
This looks like a very well-intentioned way to get the latest version and avoid
always having to update versions in examples. What I'm seeing in practice is
that it behaves very inconsistently from example to example for reasons that
are unclear.
For example in the example `javamail-velocity` it downloads stuff from 8.0.7,
8.0.8, 8.0.9 and 8.0.10-SNAPSHOT. In fact if you build offline without those
versions in your m2 repo, you'll get a build failure. If you'd like to try,
here's a quick way to delete the last few releases while leaving your
8.0.11-SNAPSHOTs intact:
$ rm -r ~/.m2/repository/org/apache/tomee/*/8.0.{7,8,9,10}*
$ rm -r ~/.m2/repository/org/apache/tomee/bom/boms/8.0.{7,8,9,10}*
Ultimately this means our build is actually dependent on previous releases.
Here's the full list of old release binaries our build needs to function:
- https://gist.github.com/dblevins/c86f302c8a5b2afa4fecea905ad583fb
I don't see a way to eliminate these without eliminating our
`[8.0,)` usage.
Any thoughts?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
smime.p7s
Description: S/MIME cryptographic signature
Potential JAX-RS application deployment issues (how to help)
I did some work to improve the logging for JAX-RS Applications (TOMEE-3844). There's a decent chunk of code to create an ApplicationData instance that has information about what Resources and Providers we actually deploy and where they came from (i.e. if they were explicitly configured or discovered via the classpath). At some point we'll want to use that ApplicationData instance in the actual deployment code, but that's just a side note. There are a couple red flags I think really need more investigation if someone wants to dig in. - We always add @Provider classes found in the classpath. JAX-RS 2.1 section 2.3.2 seems to imply that we should only discover annotated providers and resources from the classpath if getClasses() and getSingletons() both return nothing. There clearly are not tests for this in the Jakarta EE 9.1 TCK as we passed it. This needs some research and potentially a conversation in the Jakarta Rest mailing list. - We do not use the singleton instances provided by Application.getSingltons(). Instead we always create our own instances and hand those to CXF. If as a user you constructed the singleton with some state and expect to have that state at runtime, you will not get what you want. Some research on what other implementations do and what the spec has to say would be good. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com smime.p7s Description: S/MIME cryptographic signature
