Question about release 17

[Gregory Neil Jansen]

Hi Aaron,

I was reading release notes from 17 and planning to update the dependencies for my Quarkus-base app. Is creating my own quarkusBuild around Trellis dependencies still the best way to inject custom classes for REST, camel messaging, and storage?

I've been basing my build on the 0.16.3 release, but recently that started failing the quarkusBuild. Not sure if going to 17 would address it.

thanks for any advice,

Greg

Maybe you've seen this trace before:

Caused by: java.lang.IllegalArgumentException: wrong number of arguments
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at io.quarkus.gradle.tasks.QuarkusGenerateCode.prepareQuarkus(QuarkusGenerateCode.java:87)

--

Gregory N. Jansen
Research Software Architect
Advanced Information Collaboratory
School of Information Studies
University of Maryland in College Park

[Aaron Coburn]

Hi Greg,

Yes, that would still be the preferred approach. If you'd like a template for your build, have a look at the trellis-microprofile repository.

This commit shows what I had to do to upgrade from trellis 0.16.3 to 0.17.0

As for that particular stack trace, I haven't seen anything quite like that. The trellis-microprofile repo is using the latest version of Quarkus, so you might want to check on that.

Also, the 1.12 release of Quarkus changes the layout of generated JAR files, so if you have a Dockerfile, you may need to adjust that code. FWIW, I would recommend how Quarkus automatically generates containers (rather than relying on a Dockerfile): https://quarkus.io/guides/container-image

Cheers,

Aaron

--
You received this message because you are subscribed to the Google Groups "Trellis LDP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trellis-ldp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/CAK8%2BkyKQV55C3T4wWcrq1Bcmdxg_Jzr5341WP4R-gBMp6o91zg%40mail.gmail.com.

[Gregory Neil Jansen]

Thanks Aaron, this is exactly the guidance that I needed. The example project should indeed get me back on course as I am still fairly new to gradle projects.

Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/CAD4uyLfxggke9bprw4_TN9Pd_8258i_MzAF6pjZesf3_rFcHLg%40mail.gmail.com.

[Aaron Coburn]

Hi Greg,

And just so you know, Maven works great, too.

-Aaron

To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/CAK8%2Bky%2B9%2BqnVESnPMMiZLJ6tYkuu4oV-qJ7wLNMCP4D0dJAbGQ%40mail.gmail.com.

[Gregory Neil Jansen]

Many thanks. Gradle build scripting is powerful magic and I don't miss the angle brackets as much as I thought I would.

As with maven, the necessary complexities of the different plugins configs add up quickly and Trellis projects use a lot of them.

My demonstration-style project requires far less ceremony and release packaging, so I can carve off a lot of it. Along the way

I learn about a lot things that are also perfectly compatible with maven too.

Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/CAD4uyLfiYzWJVe1AHg2vEbSVKBYRU%3DzTGFEEVz8mH_RoXczQ1g%40mail.gmail.com.

[Gregory Neil Jansen]

To follow up, the microprofile project gave a good example that I have adapted to my needs. The result still bears some ambiguous dependencies, which I have to sort out. I suspect that some are entering via trellis-cassandra, but it remains to be seen. For the present, it has started exhausting the heap space during the configure project step..

[Gregory Neil Jansen]

I thought I'd come back to report success, since thread history often leaves that out.

I redesigned my project into two parts (so far), much like the trellis-microprofile project.

This is working well against 17.0 and I'll try it against 17.1 again after having figured out the

Dockerfile.legacy-jar migration. So now I have Quarkus working with Cassandra storage

and my little collection of custom beans.

My goal was to use Camel to route Trellis notifications through Kafka and from there back into

more distributed workflows. Instead I ended up shifting that strategy to use the MP reactive messaging

Kafka producer to achieve this more directly with fewer dependencies. Currently it simply forwards the

activity stream JSON to Kafka. After implementing this I noticed trellis-kafka does the same thing, but outside of MP.

The code is largely the same.

thanks again,

Greg

[Aaron Coburn]

Hi Greg, that's great to hear.

I'd definitely recommend using the MP reactive messaging system over trellis-kafka. The MP approach ends up being considerably more flexible, with a consistent configuration across different connectors. Plus, you could send messages directly to a camel context with MP reactive messaging.

https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/connectors/connectors.html

In fact, given that smallrye-reactive-messaging already supports JMS, AMQP, Kafka plus many others, it would probably be a good idea to just deprecate (and eventually remove) the trellis equivalents. One important advantage of the MP approach is that it does a better job of handling backpressure and overflow scenarios.

-Aaron

To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/CAK8%2Bky%2B%3DbHUXbxOmNi6ba3mVY1XWBHDcEN7a22FNJGZRAER3VA%40mail.gmail.com.