Re: Dependencies on previous releases / Use of [8.0,) in examples
"tomee-webaccess-7.0.0.war" is only used to participate in a
StripVersionTest: "tomee-webaccess-7.0.0.war" -> "tomee-webaccess".
Imho, it could basically be an empty WAR file, i.e. we could build a
"fake" war during our build and reference it.
Same holds for the (outdated) sirona-javaagent. We could also add a
"fake" javaagent (or any other modern and small javaagent) to test the
same functionality.
Question would be: Separate repository or include it in a module of
TomEE main (which one)?
Gruß
Richard
Am Montag, dem 21.02.2022 um 20:48 -0500 schrieb David Blevins:
> Nice,
>
> We're down to just one reference to a past release, tomee-webaccess-
> 7.0.0.war! We're using that to test the TomEE Maven Plugin.
>
> If someone wanted to cut it out, it looks like basically any war
> would work as long as it was in Maven Central. Maybe we could push
> something up there that's smaller than 6.9MB.
>
>
> -David
>
> > On Feb 21, 2022, at 3:49 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > +1
> >
> > I did the same in the 9.x branch.
> > I'm not a fan either because as you mentioned, it's not
> > reproducible.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Mon, Feb 21, 2022 at 8:03 AM Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> >
> > > 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
Re: Dependencies on previous releases / Use of [8.0,) in examples
Nice,
We're down to just one reference to a past release, tomee-webaccess-7.0.0.war!
We're using that to test the TomEE Maven Plugin.
If someone wanted to cut it out, it looks like basically any war would work as
long as it was in Maven Central. Maybe we could push something up there that's
smaller than 6.9MB.
-David
> On Feb 21, 2022, at 3:49 AM, Jean-Louis Monteiro
> wrote:
>
> +1
>
> I did the same in the 9.x branch.
> I'm not a fan either because as you mentioned, it's not reproducible.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Feb 21, 2022 at 8:03 AM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
>
>> 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
Re: Jakarta EE API Uber jar
Let's cut a milestone of the jakartaee-api jar and keep cutting them till we're ready to get TomEE 9.0 final out the door. -David > On Feb 21, 2022, at 4:06 AM, Jean-Louis Monteiro > wrote: > > Hi all, > > I'll do some minor changes to the jakartaee-api jar. > I'd like to do a small release of it so we have a consistent and stable jar > to use. > > I found locally that sometimes the snapshot is pulled, sometimes not which > causes random failures. > > I think most of the work has been done. If we need some tweaks we can do on > the fly and do another release when we want, but at least we have 90% there > already. > > Any feedback or thoughts? > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com smime.p7s Description: S/MIME cryptographic signature
[GitHub] [tomee] dblevins merged pull request #817: Minor: Replaces Maven Range Syntax with plain versions in Examples
dblevins merged pull request #817: URL: https://github.com/apache/tomee/pull/817 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [tomee] rzo1 opened a new pull request #817: Minor: Replaces Maven Range Syntax with plain versions in Examples
rzo1 opened a new pull request #817: URL: https://github.com/apache/tomee/pull/817 as the title says -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Jakarta EE API Uber jar
I removed all of them already yep -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Feb 21, 2022 at 10:11 AM Zowalla, Richard < richard.zowa...@hs-heilbronn.de> wrote: > Hi, > > I guess, that this is also related to the range syntax thing for the EE > api - we should be consistent / use plain versions and avoid this hell > of dependency hassle. > > Gruß > Richard > > Am Montag, dem 21.02.2022 um 10:06 +0100 schrieb Jean-Louis Monteiro: > > Hi all, > > > > I'll do some minor changes to the jakartaee-api jar. > > I'd like to do a small release of it so we have a consistent and > > stable jar > > to use. > > > > I found locally that sometimes the snapshot is pulled, sometimes not > > which > > causes random failures. > > > > I think most of the work has been done. If we need some tweaks we can > > do on > > the fly and do another release when we want, but at least we have 90% > > there > > already. > > > > Any feedback or thoughts? > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com >
Re: Jakarta EE API Uber jar
Hi, I guess, that this is also related to the range syntax thing for the EE api - we should be consistent / use plain versions and avoid this hell of dependency hassle. Gruß Richard Am Montag, dem 21.02.2022 um 10:06 +0100 schrieb Jean-Louis Monteiro: > Hi all, > > I'll do some minor changes to the jakartaee-api jar. > I'd like to do a small release of it so we have a consistent and > stable jar > to use. > > I found locally that sometimes the snapshot is pulled, sometimes not > which > causes random failures. > > I think most of the work has been done. If we need some tweaks we can > do on > the fly and do another release when we want, but at least we have 90% > there > already. > > Any feedback or thoughts? > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com smime.p7s Description: S/MIME cryptographic signature
Jakarta EE API Uber jar
Hi all, I'll do some minor changes to the jakartaee-api jar. I'd like to do a small release of it so we have a consistent and stable jar to use. I found locally that sometimes the snapshot is pulled, sometimes not which causes random failures. I think most of the work has been done. If we need some tweaks we can do on the fly and do another release when we want, but at least we have 90% there already. Any feedback or thoughts? -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
Re: SXC JAXB from codehaux
Hey David, Thanks, I ended up finding your repo and putting all the pieces together. Good to have this summary in the mailing list though. I'm still not sure if it is worth it or not. We would need to measure it on different sets of applications. For the moment, I have bytecode updated it as well as other libraries I can't update or move to Jakarta at the minute. https://github.com/apache/tomee/tree/tomee-9.x-initial/deps -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Wed, Feb 16, 2022 at 4:42 PM David Blevins wrote: > > On Feb 16, 2022, at 9:28 AM, Zowalla, Richard < > richard.zowa...@hs-heilbronn.de> wrote: > > > > The list archive does not contain any useful information regarding sxc. > > Note the list archive frustratingly searches only the last month's worth > of mail by default. Try this link: > > - https://lists.apache.org/list?dev@tomee.apache.org:lte=20y > > Here's a couple threads with information: > > - "SXC" February 6, 2019 >https://lists.apache.org/thread/6h40wo6vfgrspjt2vzzfkpm8k2w42ym4 > > - "XML performance improvement" December 10, 2012 >https://lists.apache.org/thread/f5bnv2nz917pjz8zyh7ktx6ngtysgron > > Here's the source code: > > - https://github.com/dblevins/sxc > > From the 2012 email, the key part from the last link, "We load 5,000 - > 6,000 classes when TomEE boots and nearly 4,000 are JAXB generated." My > memory is that this was over 50% of our start time. > > As a reference, generating classes in advance is basically one of the key > things that makes Quarkus fast and the SXC/generation optimization a > significant part of why we were faster to boot than everyone else in the > pre-Quarkus days. The concept is valid and we definitely need to do > significantly more of it, but there is a valid question on if this codebase > is worth investment. > > I don't think it's worth significant investment, but I don't think we > should remove it until we can replace it with something equivalent or > better. If I had to do this again, I'd likely investigate if there's some > way to do this with extending JAXB via the TomEE Patch Plugin. > > My advice would be to bytecode translate it for now if we can. > > > -David > >
Re: Dependencies on previous releases / Use of [8.0,) in examples
+1
I did the same in the 9.x branch.
I'm not a fan either because as you mentioned, it's not reproducible.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Feb 21, 2022 at 8:03 AM Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:
> 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?
> >
> >
>
