Quarkus as a build tool

[Stuart Douglas]

Hi Everyone,

I have been thinking a bit about making our own Quarkus based build system. Within the team we have talked a bit about how Java is harder to approach than node etc as the build tools are more complex. Given that Quarkus already can do almost everything a build system can do, I am thinking maybe we can change that. 

I think we could add basic build capabilities to the CLI, so that this is all that is needed to build a Quarkus project. We would create a layout that looks like this:

quarkus.json

src/Foo.java

test/FooTest.java

Which should be very similar to what node (and other language) developers are familiar with. quarkus.json would contain the (optional) coordinates, the dependencies, the Java version (so you don't even need Java installed), and any config that would normally go in application.properties. Build/run would be done entirely from the CLI, but would pretty much delegate everything to Quarkus itself (i.e. use Quarkus existing compiler support to do compilation, Quarkus will build the output target etc). This build will not really be customisable at all, outside of features that are provided by Quarkus itself and its extensions (which is actually pretty customisable). E.g. if we wanted to add code formatting support we would add it to the compiler used in hot reload, we would not support it as a specialized plugin in the build system.

There would also be a command to turn this into a maven/gradle project, if you need something more customizable.

Basically this is a layout that will be super familiar to node and other scripting language developers, provide a very similar development experience, and should be very 'low friction' to get going with. In many ways it will provide a better experience, once you factor in dev services, continuous testing and the ability to easily generate docker images. This is not supposed to be a replacement for Maven/Gradle, but will be aimed at people who are not experienced Java developers but want to try out Quarkus. 

This feels very similar to what jbang is trying to do, but is also a bit different, although hopefully we can leverage JBang as much as possible.

Implementation wise we actually have a lot of the pieces we already need for this (compiler support, resolver support, the ability to build an archive), but they are not really usable in this way, so the first step will be a big refactoring project to try and clean up our bootstrap/workspace code to make this possible, and to add a clean SPI between Maven/Gradle/JBang support, as will as making the dev mode workspace concept more generic (this will have other benefits as well, as it should help out the Kogito team with gradle support for example). Once this refactoring is complete then in theory there should not be much code required to actually make the 'build system' part work, as in theory it will just be some glue code to wire up our chosen workspace layout.

This would be a big job, most of it is refactoring and improvements that are worth doing anyway.

Thoughts?  

Stuart

[Ken Finnigan]

I think it would be really interesting to see done, in addition to the benefits of general refactoring.

Would be very interesting for small projects as well even for those from the Java landscape looking for a simple build process.

Ken

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com.

[Georgios Andrianakis]

I understand the reasoning here, but I am sceptical whether developers with more than a couple years of experience would actually want to learn something other than Maven or Gradle...

Furthermore, although probably relatively easy to implement, there would be no IDE support for this for some time, which means that a good amount of users would likely steer clear of it

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com.

[Andy Damevin]

As tempting as it is, I tend to agree with Georgios and his arguments.

Wouldn't jbang be closer to what we are looking to achieve?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n7u0T8L5Oc_iN9jzb0Z2q9TUCUYH0JgpgNho49E7cwBA%40mail.gmail.com.

--

Andy Damevin

[Alexey Loubyansky]

I totally support this effort. IMO, it's worth researching it even if it might not become the number one build tool for the Quarkus apps (there is actually no such objective at this point, afaiu).

The way I see it, this effort would be valuable from a couple of perspectives. While the primary aim is presented as a build tool, to get there we'd need to do a refactoring of the bootstrap parts. And I find that alone as a worthwhile goal and highly necessary actually. It's really about time we do that after all these years of bending it in various ways. E.g. we tried to introduce support for JBang projects. Nobody thought it was a bad idea but it was a struggle due to some parts of the bootstrap mechanism not being flexible enough. It may also help improve integration with Gradle. Once we improve those parts, it will not only make the JBang integration better but will open up new possibilities to support projects like Stuart described that looks like an evolution of the JBang-Quarkus tandem.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P6AWxXhuwYxzLBAriek%2BiHFey36DuaT_TbVn2OD-Kw3fQ%40mail.gmail.com.

[Paul Carter-Brown]

I get the point about it being a low-friction entry point, but then at the same time if it's not as capable as maven/gradle then people will end up cursing the fact they need to use another tool when their project becomes "real". I say another tool, cause sure if it's a simple Quarkus app with some extensions then maybe it's easy enough, but surely out in the wild, I can't be the only one that uses BOM's and Archetypes, and Dependabot and maven profiles and IDE integration showing dependency management and navigation from project to project. Our IDE's "know" how to use maven to see what one is dependent on. Right-click on something and say "download sources". IDE debugging... How will this all work?

The refactoring etc may be a great idea, but I wouldn't want to see a new default build tool/ideology.

Just my 2c. 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJ97idHzofUK6CqSoFZFcB3jL9ezxMx-%3DMay29xwQeyMmddMKw%40mail.gmail.com.

[Erin Schnabel]

Refactoring alone would maybe let us support gradle properly (instead of wrapping/mapping/grafting our maven-based behavior atop gradle concepts).

I’ve said before that I would prefer keeping some of the file structure (src/main/, src/test), as it would be familiar to existing Java devs, and would help those coming from other languages understand other java projects (and would mean less change if something needs to “grow up” into the existing Java tooling ecosystem).

But IDE support (e.g. understanding dependencies) is a limitation (we would be on the hook to work with the Developer Tools teams to update the Quarkus IDE extensions to learn how to understand dependencies declared this way.. )

… 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAO8YPTQiyfmPn3W2p7TqCcKnvVjQ2gfniTsQ9mSt53EC9JTy4g%40mail.gmail.com.

--

Thanks,

Erin

 

------
Erin Schnabel <ebul...@redhat.com>

@ebullientworks

[Georgios Andrianakis]

On Tue, Aug 24, 2021, 10:04 Alexey Loubyansky <alexey.l...@redhat.com> wrote:

I totally support this effort. IMO, it's worth researching it even if it might not become the number one build tool for the Quarkus apps (there is actually no such objective at this point, afaiu).

I completely agree with this. A comprehensive refactoring would be very beneficial.

I just personally don't see the idea of adding a simplified build tool taking off.

I mean I would enjoy working on such a tool and improving the user experience, but at the same time I am skeptical of how useful it would be in the real world

[William Burke]

+1 here, but it has to have more than incremental improvements over maven/gradle.  Think like developing functions/lambdas where you don't write any pom.xml code and you dont have to do everythign in one file like jbang.   And an extension system that can also resolve tooling.  I've discussed this before.

This should all be in conjunction with CLI.  

Would be worth it to experiment with this to see if it gains any traction.  I'll reiterate again:  must leapfrog maven/gradle, nobody will buy into incremental improvements.

On Mon, Aug 23, 2021 at 8:36 PM Stuart Douglas <sdou...@redhat.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com.

--

Bill Burke

Red Hat

[Max Rydahl Andersen]

> I understand the reasoning here, but I am sceptical whether developers
> with
> more than a couple years of experience would actually want to learn
> something other than Maven or Gradle...

Its not for everyone for sure but as Alexey and Stuart points out lots
of this
will also help current maven, gradle and jbang support.

> Furthermore, although probably relatively easy to implement, there
> would be
> no IDE support for this for some time, which means that a good amount
> of
> users would likely steer clear of it

so what kind of IDE support are you after ? jbang has IDE support (by
generating maven/gradle/eclipse files which every IDE understands).
Currently its done via a temporary symbolically project layout but I
know how and plan to implment so you can get IDE support as in content
assist/refactoring/run/debug working for the project without symbolic
linking.

That will give us IDE support from day one - and if we make it
successful we can get more native support added to IDE's over time.

This is btw. the same thing Gradle did in its early days - had a plugin
to generate IDE specific files to make it work until IDE's picked up
implementing native support.

So this would not be a concern IMO.

/max

>>> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n7u0T8L5Oc_iN9jzb0Z2q9TUCUYH0JgpgNho49E7cwBA%40mail.gmail.com.

[Max Rydahl Andersen]

On 24 Aug 2021, at 19:56, William Burke wrote:

> +1 here, but it has to have more than incremental improvements over
> maven/gradle. Think like developing functions/lambdas where you don't
> write any pom.xml code and you dont have to do everythign in one file
> like
> jbang.

jbang supported multiple files for over a year now - just saying :)

> And an extension system that can also resolve tooling. I've
> discussed this before.

"resolve tooling" ?

you do realise jbang's integration works by an extension model ?

> This should all be in conjunction with CLI.

> Would be worth it to experiment with this to see if it gains any
> traction.
> I'll reiterate again: must leapfrog maven/gradle, nobody will buy
> into
> incremental improvements.

leapfrog in what way ? as in have all the features maven/gradle has with
super flexible multi module project notions or
in being super easy to use and work extremely well for microservice
style apps and can easily pick up existing maven/gradle generated
artefacts if needed ?

/max

>> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
>
> --
> Bill Burke
> Red Hat
>

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSp25pm%2B-D13g45SpYUCNncoh-6pVPZ7VycK5ty3dhZow%40mail.gmail.com.


/max
https://xam.dk/about

[Francois Green]

Instead of a tool just for Quarkus, maybe Red Hat would consider spearheading a community effort to create a lightweight build tool for inclusion in the JDK itself, something along the lines of Remi Forax's Pro. 

[Max Rydahl Andersen]

On 24 Aug 2021, at 23:30, Francois Green wrote:

Instead of a tool just for Quarkus, maybe Red Hat would consider
spearheading a community effort to create a lightweight build tool for
inclusion in the JDK itself, something along the lines of Remi Forax's Pro

https://github.com/forax/pro .

Do you know how that relates to https://github.com/sormuras/bach btw ?

In any case, I wish it was that easy, but the JDK team have historically not wished to enter this area
(for somewhat good reasons imo).

I raised to the JDK team at least recognise notion of maven dependency mechanism which is basically what jbang does - enable javac and java to
grok maven dependencies and you can get very far - it will take time and probably not happen soon. I'll keep trying though.

/max

https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
Bill Burke
Red Hat

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/7676d04a-3aaa-40f0-bdb4-30d5f56e96e9n%40googlegroups.com.

/max
https://xam.dk/about

[Georgios Andrianakis]

I am not sure. If I am going to be using a new build tool, I want to be able to do everything I can currently do in my IDE when it comes to Maven.

Things like automatic import and setup of the project, automatic updates when things change, ability to download sources, debugging, running application / tests with right click, seeing the dependencies graph.

Will all those things (and probably more I don't remember now) work from day 1?

[Max Rydahl Andersen]

Yes. It works today with jbang. 

[Georgios Andrianakis]

To be clear:

I want to do idea . and have everything automatically setup for me. Will that work?

I am pretty sure that doesn't work with the jbang workflow... And FWIW when I did try the IDE integration (a while back), things were not working for me...

If we can get things to work (without any extra configuration on the users part), then awesome (I personally don't use CLIs and I know I am not the only one).

If not, then I don't see the build tool part gaining any traction...

[Max Rydahl Andersen]

On 25 Aug 2021, at 8:51, Georgios Andrianakis wrote:

To be clear:
I want to do *idea** . *and have everything automatically setup for me.
Will that work?

Yes, if you before that have run i.e. jbang edit or maybe we make a quarkus edit commond.

I am pretty sure that doesn't work with the jbang workflow... And FWIW when
I did try the IDE integration (a while back), things were not working for
me...

todays version of the above is

jbang edit --open=idea main.java

This is the command that today uses a temporary symbolic link generated project but which in future
will be updated to have the IDE required files put inside the project (just as you have them today when using normal maven/gradle project)

If we can get things to work (without *any* extra configuration on the

users part), then awesome (I personally don't use CLIs and I know I am not
the only one).

Can you explain what you mean here, calling idea . or mvn package is using a cli ...

If not, then I don't see the build tool part gaining any traction...

To be honest I think this issue of having fully working IDE integration from Day one is
too harsh a goal post to set. There is a trivial way to have it working and none of this
is forced upon anyone. Maven/Gradle is still the default and nothing of that will change.
IDE's supporting this natively will take time - but until then users can still use all
the usual features of IDE's by utilising the fact that IDE's today support maven/gradle fairly well.

If anything by doing the changes needed for this will improve the maven and gradle support too.

/max

<https://mailto:k...@kenfinnigan.me>>

wrote:

I think it would be really interesting to see done, in addition to
the
benefits of general refactoring.
Would be very interesting for small projects as well even for those
from
the Java landscape looking for a simple build process.
Ken
On Mon, Aug 23, 2021 at 8:36 PM Stuart Douglas <sdou...@redhat.com

<https://mailto:sdou...@redhat.com>>

<https://mailto:quarkus-dev%2Bunsu...@googlegroups.com> .

To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com>>>
<
https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer

.

--
You received this message because you are subscribed to the Google
Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to quarkus-dev...@googlegroups.com

<https://mailto:quarkus-dev%2Bunsu...@googlegroups.com> .

To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com>>
<
https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com?utm_medium=email&utm_source=footer

.

--
You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to quarkus-dev...@googlegroups.com

<https://mailto:quarkus-dev%2Bunsu...@googlegroups.com> .

To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n7u0T8L5Oc_iN9jzb0Z2q9TUCUYH0JgpgNho49E7cwBA%40mail.gmail.com
.

[Georgios Andrianakis]

On Wed, Aug 25, 2021 at 10:26 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

On 25 Aug 2021, at 8:51, Georgios Andrianakis wrote:

To be clear:
I want to do *idea** . *and have everything automatically setup for me.
Will that work?

Yes, if you before that have run i.e. jbang edit or maybe we make a quarkus edit commond.

I am pretty sure that doesn't work with the jbang workflow... And FWIW when
I did try the IDE integration (a while back), things were not working for
me...

todays version of the above is

jbang edit --open=idea main.java

This is the command that today uses a temporary symbolic link generated project but which in future
will be updated to have the IDE required files put inside the project (just as you have them today when using normal maven/gradle project)

If we can get things to work (without *any* extra configuration on the
users part), then awesome (I personally don't use CLIs and I know I am not
the only one).

Can you explain what you mean here, calling idea . or mvn package is using a cli ...

If we really want to get technical, no idea is not a CLI.

But yeah OK, I see your point. If we are going to build a new build tool, I'll have to install a new CLI - fine, that's fair.

What I really meant is that I don't ever want to have to use a framework specific CLI, be it spring boot, angular, ruby on rails, whatever.

If not, then I don't see the build tool part gaining any traction...

To be honest I think this issue of having fully working IDE integration from Day one is
too harsh a goal post to set. There is a trivial way to have it working and none of this
is forced upon anyone. Maven/Gradle is still the default and nothing of that will change.
IDE's supporting this natively will take time - but until then users can still use all
the usual features of IDE's by utilising the fact that IDE's today support maven/gradle fairly well.

I might be for you, but from where I stand, I value my IDE too much to work with something that will give me less features than what Maven / Gradle IDEs integration gives me. This is basically my spin on what Bill mentioned earlier

If anything by doing the changes needed for this will improve the maven and gradle support too.

Not sure what you are referring to here

[Max Rydahl Andersen]

>> To be clear:
>> I want to do *idea** . *and have everything automatically setup for
>> me.
>> Will that work?
>>
>> Yes, if you before that have run i.e. jbang edit or maybe we make a
>> quarkus
>> edit commond.
>>
>> I am pretty sure that doesn't work with the jbang workflow... And
>> FWIW
>> when
>> I did try the IDE integration (a while back), things were not working
>> for
>> me...
>>
>> todays version of the above is
>>
>> jbang edit --open=idea main.java
>>

>> This is the command that *today* uses a temporary symbolic link
>> generated
>> project but which in *future*

>> will be updated to have the IDE required files put inside the project
>> (just as you have them today when using normal maven/gradle project)
>>
>> If we can get things to work (without *any* extra configuration on
>> the
>> users part), then awesome (I personally don't use CLIs and I know I
>> am not
>> the only one).
>>
>> Can you explain what you mean here, calling idea . or mvn package is
>> using a cli ...
>>
>

> If we really want to get technical, no *idea* is not a CLI.

> But yeah OK, I see your point. If we are going to build a new build
> tool,
> I'll have to install a new CLI - fine, that's fair.

:)

> What I really meant is that I don't ever want to have to use a
> framework
> specific CLI, be it spring boot, angular, ruby on rails, whatever.

Thus this is not for you - stay with maven/gradle/jbang and its
advantages and disadvantages.

>> If not, then I don't see the build tool part gaining any traction...
>>
>> To be honest I think this issue of having fully working IDE
>> integration
>> from Day one is
>> too harsh a goal post to set. There is a trivial way to have it
>> working
>> and none of this
>> is forced upon anyone. Maven/Gradle is still the default and nothing
>> of
>> that will change.
>> IDE's supporting this natively will take time - but until then users
>> can
>> still use all
>> the usual features of IDE's by utilising the fact that IDE's today
>> support
>> maven/gradle fairly well.
>>
>
> I might be for you, but from where I stand, I value my IDE too much to
> work
> with something that will give me less features than what Maven /
> Gradle
> IDEs integration gives me. This is basically my spin on what Bill
> mentioned
> earlier

Sure - but if for any foreseeable time what happens is that you in the
IDE
are importing maven/gradle project generated by the build tool then you
have
all those features.

>> If anything by doing the changes needed for this will *improve* the

>> maven
>> and gradle support too.
>>
>
> Not sure what you are referring to here

Today we have quite some subtle bugs where extensions have to fall back
to do their own
maven/gradle project layout parsing/scanning (i.e. decorate has such
assumptions) and
there are challenges within kogito on having good gradle integration
because the core
have too hardcoded assumptions.

These got really exposed when we did the jbang integration and it is
today holding back how
smooth we can make jbang and gradle integration.

/max

[Georgios Andrianakis]

The point is this however: If I am a limited case, then this makes a lot of sense. If however I am part of the majority, then developing a whole new tool doesn't seem to make a tremendous amount of sense.

The refactoring of course is a whole different matter, that makes sense in any case

[Stuart Douglas]

The main use case for this is to make quarkus more accessible to non java developers. There are a lot of mode developers who have no idea about maven or grade but will find this approach super familiar.

It's not really about about replacing maven or grade, it's about making quarkus more accessible.

Stuart

[Georgios Andrianakis]

On Wed, Aug 25, 2021 at 12:30 PM Stuart Douglas <sdou...@redhat.com> wrote:

The main use case for this is to make quarkus more accessible to non java developers. There are a lot of mode developers who have no idea about maven or grade but will find this approach super familiar.

It's not really about about replacing maven or grade, it's about making quarkus more accessible.

Color me a sceptic, but as I said before, I'm glad to work on this with you folks and try to make the possible experience out of it.

[KimJohn Quinn]

Hopefully it is ok for me to provide my two-cents on this topic as we just made our first significant, and successful, deployment of a series of Quarkus  services from the ground up.

For background, one of our goals with moving to Quarkus was to provide a more level playing field across Java and non-Java developers.  We also wanted them to have more insight at the cluster level without necessarily being a K8S expert.  As a part of this, bringing in new services should be a seamless process.

In the 3-4 months we worked to establish our foundation a good part of that has been the GitLab pipeline tooling and we have it down to a science but here is what we wrestled with using Maven (not unlike any other large Maven CI/CD process):

• Reconciling "versions" using Maven Deploy, Flatten, and the CI "friendly" features - this was an absolute nightmare to get working.  We have many services, not all versioned the same and orchestrating the core service versions with user-driven services was one of the hardest challenges in Maven. It would be nice to have some way in either the Maven plugin or even Quarkus that lets us manage those versions easier.
  
  
• From the CI/CD process managing and updating configurations, without a ton of profiles, for everything - especially the generated K8S manifests.  In our world, we have development (merge-request) previews, snapshots, and of course releases - depending on the pipeline numerous values can be changed based on values out of the CI.  We accomplish this rather elegantly using S3 as a "group" and then in later jobs manipulating the configs prior to the actual build steps.  If there was a way to somewhat manage that easier for a pipeline it would of been helpful.
  
  
• To generate services, native or otherwise, we had to create an additional pipeline dynamically outside of our main pipeline.  At least in the GL side, we lose some metrics because of this. So, something to control building services better would be nice.
  
  
• Our biggest pain point right now, and not necessarily a Maven or Quarkus issue, is the time to it takes to build/deploy.  This starts at about 10-15m just to go through our compile-to-readyForDeploy stages.

Basically for us, anything revolving around configuration during the build process would be of interest.  Firstly, if it eases Maven integration or even applies it behind the scenes so developer dont even have to use it would be helpful and help us get more adoption.  Second, configuration thought of at the CI/CD level where a "test" run vs. a "service" run vs. a "deploy" run can be easier configured - this would need to take into account coordinating OAS and K8S configurations along with the native executable itself.  Finally, anything the speeds up our pipeline specific to the CI/CD process. 

We only use Maven because we have to.  Not because we like it or find it overly efficient/helpful especially in CI/CD pipelines.  Anything potential that could replace it we would be interested in and even willing to contribute.  I can even share what we are doing if it helps.

[Max Rydahl Andersen]

Hopefully it is ok for me to provide my two-cents on this topic as we just
made our first significant, and successful, deployment of a series of
Quarkus services from the ground up.

Definitely helpful! Hearing war stories is some of the best ways to improve :)

Your story below is (as I see it now) more about how to setup full CI pipelines which
for most part is actually build tool agnostic but definitely related and an area I'm
very keen to see if we can improve - if not by doing things at Quarkus level then at
least document/provide examples of possible setup.

For background, one of our goals with moving to Quarkus was to provide a
more level playing field across Java and non-Java developers. We also
wanted them to have more insight at the cluster level without necessarily
being a K8S expert. As a part of this, bringing in new services should be
a seamless process.

+1

In the 3-4 months we worked to establish our foundation a good part of that
has been the GitLab pipeline tooling and we have it down to a science but
here is what we wrestled with using Maven (not unlike any other large Maven
CI/CD process):

• Reconciling "versions" using Maven Deploy, Flatten, and the CI

"friendly" features - this was an absolute nightmare to get working.

This is for versions across plugins or for project dependencies ?

And whats the reason why you want it fully aligned ? out of principle or some
technical reason ?

We
have many services, not all versioned the same and orchestrating the core
service versions with user-driven services was one of the hardest
challenges in Maven. It would be nice to have some way in either the Maven
plugin or even Quarkus that lets us manage those versions easier.

if for dependencies if you use Quarkus universal platform which of these versions were not aligned for you ?

• From the CI/CD process managing and updating configurations, without a

ton of profiles, for everything - especially the generated K8S manifests.
In our world, we have development (merge-request) previews, snapshots, and
of course releases - depending on the pipeline numerous values can be
changed based on values out of the CI. We accomplish this rather elegantly
using S3 as a "group" and then in later jobs manipulating the configs prior
to the actual build steps. If there was a way to somewhat manage that
easier for a pipeline it would of been helpful.

Not following exactly what this is - maybe if you could share the setup I could grasp it better?

• To generate services, native or otherwise, we had to create an

additional pipeline dynamically outside of our main pipeline. At least in
the GL side, we lose some metrics because of this. So, something to control
building services better would be nice.

"generate services" ? as in building them ?

• Our biggest pain point right now, and not necessarily a Maven or

Quarkus issue, is the time to it takes to build/deploy. This starts at
about 10-15m just to go through our compile-to-readyForDeploy stages.

I'm curious on why it takes that long...what is taken up the time ?
I assume it is not just native compile you have issues with?

Basically for us, anything revolving around configuration during the build
process would be of interest. Firstly, if it eases Maven integration or
even applies it behind the scenes so developer dont even have to use it
would be helpful and help us get more adoption. Second, configuration
thought of at the CI/CD level where a "test" run vs. a "service" run vs. a
"deploy" run can be easier configured - this would need to take into
account coordinating OAS and K8S configurations along with the native
executable itself. Finally, anything the speeds up our pipeline specific
to the CI/CD process.

We only use Maven because we have to. Not because we like it or find it
overly efficient/helpful especially in CI/CD pipelines. Anything potential
that could replace it we would be interested in and even willing to
contribute. I can even share what we are doing if it helps.

That would be great.

/max

On Wednesday, August 25, 2021 at 5:56:26 AM UTC-4 gand...@redhat.com wrote:

On Wed, Aug 25, 2021 at 12:30 PM Stuart Douglas sdou...@redhat.com
wrote:

The main use case for this is to make quarkus more accessible to non java
developers. There are a lot of mode developers who have no idea about maven
or grade but will find this approach super familiar.

It's not really about about replacing maven or grade, it's about making
quarkus more accessible.

Color me a sceptic, but as I said before, I'm glad to work on this with
you folks and try to make the possible experience out of it.

Stuart

On Wed, 25 Aug 2021, 6:30 pm Georgios Andrianakis, gand...@redhat.com
wrote:

On Wed, Aug 25, 2021 at 11:04 AM Max Rydahl Andersen mand...@redhat.com
wrote:

To be clear:
I want to do idea* . *and have everything automatically setup for
me.
Will that work?

Yes, if you before that have run i.e. jbang edit or maybe we make a
quarkus
edit commond.

I am pretty sure that doesn't work with the jbang workflow... And
FWIW
when
I did try the IDE integration (a while back), things were not

working

for
me...

todays version of the above is

jbang edit --open=idea main.java

This is the command that today uses a temporary symbolic link
generated
project but which in future

will be updated to have the IDE required files put inside the project
(just as you have them today when using normal maven/gradle project)

If we can get things to work (without any extra configuration on

the
users part), then awesome (I personally don't use CLIs and I know I
am not
the only one).

Can you explain what you mean here, calling idea . or mvn package is
using a cli ...

If we really want to get technical, no idea is not a CLI.

If anything by doing the changes needed for this will improve the

You received this message because you are subscribed to the Google

<https://mailto:quarkus-dev%2Bunsu...@googlegroups.com

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/2f55197d-8c27-4d40-9f86-7ed003d06b77n%40googlegroups.com.

/max
https://xam.dk/about

[KimJohn Quinn]

Hello Max.

I think a picture would be worth a thousand words if it is helpful and would love to show what we do.

For us, the DevOps pipeline is very integrated into the process.  In fact, we feel to be successful you can't really have one without the other.  So, with that being said, the developer "experience" to not only build but also deploy Quarkus needs to be super transparent, especially when I am working towards adoption from other teams who are not Java developers.  

Basically, we want the mantra internally if it needs to be done at the service level use Quarkus.  By abstracting away the pipeline or local build that is one less thing for them to wrestle with so they can focus on developing with Quarkus rather than how to set it up or use it. If all they need to know is Quarkus it is a lot faster than Quarkus, Maven, Kubernetes, OAS, etc.

As a note, we have officially built our foundation and tooling - the next phase is moving into Kogito and potentially Kamel.  We based our approach/architecture with this knowledge going forward and some of our approach is in preparation for this.

Let me try and elaborate on the responses below and I am just brain-dumping so hopefully it adds context.

On Wed, Aug 25, 2021 at 9:08 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

Hopefully it is ok for me to provide my two-cents on this topic as we just
made our first significant, and successful, deployment of a series of
Quarkus services from the ground up.

Definitely helpful! Hearing war stories is some of the best ways to improve :)

Your story below is (as I see it now) more about how to setup full CI pipelines which
for most part is actually build tool agnostic but definitely related and an area I'm
very keen to see if we can improve - if not by doing things at Quarkus level then at
least document/provide examples of possible setup.

For background, one of our goals with moving to Quarkus was to provide a
more level playing field across Java and non-Java developers. We also
wanted them to have more insight at the cluster level without necessarily
being a K8S expert. As a part of this, bringing in new services should be
a seamless process.

+1

Using the Quarkus CLI would be preferable here.  Anytime someone not familiar with Maven has to do something, change versions, add dependencies, etc. this becomes a pain-point and a blocker for developers (seasoned or not - you would be surprised how once you leave textbook Maven usage all hell can break loose).  The learning curve to Quarkus we have found is very quick to get up and running (at least prior to testing a native executable).

In the 3-4 months we worked to establish our foundation a good part of that
has been the GitLab pipeline tooling and we have it down to a science but
here is what we wrestled with using Maven (not unlike any other large Maven
CI/CD process):

• Reconciling "versions" using Maven Deploy, Flatten, and the CI

"friendly" features - this was an absolute nightmare to get working.

This is for versions across plugins or for project dependencies ?

Less Maven dependencies themselves and more orchestrating "service" versions.  This especially becomes challenging when services are isolated but through clients need to communicate to other services for a full e2e run.  For example, I have a project service(s) at v2.0.0 and a data service(s) at v1.0.0, that talks to  project services vis RESTclient.  The happy path, this works great - it gets complicated when in the pipeline, an MR is "versioned" differently and that cascades across the build.  End result, Maven comes into play at each project which requires some Maven knowledge.  In addition, some way to be able to "bootstrap" a variety or services (we have started to gravitate towards Wiremock) as a single "server" would go a long way in making the process smoother (we do have something like this and it works really well for local development).

And whats the reason why you want it fully aligned ? out of principle or some
technical reason ?

We
have many services, not all versioned the same and orchestrating the core
service versions with user-driven services was one of the hardest
challenges in Maven. It would be nice to have some way in either the Maven
plugin or even Quarkus that lets us manage those versions easier.

This is tough for me to explain properly and I may have to revisit my answer.  We deploy about ~20 something services.  It almost becomes an issue tying together artifacts such as OAS documentation, K8S manifests, Ingress locations more so than orchestrating the services.  At a developer level, we have crafter a "bootstrap" which composes all of the services into a single runtime to minimize having so many dependencies (service or maven). BUT, any orchestration that requires manipulating Maven (use versions or dependencies for example) almost always causes an issue for non-Java/Maven developers. From the DevOps side, we heavily use the Maven CI-friendly approach, which is half-baked but better than the Release approach, and that has been a considerable pain point for us in the initial setup especially when the parent of one project is not necessarily driving another project.

if for dependencies if you use Quarkus universal platform which of these versions were not aligned for you ?

• From the CI/CD process managing and updating configurations, without a

ton of profiles, for everything - especially the generated K8S manifests.
In our world, we have development (merge-request) previews, snapshots, and
of course releases - depending on the pipeline numerous values can be
changed based on values out of the CI. We accomplish this rather elegantly
using S3 as a "group" and then in later jobs manipulating the configs prior
to the actual build steps. If there was a way to somewhat manage that
easier for a pipeline it would of been helpful.

Not following exactly what this is - maybe if you could share the setup I could grasp it better?

• To generate services, native or otherwise, we had to create an

additional pipeline dynamically outside of our main pipeline. At least in
the GL side, we lose some metrics because of this. So, something to control
building services better would be nice.

"generate services" ? as in building them ?

Even though Quarkus is our primary service, we have other services in Node, Python, even plain-old Java/Spring.  Each of these is "triggered" as external pipelines that spin off the main pipeline.  This gives us a "building" block approach and makes crafting CI/CD consistent regardless of the stack.  Also, a better shown than I can explain item ;).

• Our biggest pain point right now, and not necessarily a Maven or

Quarkus issue, is the time to it takes to build/deploy. This starts at
about 10-15m just to go through our compile-to-readyForDeploy stages.

I'm curious on why it takes that long...what is taken up the time ?
I assume it is not just native compile you have issues with?

No, it is not you its me ;)  I am not sure what it is.  We did standardize on use of @QuarkusTest (better than explaining use it here but dont use it here for regular JUnit - especially to new or non-Java developers).  The 10-15 minutes to run a non-native build may be related to the AWS EC2 class we are using but locally the same build is pretty hefty too.  Even on my local machine which is beefy it takes a while (2-3 minutes for 100+ test cases right now).

Here, it appears a bulk of the time is taken during the startup of Quarkus for the test runs.  

We are doing some investigation here and taking apart our test process to see if the result vary drastically.  For example, does removing Jacoco help.  The variance though from my local to AWS we believe has to do with the infrastructure and not anything to do with the code.

If this is the price of consistency we can live with a 30-60m build because it is a single-click operation and well worth the time.

Testing native (even building native) is challenging and since we just got burned on @RegisterForReflection (as a note, every deploy we get hit on this one) we are working out a process to ease this and tooling to help test better/quicker.

[David Lloyd]

I love this idea. Quarkus really is a build system already in many respects.

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com.



--
- DML • he/him

[Stuart Douglas]

<snip>

I think this discussion has diverged a bit from the build tool, but is still really interesting.

 

Less Maven dependencies themselves and more orchestrating "service" versions.  This especially becomes challenging when services are isolated but through clients need to communicate to other services for a full e2e run.  For example, I have a project service(s) at v2.0.0 and a data service(s) at v1.0.0, that talks to  project services vis RESTclient.  The happy path, this works great - it gets complicated when in the pipeline, an MR is "versioned" differently and that cascades across the build.  End result, Maven comes into play at each project which requires some Maven knowledge.  In addition, some way to be able to "bootstrap" a variety or services (we have started to gravitate towards Wiremock) as a single "server" would go a long way in making the process smoother (we do have something like this and it works really well for local development).

 

This sounds kinda like DevServices, we have been talking about adding a more generic approach to dev services that allows you to spin up arbitrary docker images as part of dev/test, does this sound useful?

And whats the reason why you want it fully aligned ? out of principle or some
technical reason ?

We
have many services, not all versioned the same and orchestrating the core
service versions with user-driven services was one of the hardest
challenges in Maven. It would be nice to have some way in either the Maven
plugin or even Quarkus that lets us manage those versions easier.

This is tough for me to explain properly and I may have to revisit my answer.  We deploy about ~20 something services.  It almost becomes an issue tying together artifacts such as OAS documentation, K8S manifests, Ingress locations more so than orchestrating the services.  At a developer level, we have crafter a "bootstrap" which composes all of the services into a single runtime to minimize having so many dependencies (service or maven). BUT, any orchestration that requires manipulating Maven (use versions or dependencies for example) almost always causes an issue for non-Java/Maven developers. From the DevOps side, we heavily use the Maven CI-friendly approach, which is half-baked but better than the Release approach, and that has been a considerable pain point for us in the initial setup especially when the parent of one project is not necessarily driving another project.

This is also something I have been thinking a lot about. Live Reload and continuous testing are not really useful if your dev environment is so complex that local development is no longer possible. I have been thinking about ways to enable Quarkus to handle this as well (e.g. potentially end to end continuous testing, where downstream tests are also run when changes are made).

 

if for dependencies if you use Quarkus universal platform which of these versions were not aligned for you ?

• From the CI/CD process managing and updating configurations, without a

ton of profiles, for everything - especially the generated K8S manifests.
In our world, we have development (merge-request) previews, snapshots, and
of course releases - depending on the pipeline numerous values can be
changed based on values out of the CI. We accomplish this rather elegantly
using S3 as a "group" and then in later jobs manipulating the configs prior
to the actual build steps. If there was a way to somewhat manage that
easier for a pipeline it would of been helpful.

Not following exactly what this is - maybe if you could share the setup I could grasp it better?

• To generate services, native or otherwise, we had to create an

additional pipeline dynamically outside of our main pipeline. At least in
the GL side, we lose some metrics because of this. So, something to control
building services better would be nice.

"generate services" ? as in building them ?

Even though Quarkus is our primary service, we have other services in Node, Python, even plain-old Java/Spring.  Each of these is "triggered" as external pipelines that spin off the main pipeline.  This gives us a "building" block approach and makes crafting CI/CD consistent regardless of the stack.  Also, a better shown than I can explain item ;).

• Our biggest pain point right now, and not necessarily a Maven or

Quarkus issue, is the time to it takes to build/deploy. This starts at
about 10-15m just to go through our compile-to-readyForDeploy stages.

I'm curious on why it takes that long...what is taken up the time ?
I assume it is not just native compile you have issues with?

No, it is not you its me ;)  I am not sure what it is.  We did standardize on use of @QuarkusTest (better than explaining use it here but dont use it here for regular JUnit - especially to new or non-Java developers).  The 10-15 minutes to run a non-native build may be related to the AWS EC2 class we are using but locally the same build is pretty hefty too.  Even on my local machine which is beefy it takes a while (2-3 minutes for 100+ test cases right now).

Any chance you can profile this with YourKit or https://github.com/jvm-profiling-tools/async-profiler and send me the results? It's hard for us to improve this sort of perfomance without real world data on what is slowing things down.

 

Here, it appears a bulk of the time is taken during the startup of Quarkus for the test runs.  

We are doing some investigation here and taking apart our test process to see if the result vary drastically.  For example, does removing Jacoco help.  The variance though from my local to AWS we believe has to do with the infrastructure and not anything to do with the code.

If this is the price of consistency we can live with a 30-60m build because it is a single-click operation and well worth the time.

Testing native (even building native) is challenging and since we just got burned on @RegisterForReflection (as a note, every deploy we get hit on this one) we are working out a process to ease this and tooling to help test better/quicker.

If you have a set of classes you can tell always need to be registered (e.g. everything that implements a specific interface) your best bet might be to write a simple extension to handle this. The actual Java code to do this is only a couple of lines, there would be way more pom.xml code than java.

 

Basically for us, anything revolving around configuration during the build
process would be of interest. Firstly, if it eases Maven integration or
even applies it behind the scenes so developer dont even have to use it
would be helpful and help us get more adoption. Second, configuration
thought of at the CI/CD level where a "test" run vs. a "service" run vs. a
"deploy" run can be easier configured - this would need to take into
account coordinating OAS and K8S configurations along with the native
executable itself. Finally, anything the speeds up our pipeline specific
to the CI/CD process.

We only use Maven because we have to. Not because we like it or find it
overly efficient/helpful especially in CI/CD pipelines. Anything potential
that could replace it we would be interested in and even willing to
contribute. I can even share what we are doing if it helps.

That would be great.

I am also really interested in this.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv7_VW58zddvYnskK%3DnNSjrm206jSP8kSJdRvz7JXvx1VQ%40mail.gmail.com.

[Eduardo Ramirez Ronco]

>This sounds kinda like DevServices, we have been talking about adding a more generic approach to dev services that allows you to spin up arbitrary docker images as part of dev/test, does this sound useful?

Isn't that what TestContainer is?

Eduardo

  

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czJa%2B5x0oCW-buem_7YDUbAmaJEY4KNFJ2_Y8ek-OUosQ%40mail.gmail.com.

[Stuart Douglas]

On Thu, 26 Aug 2021 at 17:09, Eduardo Ramirez Ronco <eram...@redhat.com> wrote:

>This sounds kinda like DevServices, we have been talking about adding a more generic approach to dev services that allows you to spin up arbitrary docker images as part of dev/test, does this sound useful?

Isn't that what TestContainer is?

We use test containers behind the scenes, the main thing is with Dev Services they are usable in dev mode as well and automatically wire up all the relevant Quarkus config.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAFif860ph8NTHbXHNTyufJE-22B6eDA2W%2By48AJ-f_367U5%2BrQ%40mail.gmail.com.

[Martin Kouba]

On 24. 08. 21 2:36, Stuart Douglas wrote:
> Hi Everyone,
>
> I have been thinking a bit about making our own Quarkus based build
> system. Within the team we have talked a bit about how Java is harder to
> approach than node etc as the build tools are more complex. Given that
> Quarkus already can do almost everything a build system can do, I am
> thinking maybe we can change that.
>
> I think we could add basic build capabilities to the CLI, so that this
> is all that is needed to build a Quarkus project. We would create a
> layout that looks like this:
>
> quarkus.json
> src/Foo.java
> test/FooTest.java

Although I like the simplicity of this structure we should probably
follow the src/main/java and src/test/java convention here. Or at least
src/main and src/test.

>
> Which should be very similar to what node (and other language)
> developers are familiar with. quarkus.json would contain the (optional)
> coordinates, the dependencies, the Java version (so you don't even need
> Java installed), and any config that would normally go in
> application.properties. Build/run would be done entirely from the CLI,
> but would pretty much delegate everything to Quarkus itself (i.e. use
> Quarkus existing compiler support to do compilation, Quarkus will build
> the output target etc). This build will not really be customisable at
> all, outside of features that are provided by Quarkus itself and its
> extensions (which is actually pretty customisable). E.g. if we wanted to
> add code formatting support we would add it to the compiler used in hot
> reload, we would not support it as a specialized plugin in the build system.
>
> There would also be a command to turn this into a maven/gradle project,
> if you need something more customizable.

I think that this is a very important point. With this option your build
setup can evolve if needed, which is great...

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--

Martin Kouba
Software Engineer
Red Hat, Czech Republic

[Martin Kouba]

On 24. 08. 21 18:37, Georgios Andrianakis wrote:
>
>
> On Tue, Aug 24, 2021, 10:04 Alexey Loubyansky
> <alexey.l...@redhat.com <mailto:alexey.l...@redhat.com>> wrote:
>
> I totally support this effort. IMO, it's worth researching it even
> if it might not become the number one build tool for the Quarkus
> apps (there is actually no such objective at this point, afaiu).
>
>
> I completely agree with this. A comprehensive refactoring would be very
> beneficial.
>
> I just personally don't see the idea of adding a simplified build tool
> taking off.
> I mean I would enjoy working on such a tool and improving the user
> experience, but at the same time I am skeptical of how useful it would
> be in the real world

I wouldn't be that sceptical. For sure, most of the experienced users
will continue with maven/gradle because they're used to it. But
newcomers, demos, serverless, etc. All these categories could leverage
the simplicity...

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com

> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cztSkLq8a6oTqTFksgDGJneYjL3ORwv2Z5trqS67G2-1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to
> the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/CAKeeVe4ZXoFuaX_Mvu1JfJb8zQuLLg8fTFEh2kMPpfSBphZvUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the
> Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n7u0T8L5Oc_iN9jzb0Z2q9TUCUYH0JgpgNho49E7cwBA%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n7u0T8L5Oc_iN9jzb0Z2q9TUCUYH0JgpgNho49E7cwBA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Andy Damevin
>
> --
> You received this message because you are subscribed to the
> Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P6AWxXhuwYxzLBAriek%2BiHFey36DuaT_TbVn2OD-Kw3fQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P6AWxXhuwYxzLBAriek%2BiHFey36DuaT_TbVn2OD-Kw3fQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mmA91PmBwK7PgAD1TQQ1CB5g-ttXgMawXHNvsd307Dag%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mmA91PmBwK7PgAD1TQQ1CB5g-ttXgMawXHNvsd307Dag%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Stephane Epardaud]

On Wed, 25 Aug 2021 at 00:52, Max Rydahl Andersen <mand...@redhat.com> wrote:

I raised to the JDK team at least recognise notion of maven dependency mechanism which is basically what jbang does - enable javac and java to
grok maven dependencies and you can get very far - it will take time and probably not happen soon. I'll keep trying though.

Huge +1 from me about this. And change the default source lookup and output from $CWD which is _very_ outdated. That would help everyone.

[KimJohn Quinn]

KimJohn Quinn <k...@logicdrop.com>	9:17 AM (0 minutes ago)
to Stuart, Eduardo, Quarkus

I am more than likely the culprit of causing this thread to diverge so much so apologies.

Trying to get myself back to the original discussion:

- DevContainers/Test Containers - these are neat, and we will explore them more later, but for now we disabled them and continuous testing because we have already worked into our process any containers we need both locally, CI, and in VSCode.  Also for us, this goes beyond just testing and we would like a more cohesive process across different services rather than the primary one being worked on.  DevContainers, a more generic approach, seems to line up with what we do now and would be helpful.

- Build Performance - yes, I will profile this soon and try to get back some metrics.  Right now, it is a small price to pay for an almost no-touch end-to-end deployment right now.

- @RegisterForReflection - It has seemed this always revolves around our "DTO" objects (almost every Native issue for us has been this which is actually great because it provides a blueprint of what to look for first).  The annotation is more comfortable to us for non-Java devs since, per the original discussion, we want less Maven interaction (a lot of pom work and their heads would explode).It "seems" and maybe this was in our rush to get the MVP together, that it depended.  We have similar DTO's that did not require it whereas others do.  Never on the JVM side has this been an issue and we mitigate this now but introducing a few simple Native tests for every service.  I will say I wanted really badly to use the approach typically outlined in the examples where you extended the original resource but because of mocking it just was not possible.  We even introduced wiremock across the board to ease RESTclients.

- Orchestration for development - just spitballing, what would be nice is somehow the equivalent of a service broker/locator where if I spin up multiple instances they can recognize each other.  Our approach right now is a "super" bootstrap that aggregates/exposes core services.  Developers can spin that up and the service(s) they are working on.  It is a little heavy-handed but it works and is simple.

- Quarkus as a build tool - Anything that helps to provide a consistent environment to onboard and use is of importance to us and we are interested in.  On that note, a tool used during development ideally would also be usable in our DevOps environment and that is where we see the real power (for us).  If it helps to streamline that process more especially when preparing and building the native services that would be awesome.

Let me share some "hard" metrics too that you might find interesting (and why I am expressing interest in these topic(s) and probably seem all over the place).  We track everything from the minute a ticket comes in, to when an MR is open, everything in between, finally when it gets deployed.

Our reasons for moving over to Quarkus are actually quite different than what you might expect.  Native images were nice and happen to be icing on the cake since so far everything we do has fit into that model.  We were more about streamlining and simplifying the overall developer process end-to-end on the premise that by doing so we could iterate faster, for better or worse, and level our playing field so all teams could equally be involved.  As we evangelize Quarkus to our clients we see they share this point of view. We even have been able to standardize on using VSCode as the environment rather than specialized IDEs (which has a huge impact on the learning curve and an environment where multiple stacks exist).

As for this conversation, right now I really have no complaints.  My only regret is not moving over to Quarkus sooner.  It has been one of the most spectacular experiences ever!  At the end of the day, I went from an 8 hour (minimum) deployment with "babysitting" to less than 1 hour completely automated.

--
You received this message because you are subscribed to a topic in the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/quarkus-dev/4FSp4aKciEc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9sMM3z0pKXr_4yvAbyjWphgcKbNEdgDofbyiUf00Z-Kcw%40mail.gmail.com.

[Stephane Epardaud]

Big +1 on making Quarkus easier to use.

Just for quick reference as to how the layout of a Play 1 application was:

conf/

 application.conf (config)

 dependencies.yml (list of line-separated mvn coordinates, with some fancy options: https://www.playframework.com/documentation/1.3.x/dependency)

 messages.en (I18N)

 routes (external text-based routing, not applicable for us, though we did discuss it some times, but out of the scope of this discussion)

app/ (source code, no TLDN package prefix necessary)

 controllers/ (REST endpoints)

 model/ (DB models)

test/ (test source code)

Not saying we have to copy this, we don't. But it's a comparison to how easy/compact the initial layout can be when it's not Maven/Gradle.

If I can get my project created and running with something like this, I'll be happy:

$ cd $HOME/src

# Create an app called test-app with the following extensions and sample code

$ q create test-app resteasy-reactive,hibernate-reactive-panache,graphql

$ cd test-app

# Start dev mode, generate whatever pom.xml file is needed for Eclipse (or IDEA or whatever) to grok my project setup

$ q dev --eclipse

# Build me a jar

$ q jar

# Build me a native exec

$ q native

And that's it. Well, that and probably we will indeed need something to _turn_ it into a real Maven/Gradle project (not just pretend for the sake of the IDE): $ q regress --maven

And if we really are serious about catering to non-Java devs, we will indeed have to fix the issues brought up about Java not having a landing page for beginners, but that'd be a win anyway.

[William Burke]

On Tue, Aug 24, 2021 at 5:29 PM Max Rydahl Andersen <mand...@redhat.com> wrote:

On 24 Aug 2021, at 19:56, William Burke wrote:

> +1 here, but it has to have more than incremental improvements over
> maven/gradle.  Think like developing functions/lambdas where you don't
> write any pom.xml code and you dont have to do everythign in one file
> like
> jbang.

jbang supported multiple files for over a year now - just saying :)

> And an extension system that can also resolve tooling.  I've
> discussed this before.

"resolve tooling" ?

you do realise jbang's integration works by an extension model ?


> This should all be in conjunction with CLI.

> Would be worth it to experiment with this to see if it gains any
> traction.
> I'll reiterate again:  must leapfrog maven/gradle, nobody will buy
> into
> incremental improvements.

+1 to JBang.   But, JBang would be greatly improved by a custom quarkus build system wouldn't it?

By "resolving tooling", I mean this:  If you think of quarkus, what it automatically does now is it resolves "maven plugins" (analogy here).  Simple, but pretty powerful right when you think about it?  Its great to not have to google for whatever the maven plugin is and look through the always crappy maven documentation, etc.   

Would be cool if we could also automatically resolve IDE tooling, CLI extensions, etc. all by just declaring one dependency.  

 

leapfrog in what way ? as in have all the features maven/gradle has with
super flexible multi module project notions or
in being super easy to use and work extremely well for microservice
style apps and can easily pick up existing maven/gradle generated
artefacts if needed ?

Leapfrog would be I don't have to worry about or know pom syntax and the auto-resolving I talked about before.

[KimJohn Quinn]

It would be pretty sweet if you could embed WireMock or the equivalent into the CLI, as a container, etc.  That way I could spin up a service with no hard dependencies stand-alone.  I could then distribute the "mocks" to take the place of real remote service calls.  Actually any way that let's me pretend I have all the services when developing a new one that requires interaction.

[Erin Schnabel]

Let’s say into the build tool capabilities, rather than into the CLI.

And contract based testing (using mocks locally, with ), is definitely a thing we should be doing more of. We have a thread about that languishing somewhere.. 

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/0e82c5da-5df4-478f-be56-835c32847876n%40googlegroups.com.

--

Thanks,

Erin

 

------
Erin Schnabel <ebul...@redhat.com>

@ebullientworks

[KimJohn Quinn]

Sure! I am also suggesting that as a part of the build capabilities, beyond testing and if you go to some "package.json" like configuration - it would be super handy to configure external endpoints, similar to how we use Wiremock in test cases, that could be applied in dev mode.  

That way, when i quarkus:dev my service everything is self contained and I can interact with it as if I do with wiremocks during testing.  In our DevOps cycle this would let me deploy isolated services without the need to mixing up the endpoints (some point here but if it is a MR it should point here instead).  From the testing side we already use wiremock so it is not much different there but maybe easier to integrate.

It would also have the added advantage that merge-request based features, devoid of testing, could be deployed as a stand alone until they become more formalized.

[Stuart Douglas]

On Thu, 26 Aug 2021 at 23:32, Stephane Epardaud <stephane...@gmail.com> wrote:

Big +1 on making Quarkus easier to use.

Just for quick reference as to how the layout of a Play 1 application was:

conf/

 application.conf (config)

 dependencies.yml (list of line-separated mvn coordinates, with some fancy options: https://www.playframework.com/documentation/1.3.x/dependency)

 messages.en (I18N)

 routes (external text-based routing, not applicable for us, though we did discuss it some times, but out of the scope of this discussion)

app/ (source code, no TLDN package prefix necessary)

I also want to do something like this (get rid of the useless package structure), although we need to be careful this does not break IDE's.

 

 controllers/ (REST endpoints)

 model/ (DB models)

test/ (test source code)

Not saying we have to copy this, we don't. But it's a comparison to how easy/compact the initial layout can be when it's not Maven/Gradle.

If I can get my project created and running with something like this, I'll be happy:

$ cd $HOME/src

# Create an app called test-app with the following extensions and sample code

$ q create test-app resteasy-reactive,hibernate-reactive-panache,graphql

$ cd test-app

# Start dev mode, generate whatever pom.xml file is needed for Eclipse (or IDEA or whatever) to grok my project setup

$ q dev --eclipse

# Build me a jar

$ q jar

# Build me a native exec

$ q native

That is pretty much what I want to do.

 

And that's it. Well, that and probably we will indeed need something to _turn_ it into a real Maven/Gradle project (not just pretend for the sake of the IDE): $ q regress --maven

And if we really are serious about catering to non-Java devs, we will indeed have to fix the issues brought up about Java not having a landing page for beginners, but that'd be a win anyway.

Yep, because that is really our target audience for this. We want to make the Java experience as simple and awesome as possible.

Stuart

 

[Stuart Douglas]

On Fri, 27 Aug 2021 at 00:05, KimJohn Quinn <k...@logicdrop.com> wrote:

It would be pretty sweet if you could embed WireMock or the equivalent into the CLI, as a container, etc.  That way I could spin up a service with no hard dependencies stand-alone.  I could then distribute the "mocks" to take the place of real remote service calls.  Actually any way that let's me pretend I have all the services when developing a new one that requires interaction.

We can do this as a Quarkus extension, in a similar way we do for Dev Services. Just auto start wiremock in dev/test mode.

Stuart

 

--

[Georgios Andrianakis]

On Fri, Aug 27, 2021, 04:42 Stuart Douglas <sdou...@redhat.com> wrote:

On Fri, 27 Aug 2021 at 00:05, KimJohn Quinn <k...@logicdrop.com> wrote:

It would be pretty sweet if you could embed WireMock or the equivalent into the CLI, as a container, etc.  That way I could spin up a service with no hard dependencies stand-alone.  I could then distribute the "mocks" to take the place of real remote service calls.  Actually any way that let's me pretend I have all the services when developing a new one that requires interaction.

We can do this as a Quarkus extension, in a similar way we do for Dev Services. Just auto start wiremock in dev/test mode.

We have thought about this actually. 

The reason we haven't done it is that we wanted to tie it in with the rest client, but we didn't figure out a way to make it super useful

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czB3hDg8hC4RfSSDqgonkE1HZNy%2BCF71fLZJmUVnmgV1w%40mail.gmail.com.

[Max Rydahl Andersen]

On 26 Aug 2021, at 15:01, Martin Kouba wrote:

> On 24. 08. 21 2:36, Stuart Douglas wrote:
>> Hi Everyone,
>>
>> I have been thinking a bit about making our own Quarkus based build
>> system. Within the team we have talked a bit about how Java is harder
>> to approach than node etc as the build tools are more complex. Given
>> that Quarkus already can do almost everything a build system can do,
>> I am thinking maybe we can change that.
>>
>> I think we could add basic build capabilities to the CLI, so that
>> this is all that is needed to build a Quarkus project. We would
>> create a layout that looks like this:
>>
>> quarkus.json
>> src/Foo.java
>> test/FooTest.java
>
> Although I like the simplicity of this structure we should probably
> follow the src/main/java and src/test/java convention here. Or at
> least src/main and src/test.

Can you articulate why ?

What if it would be toggle or simply auto detected which structure you
use ? simple or classic ?

/max

[Max Rydahl Andersen]

from $CWD which is very outdated. That would help everyone.

Can you outline what you mean ? one of the reasons jbang been able to be so nimble is that javac default source lookup is relative to $CWD;
for output yes - here jbang redirects it to its little own internal place to not pollute.

/max
https://xam.dk/about

[Max Rydahl Andersen]

+1 here, but it has to have more than incremental improvements over
maven/gradle. Think like developing functions/lambdas where you don't
write any pom.xml code and you dont have to do everythign in one file
like
jbang.

jbang supported multiple files for over a year now - just saying :)

And an extension system that can also resolve tooling. I've
discussed this before.

"resolve tooling" ?

you do realise jbang's integration works by an extension model ?

This should all be in conjunction with CLI.

Would be worth it to experiment with this to see if it gains any
traction.
I'll reiterate again: must leapfrog maven/gradle, nobody will buy
into
incremental improvements.

+1 to JBang. But, JBang would be greatly improved by a custom quarkus
build system wouldn't it?

Yes, and to be clear it already has it BUT is currently "blocked" because of the limitations in core that stuart highlighted in
the initial mail. JBang can already today utilise the container building, code generation etc. features of Quarkus but because
of Quarkus core having assumptions about maven/gradle setup and does not let extensions know about it enough extensions that uses
i.e. decorate fails with jbang thus Kubernetes/OpenShift deployment currently does not work - and would be really kludgy to fix atm.

By "resolving tooling", I mean this: If you think of quarkus, what it
automatically does now is it resolves "maven plugins" (analogy here).
Simple, but pretty powerful right when you think about it? Its great to
not have to google for whatever the maven plugin is and look through the
always crappy maven documentation, etc.

Would be cool if we could also automatically resolve IDE tooling, CLI
extensions, etc. all by just declaring one dependency.

Yes, I get this but there is a chicken and egg issue here on having (all) tooling resolving its plugins from Quarkus current dependency - it requires
things to be resolvable and runnable before the project is actually there...so (at least for now) I do believe the tooling wiring needs a bootstrap that
is independent from Quarkus.

I think we can get very far here if quarkus core gets opened up - as lots of tooling is perfectly fine to resolve from quarkus dependency mechanism.

Not sure at what point we absolutely need the "flip" to where quarkus drives but
I can see cases where it makes sense....its part of what this effort would reveal.

leapfrog in what way ? as in have all the features maven/gradle has with
super flexible multi module project notions or
in being super easy to use and work extremely well for microservice
style apps and can easily pick up existing maven/gradle generated
artefacts if needed ?

Leapfrog would be I don't have to worry about or know pom syntax and the
auto-resolving I talked about before.

Right now I just know //DEPS and looking up right quarkus properties to enable the various tools - won't scale forever but its refreshing for now at least :)

/max
https://xam.dk/about

[Max Rydahl Andersen]

On 27 Aug 2021, at 3:41, Stuart Douglas wrote:

> On Thu, 26 Aug 2021 at 23:32, Stephane Epardaud
> <stephane...@gmail.com>
> wrote:
>
>> Big +1 on making Quarkus easier to use.
>>
>> Just for quick reference as to how the layout of a Play 1 application
>> was:
>>
>> conf/
>> application.conf (config)
>> dependencies.yml (list of line-separated mvn coordinates, with some
>> fancy
>> options:
>> https://www.playframework.com/documentation/1.3.x/dependency)
>> messages.en (I18N)
>> routes (external text-based routing, not applicable for us, though
>> we did
>> discuss it some times, but out of the scope of this discussion)
>> app/ (source code, no TLDN package prefix necessary)
>>
>
> I also want to do something like this (get rid of the useless package
> structure), although we need to be careful this does not break IDE's.

This have been a big part of fun I had doing jbang - you can mainly
ignore packages but there are dragons.

javac does not for most parts care about the directory structure - it
will automatically deduce the needed structure
from the package statement's. Where it gets tricky is if you have a
class in package a using package b - this easily breaks
as javac for optimisations here does rely on source structure lookup and
gets it wrong.

java does not care as it just uses the generated classes/jars which
javac made sure is in place.

Quarkus often were coded to assume class names are fully qualified -
i.e. cannot be in default package space; we fixed ~20 instances of that
in Quarkus - haven't (yet) spotted that being issue outside yet. So
maybe we are good here.

IDE's are a combination of the above. They mainly work but some are
annoying telling you that a source file must be in a certain directory;
despite everything just working fine.

And finally, java inherently cannot use default(empty) package classes
from a package space - even when loaded dynamically can there be
problems.

soo...everything works in default package; but it can't be reused so
packages are probably here to stay - and deduced from that the directory
structure are going to be hard to eradicate.

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxb%3DxdiSvvsS9qWX6htJAGszY1YyubPpkxQkXboH3B3pw%40mail.gmail.com.

[Max Rydahl Andersen]

Big +1 on making Quarkus easier to use.

Just for quick reference as to how the layout of a Play 1 application was:

conf/
application.conf (config)
dependencies.yml (list of line-separated mvn coordinates, with some fancy
options: https://www.playframework.com/documentation/1.3.x/dependency)
messages.en (I18N)
routes (external text-based routing, not applicable for us, though we did
discuss it some times, but out of the scope of this discussion)
app/ (source code, no TLDN package prefix necessary)
controllers/ (REST endpoints)
model/ (DB models)
test/ (test source code)

Not saying we have to copy this, we don't. But it's a comparison to how
easy/compact the initial layout can be when it's not Maven/Gradle.

If I can get my project created and running with something like this, I'll
be happy:

$ cd $HOME/src

Create an app called test-app with the following extensions and sample

code
$ q create test-app resteasy-reactive,hibernate-reactive-panache,graphql

its:

quarkus create -x resteasy-reactive,hibernate-reactive-panache,graphql test-app

$ cd test-app

Start dev mode, generate whatever pom.xml file is needed for Eclipse (or

IDEA or whatever) to grok my project setup
$ q dev --eclipse

hooking IDE generation into quarkus dev mode is a nice idea. Thats one place where
enabling quarkus to call into jbang as a "library" would help.

note, I would probably just have it generate it no matter what or call it quarkus dev --ide

Build me a jar

$ q jar

quarkus package

Build me a native exec

$ q native

quarkus package --native

And that's it. Well, that and probably we will indeed need something to

turn it into a real Maven/Gradle project (not just pretend for the sake

of the IDE): $ q regress --maven

nice name :)

I'm going to add this to jbang shortly - I already done it once but lost the branch (don't ask; i'm still traumatised :)

And if we really are serious about catering to non-Java devs, we will
indeed have to fix the issues brought up about Java not having a landing
page for beginners, but that'd be a win anyway.

+100

/max
https://xam.dk/about

[Stephane Epardaud]

For jbang perhaps it makes sense, but most people still prefer to tuck their sources in a subfolder, usually `src` (not `src/main/java`). I guess some autodetection (check if pom.xml or other such marker exists) or convention-over-configuration (check if src, src/main/java folder exists, etc…) would solve the issue. Note that the new behaviour could even be in a new JDK tool rather than change the behaviour of javac. It would just invoke javac with different defaults. Hell, if it were a `j compile` tool it would even be better ;)

--

Stéphane Épardaud

[Stephane Epardaud]

Nice ! Note that I really don't care about names, so the current variants are fine ;)

--

Stéphane Épardaud

[Max Rydahl Andersen]

On 27 Aug 2021, at 10:05, Stephane Epardaud wrote:

For jbang perhaps it makes sense, but most people still prefer to tuck

their sources in a subfolder, usually src (not src/main/java). I guess

some autodetection (check if pom.xml or other such marker exists) or
convention-over-configuration (check if src, src/main/java folder exists,
etc…) would solve the issue.
Note that the new behaviour could even be in a
new JDK tool rather than change the behaviour of javac. It would just
invoke javac with different defaults. Hell, if it were a j compile tool
it would even be better ;)

You are basically describing where jbang and the suggested quarkus as build tool is going.

the alias is j! btw :)

/max

On Fri, 27 Aug 2021 at 08:37, Max Rydahl Andersen mand...@redhat.com
wrote:

On 26 Aug 2021, at 15:13, Stephane Epardaud wrote:

On Wed, 25 Aug 2021 at 00:52, Max Rydahl Andersen mand...@redhat.com
wrote:

I raised to the JDK team at least recognise notion of maven dependency
mechanism which is basically what jbang does - enable javac and java to
grok maven dependencies and you can get very far - it will take time
and probably not happen soon. I'll keep trying though.

Huge +1 from me about this. And change the default source lookup and output
from $CWD which is very outdated. That would help everyone.

Can you outline what you mean ? one of the reasons jbang been able to be
so nimble is that javac default source lookup is relative to $CWD;
for output yes - here jbang redirects it to its little own internal place
to not pollute.

/max
https://xam.dk/about

--
Stéphane Épardaud

/max
https://xam.dk/about

[KimJohn Quinn]

Georgios,

We have thought about this actually. 
The reason we haven't done it is that we wanted to tie it in with the rest client, but we didn't figure out a way to make it super useful

This is exactly the scenario we are looking to do ;).  Almost all of our services talk to at least one other service (locator-like service) using the REST Client.  We have keep the services relatively isolated and expect the use of the REST client to grow which is where it would be useful for development.

In a couple of weeks (at most) I am going to try writing an extension for this.

 

[Georgios Andrianakis]

On Fri, Aug 27, 2021, 19:20 KimJohn Quinn <k...@logicdrop.com> wrote:

Georgios,

We have thought about this actually. 
The reason we haven't done it is that we wanted to tie it in with the rest client, but we didn't figure out a way to make it super useful

This is exactly the scenario we are looking to do ;).  Almost all of our services talk to at least one other service (locator-like service) using the REST Client.  We have keep the services relatively isolated and expect the use of the REST client to grow which is where it would be useful for development.

The problem is however, what exactly will you be testing?

Do you assume that the java model is the starting and generate wiremock stubs that accept it?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv6kgbfgX4pKeiEDy59%2BHyN4%2BuVGnS-2YDN9UMT4wmF8Rw%40mail.gmail.com.

[KimJohn Quinn]

Georgios.

From the Wiremock side, similar to what we do with Lifecycle in our tests we provide a "base" set of mock data (plan is to incorporate stubs) and then from the services additional ones can be added/used and the stub mappings, right now until stubs are pulled in, can be customized over and above the base.  From our side, we are just looking to automate including wiremock as a part of the startup so that developers of services can use the base and then craft their own for what they need in the service. So, I would not try to infer the models, just standardize RESTclient usage as if the external service was exposed/running along-side the one being developed.

For example, when we are testing service A it depends on a rest client service B.  Using Wiremock I dont need to spin up B and I can iterator over the wm files to simulate that.  I'd like to be able to do the same thing with quarkus:dev - spin it up, iterate over some JSON for my external calls, and work on my service at hand as needed.  Wiremock here would be the equivalent of me injecting an alternative implementation for local development.

[Georgios Andrianakis]

Thanks for the input.

Here is where we had captured: https://github.com/quarkusio/quarkus/issues/17861

[KimJohn Quinn]

Awesome.  If you carry that over into DEV mode as well, as an option, developers can then develop a single service using quarkus:dev with external calls treated as mocked JSON responses for quick development. This also could simplify my need to configure multiple services during phases in the CI/CD process too!

www.logicdrop.com

[Georgios Andrianakis]

Right, that's the goal.

[Loïc MATHIEU]

Just a wild idea but instead of inventing another build tool for Quarkus maybe we can based the work on a well know build tool, a build tool that non-java developers may already know. For example we can use a makefile to manage build steps and dependencies (and using make or make the quarkus cli to use the makefile). Or we can use Bazel : https://bazel.build.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3Dnw0WW-Xui1t7EcbhvfMSmF0PNMXitZRDOoLuTcBpzHg%40mail.gmail.com.

[Georgios Andrianakis]

IIUC, the goal is to simplify things, not make them more complicated. Bazel is not definitely not simple :)

[Stephane Epardaud]

Loïc, come on ;) Make? Come on :)

I've written some pretty crazy Makefiles myself over the years, some even recursive with eval and stuff. Let's not get there. Makefiles should be left alone in their retirement magnetic tapes in the Arctic Vault, they're living a happy end of life there along with ed, cc and autotools. Let's not disturbe them unduly, they've done their part ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com.

--

Stéphane Épardaud

[Emmanuel Bernard]

On Tue, Aug 31, 2021 at 5:13 PM Stephane Epardaud <stephane...@gmail.com> wrote:

Loïc, come on ;) Make? Come on :)

I've written some pretty crazy Makefiles myself over the years, some even recursive with eval and stuff. Let's not get there. Makefiles should be left alone in their retirement magnetic tapes in the Arctic Vault, they're living a happy end of life there along with ed, cc and autotools. Let's not disturbe them unduly, they've done their part ;)

Ant files on the other hand...

[Loïc MATHIEU]

Well, OK make is old, but my point is to use something developers already know (so maybe not make but only a makefile) to lower the barrier to using a new tool.
Maybe using a pom.xml without Maven is the way to go, maybe something else (package.json format ?).
But adding a new dependency declaration file is not a good idea IMHO.

[Georgios Andrianakis]

As an initial sceptic myself, I have warmed up to the idea, but I am assuming we are talking about something entirely new, but similar to what exists for example in the Node.js space and therefore easy to pick up for developers knowledgeable of that sort of ecosystem

[Ladislav Thon]

út 31. 8. 2021 v 16:17 odesílatel Georgios Andrianakis <gand...@redhat.com> napsal:

IIUC, the goal is to simplify things, not make them more complicated. Bazel is not definitely not simple :)

I intentionally tried to stay away from this thread, but I just can't anymore :-) In my opinion, something like Bazel (or Buck) is exactly what the Java ecosystem needs, except it shouldn't look so alien and should natively integrate with Maven repositories. I actually think the Quarkus core infrastructue (aside: what happened to the PR that moved Quarkus to Qlue?) is pretty well suited to implementing that. It would be a waste of potential to only implement something trivial to cater for people coming from other ecosystems (aside: the word "simple" is way too overloaded, see also Simple Made Easy by Rich Hickey).

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com.

[Paul Carter-Brown]

If you looking at making JS developers feel at home then "npm -g install quarkus" and then in a quarkus directory ... "npm up" will run Quarkus in dev mode :-)

Did I just suggest wrapping Quarkus with NPM... I'm gonna go chew broken glass now :-( 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALbocOnfbuFTRUyri%3Dha020J2g0%3DqL9KHoneY2SLAQXEQLudiQ%40mail.gmail.com.

[Max Rydahl Andersen]

On 31 Aug 2021, at 17:18, Loïc MATHIEU wrote:

Well, OK make is old, but my point is to use something developers already
know (so maybe not make but only a makefile) to lower the barrier to using
a new tool.

makefiles are actually surprisingly useful - especially if you just use it for what its good at.

I've had feisty discussions with a few people arguing that they want make because there is very
little a make file can do - it just list the commands you want to run..thats it.

maven is the opposite - it does not list the commands that are run - its somewhat declarative.

people chooses different poison.

Stuart

Create an app called test-app with the following extensions

and sample code
$ q create test-app
resteasy-reactive,hibernate-reactive-panache,graphql
$ cd test-app

Start dev mode, generate whatever pom.xml file is needed for

Eclipse (or IDEA or whatever) to grok my project setup
$ q dev --eclipse

Build me a jar

$ q jar

Build me a native exec

$ q native

And that's it. Well, that and probably we will indeed need

something to turn it into a real Maven/Gradle project (not just pretend

for the sake of the IDE): $ q regress --maven

And if we really are serious about catering to non-Java devs,
we will indeed have to fix the issues brought up about Java not having a
landing page for beginners, but that'd be a win anyway.

--
You received this message because you are subscribed to the
Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/quarkus-dev/0e82c5da-5df4-478f-be56-835c32847876n%40googlegroups.com

https://groups.google.com/d/msgid/quarkus-dev/0e82c5da-5df4-478f-be56-835c32847876n%40googlegroups.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the
Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czB3hDg8hC4RfSSDqgonkE1HZNy%2BCF71fLZJmUVnmgV1w%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czB3hDg8hC4RfSSDqgonkE1HZNy%2BCF71fLZJmUVnmgV1w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv6kgbfgX4pKeiEDy59%2BHyN4%2BuVGnS-2YDN9UMT4wmF8Rw%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv6kgbfgX4pKeiEDy59%2BHyN4%2BuVGnS-2YDN9UMT4wmF8Rw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

*www.logicdrop.com http://www.logicdrop.com/ *

--

You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3Dnw0WW-Xui1t7EcbhvfMSmF0PNMXitZRDOoLuTcBpzHg%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3Dnw0WW-Xui1t7EcbhvfMSmF0PNMXitZRDOoLuTcBpzHg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--

You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
Stéphane Épardaud

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVF2nEUtZf7U5bX3kXNhfsWBDmWmPoKV0ma8AWtMfYNS9g%40mail.gmail.com.

/max
https://xam.dk/about

[Max Rydahl Andersen]

On 31 Aug 2021, at 17:38, Ladislav Thon wrote:

út 31. 8. 2021 v 16:17 odesílatel Georgios Andrianakis gand...@redhat.com
napsal:

IIUC, the goal is to simplify things, not make them more complicated.
Bazel is not definitely not simple :)

I intentionally tried to stay away from this thread, but I just can't
anymore :-) In my opinion, something like Bazel (or Buck) is exactly what
the Java ecosystem needs, except it shouldn't look so alien and should
natively integrate with Maven repositories. I actually think the Quarkus
core infrastructue (aside: what happened to the PR that moved Quarkus to
Qlue?) is pretty well suited to implementing that. It would be a waste of
potential to only implement something trivial to cater for people coming
from other ecosystems (aside: the word "simple" is way too overloaded, see
also Simple Made Easy by Rich Hickey).

you are trying to solve the generic global build challenge if you are trying to apply bazel/buck to things here - thats explicitly not what this is about IMO.

I could see something like bazel/buck build system call into a quarkus/jbang build just fine.

Assuming I remember rightly how bazel/buck works ;)

/max

Stuart

Create an app called test-app with the following extensions

and sample code
$ q create test-app
resteasy-reactive,hibernate-reactive-panache,graphql
$ cd test-app

Start dev mode, generate whatever pom.xml file is needed for

Eclipse (or IDEA or whatever) to grok my project setup
$ q dev --eclipse

Build me a jar

$ q jar

Build me a native exec

$ q native

And that's it. Well, that and probably we will indeed need

something to turn it into a real Maven/Gradle project (not just pretend

for the sake of the IDE): $ q regress --maven

And if we really are serious about catering to non-Java devs,
we will indeed have to fix the issues brought up about Java not having a
landing page for beginners, but that'd be a win anyway.

--
You received this message because you are subscribed to the
Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/quarkus-dev/0e82c5da-5df4-478f-be56-835c32847876n%40googlegroups.com

https://groups.google.com/d/msgid/quarkus-dev/0e82c5da-5df4-478f-be56-835c32847876n%40googlegroups.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the
Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czB3hDg8hC4RfSSDqgonkE1HZNy%2BCF71fLZJmUVnmgV1w%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2czB3hDg8hC4RfSSDqgonkE1HZNy%2BCF71fLZJmUVnmgV1w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv6kgbfgX4pKeiEDy59%2BHyN4%2BuVGnS-2YDN9UMT4wmF8Rw%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv6kgbfgX4pKeiEDy59%2BHyN4%2BuVGnS-2YDN9UMT4wmF8Rw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

*www.logicdrop.com http://www.logicdrop.com/ *

--

You received this message because you are subscribed to the Google
Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3Dnw0WW-Xui1t7EcbhvfMSmF0PNMXitZRDOoLuTcBpzHg%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3Dnw0WW-Xui1t7EcbhvfMSmF0PNMXitZRDOoLuTcBpzHg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--

You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com
https://groups.google.com/d/msgid/quarkus-dev/CALeTM-k21rCVQ2xEZi_Y-i0h2BUVRF3yP27r3jLdUMK0JDNmiA%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALbocOnfbuFTRUyri%3Dha020J2g0%3DqL9KHoneY2SLAQXEQLudiQ%40mail.gmail.com.

/max
https://xam.dk/about

[Stuart Douglas]

It's not the worst idea I have ever heard, if it gives people an easy way to try out Quarkus :-)

[Stuart Douglas]

We already have support for maven and gradle, I don't think adding support for make or bazel would really buy us anything.

This is really about making it super fast and simple to get started, and giving an experience that is closer to the node experience that anything Java currently provides. After the refactor it should also be relatively easy to add support for other build tools, so you could potentially add a Quarkiverse bazel extension.

Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVEtup8B0G3m_-YV%2BEEP1A_Zsuce_szFpUsRY2ASk2fwwQ%40mail.gmail.com.

[Stuart Douglas]

On Wed, 1 Sept 2021 at 01:20, Georgios Andrianakis <gand...@redhat.com> wrote:

As an initial sceptic myself, I have warmed up to the idea, but I am assuming we are talking about something entirely new, but similar to what exists for example in the Node.js space and therefore easy to pick up for developers knowledgeable of that sort of ecosystem

Exactly. quarkus.json should basically look the same as package.json, even though they are not exactly the same thing it should just feel familiar.

Stuart

[KimJohn Quinn]

I have been meaning to chime in with a potential "story" about how a CLI "could" be helpful (that does not follow visibly Maven conventions):

1. A developer or "tech-savvy" business user clicks an "artifact" (project, resource/endpoint, etc)

2. Opens up Theia with a "flatter" view such as only "Code / Tests / Resources" (behind the scenes this could still use Maven for other configuration) but the view is less deep than a standard M2 structure.

3. They make changes, run, test, etc.  - It is still code as we do today but the structure is flattened to make it seem less complex.

Not fully vetted out but maybe gives an idea of a scenario we are exploring.  This could still apply to Java developers as well as non-developers and "other" developers.  Maven in its consistency can be overwhelming and the goal would be to get someone right into writing code without knowledge of the underlying build.  Basically, get to coding quickly - ignore everything around how you got there.

[George Gastaldi]

If possible, I'd like this tool to resolve Git URLs (including tags and branches) as project dependencies (as GoLang and jitpack.io do). 

 

My 2 cents ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAF1TLv7y8-kiwF_6gmSQQxVhqq0tRRdbUq3nMShH3T4mdd%3DAFA%40mail.gmail.com.

[Stuart Douglas]

On Wed, 1 Sept 2021 at 12:24, George Gastaldi <ggas...@redhat.com> wrote:

If possible, I'd like this tool to resolve Git URLs (including tags and branches) as project dependencies (as GoLang and jitpack.io do). 

That should be possible if they use the same tool to build. I don't know about trying to make that work with maven/gradle as well.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJi7o8TVUyLt%3D237ObCu837mi9EMGis6f9HHcvZNUjHTAA%40mail.gmail.com.

[Max Rydahl Andersen]

Jbang does that already for binary dependencies.

Does require jitpack or similar service to enable it but it is there. 

For source (re)builds things gets a bit funky though. 

Both are interesting but then we are talking not just fitting into existing ecosystem but making a separate one which is non-trivial to say the least :)

-- /max http://about.me/maxandersen

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJi7o8TVUyLt%3D237ObCu837mi9EMGis6f9HHcvZNUjHTAA%40mail.gmail.com.

[Loïc MATHIEU]

Hi,

Regarding directory structure, I don't think having a structure like the Maven one is an issue.
I often have other directory than the src one at the root of my Github repos, for example for doc, infrastructure script, k8s/helm resource, ...

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ef6d52cb-3030-40f2-bfc7-30e57d0956c0%40Spark.

[George Gastaldi]

After playing with Intellij plugins, I wonder why instead of reinventing the wheel, if it wouldn't be easier to invest in a richer Gradle plugin. It seems to be easier to extend than with Maven plugins or come up with a new build tool :)

[Max Rydahl Andersen]

Can You elaborate how a plug-in would help ?

-- /max http://about.me/maxandersen

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/98465f23-4bc2-46d4-9671-4aef50d91b5fn%40googlegroups.com.

[George Gastaldi]

Maybe I am missing something, but isn't the gist of this idea to be able to build a project using the Quarkus framework itself? 

I thought that writing a plugin could control that (in the same manner that using a different language like Kotlin and groovy do). 

[Georgios Andrianakis]

One thing that we should also make really easy should this be undertaken, is integration with JS tooling so users can easily add a simple frontend if needed

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJhAHe77s8xyDsO3eOYDvdKyy9febLEuyia%3D7OHDOSpQQA%40mail.gmail.com.