Introducing the Boost Maven/Gradle plugin for MicroProfile dev

[Scott Kurz]

Hi,

Scott Kurz from IBM (WebSphere / Open Liberty) here.

I'm posting here to follow-up our presentation on the Boost Maven/Gradle plugins which we delivered to the MP Hangouts last week (4/19) (recording at https://youtu.be/prqlxgtiPfQ?t=2165) and blogged about:  https://microprofile.io/2019/04/18/build-your-microprofile-apps-quickly-with-boost/

As explained in the demo and blog post, the idea of the Boost plugin is to allow a developer to develop and package a MicroProfile application by using a single plugin goal (Gradle task) and a single set of fine-grained dependencies to run the application against any supported target runtime (such as Open Liberty, Tom EE, etc.)

The plugin's "package" goal (task) will install a supported "runtime" and deploy the project application to it, and also provide a vendor-neutral configuration layer around the target runtime (e.g. using a set of "boost" properties).

Assuming Boost were integrated with the MicroProfile Starter, the Starter would continue to generate a common set of API dependencies and application contents (such as  src/main/resources/META-INF/microprofile-config.properties)
But instead of generating different plugin goals and configuration for each target runtime (which the Starter currently does), we would encapsulate that into a single, common boost goal, whose implementation would supply the different function required for each runtime implementation.

By developing such a Boost function in the MicroProfile community, we could:

  * Provide a more common configuration for a diverse set of supported MicroProfile runtime implementations, such as the prototype using boost properties for HTTP port and database URL to generate an opinionated configuration of the selected target runtime, backing the application project.

  * Add a Gradle-based plugin capable of developing MicroProfile applications

  * Simplify the pom.xml, making it easier to edit by hand and reducing the need for the MicroProfile starter to generate the correct pom.xml

-----

For those who didn't join the MP Hangout call, let me echo back one concern raised.

This was whether the community getting behind this Boost function could introduce a gate for each new release of the MicroProfile specification, with each supported implementation needing enhancement to support the new function. 

Though that seems to skip a few steps (right from "what is this?" to "how do we maintain it?") there were a couple responses: mentioning that there is both a common layer that needs updating (e.g. the new BOM) and some kind of "adapter" layer unique to each supported implementation, and a suggestion that the Arquillian approach to managing implementation-specific adapters could be a useful pattern.

I don't mean to dwell on this one subtopic..just catching the email thread up with the live conversation a bit.

-----

One note on the current state of the Boost code / project:

Right now, to prototype/demo with Boost requires you to build the Boost plugin repo yourself, locally.   

That's partly because the Boost function is currently part of a bigger codebase that is more tightly-coupled with Open Liberty / WebSphere Liberty (and the releases/snapshots we have released correspond to earlier iterations).   Still, you can view the 'master' branch at:  https://github.com/OpenLiberty/boost/tree/master/boost-maven  (we link to Maven since we're still working on getting to equivalence with Gradle).   Though the issues with comments in the existing project may of interest, much of this content still reflects the older Liberty focus, and so engaging in this forum thread is the best way to continue the discussion (rather than engaging directly in discussion on the issues just yet).

-----

OK, I expect (hope) we will soon get more questions about what is vs. isn't implemented to date, and from there we can jump into discussing what our near-term priorities could be..  but let me send this post out first as is for comment.

Thanks in advance for your thoughts,
Scott Kurz

[Ken Finnigan]

I've been mulling this over since the Hangout, and I'm not convinced there's a benefit to having a generic plugin.

I agree it does simplify the pom.xml for the Starter, but it also creates a "one size fits all" problem.

If we were talking about packaging and deploying to Java EE/Jakarta EE application servers, then something like this would be of great benefit. But I don't see the benefits when MicroProfile implementers can choose to package and deploy their application in any way they want, as the platform does not mandate how that should be done.

Further to "one size fits all", it wouldn't be fair to add functionality to the plugin that not all implementors provide, as then the plugin would fail for those situations. What it results in is that anything that's specific to an implementor only exists in their own plugin, and then they need to provide instructions on how to change the "common" pom.xml to use their plugin to take advantage of that implementation specific feature.

In terms of updating Starter, it's an additional hurdle for new implementations, and possibly versions of an implementation, that they need to be present within the "Boost" plugin, and have the release done and updated in Starter before they can be added to the Starter.

Overall, the small benefit in a common plugin is far outweighed by the problems it introduces, at least from my perspective.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cbb74408-0358-45b4-b593-bc31b7509d91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Kurz]

Sorry all for the slow response,  I had to take off some days unexpectedly.

Ken, thanks for the comments. 

On Thursday, April 25, 2019 at 11:38:02 AM UTC-4, Ken Finnigan wrote:

If we were talking about packaging and deploying to Java EE/Jakarta EE application servers, then something like this would be of great benefit. But I don't see the benefits when MicroProfile implementers can choose to package and deploy their application in any way they want, as the platform does not mandate how that should be done.

There may be a diversity of packaging options but if you have a Maven project there basically has to be a JAR and/or a WAR type package (possibly EAR).    We can move the packaging details for a given MicroProfile implementation into the Boost plugin so the end user can simply select a packaging type of WAR vs JAR and let Boost package its opinion of the best JAR or WAR for the given runtime.    This would seem more convenient than referring to the individual plugin documentations or back to the MicroProfile starter to understand how to package for a given MicroProfile implementation.

Boost isn't going to take it upon itself to, say, implement runnable JAR support for a MicroProfile implementation that doesn't already support one.   Though if the Boost influence led to more normalization in packaging across different MicroProfile implementations, I don't think that would be a bad thing.

 

Further to "one size fits all", it wouldn't be fair to add functionality to the plugin that not all implementors provide, as then the plugin would fail for those situations. What it results in is that anything that's specific to an implementor only exists in their own plugin, and then they need to provide instructions on how to change the "common" pom.xml to use their plugin to take advantage of that implementation specific feature.

So the plugins are potentially going to have different features and the implementations will also have different features.

We think abstracting over the differences in the plugin features can be done in a way that is worth the tradeoff of losing plugin-specific features.

The Boost 'package' goal handles installing a runtime dependency into the project 'target' directory (optionally installing other key dependencies like DBs), deploying an application to it, and configuring that runtime using the boost configuration layer , and building a package from the app + runtime.   When combined with Boost start/stop/run/debug goals, the developer ends up getting a simple, common goal->phase mapping ("lifecycle" if that's not too overloaded),  which makes up for the loss of customization you'd get by pushing the unique aspects out of the user pom.xml and into the Boost plugin.

Was there another plugin use case you had in mind here that would not be as easy to generalize over?

And also... dealing with the different features and different configuration mechanisms among implementations is a whole other matter.      I'm not sure this was even part of your objection here though so don't mean to dive into that.   The short answer is that on this we think this would eventually become a topic for the Boost community to address. 

 

In terms of updating Starter, it's an additional hurdle for new implementations, and possibly versions of an implementation, that they need to be present within the "Boost" plugin, and have the release done and updated in Starter before they can be added to the Starter.

It's hard to compare the difficulty in updating Starter now vs. with Boost since we haven't really shared any vision on an adapter architecture or mechanism to judge against (having taken shortcuts in keeping this all in one project/repo). 

But if you imagine something like with Arquillian adapters where you implement a Boost-defined "adapter" SPI and then release an artifact (with someone maybe later updating the core Boost project BOM), then it doesn't necessarily sound harder for an implementation.   

For an implementation that has an existing Maven plugin with existing goals and config, well, pushing up the POM snippet into https://github.com/eclipse/microprofile-starter/blob/master/src/main/resources/pom-servers.xml is pretty straightforward.  

But for a new implementation without an existing Maven plugin, etc., implementing the Boost SPI might be simpler than creating a new plugin.     If the adapters can be written to support Maven and Gradle both this could allow a core Boost Gradle plugin too to extend Gradle support to these implementations at the same time. 

Scott

[Ken Finnigan]

On Tue, Apr 30, 2019 at 5:01 PM Scott Kurz <scot...@gmail.com> wrote:

Sorry all for the slow response,  I had to take off some days unexpectedly.

Ken, thanks for the comments. 

On Thursday, April 25, 2019 at 11:38:02 AM UTC-4, Ken Finnigan wrote:

If we were talking about packaging and deploying to Java EE/Jakarta EE application servers, then something like this would be of great benefit. But I don't see the benefits when MicroProfile implementers can choose to package and deploy their application in any way they want, as the platform does not mandate how that should be done.

There may be a diversity of packaging options but if you have a Maven project there basically has to be a JAR and/or a WAR type package (possibly EAR).    We can move the packaging details for a given MicroProfile implementation into the Boost plugin so the end user can simply select a packaging type of WAR vs JAR and let Boost package its opinion of the best JAR or WAR for the given runtime.    This would seem more convenient than referring to the individual plugin documentations or back to the MicroProfile starter to understand how to package for a given MicroProfile implementation.

I don't think moving application packaging details to a plugin solves the problem. If a developer has defined the Maven project to be of type WAR, but the runtime support WAR packaging, does the user get an error? If so, how is that less user friendly than needing to use custom plugin configuration per runtime?

 

Boost isn't going to take it upon itself to, say, implement runnable JAR support for a MicroProfile implementation that doesn't already support one.   Though if the Boost influence led to more normalization in packaging across different MicroProfile implementations, I don't think that would be a bad thing.

 

Further to "one size fits all", it wouldn't be fair to add functionality to the plugin that not all implementors provide, as then the plugin would fail for those situations. What it results in is that anything that's specific to an implementor only exists in their own plugin, and then they need to provide instructions on how to change the "common" pom.xml to use their plugin to take advantage of that implementation specific feature.

So the plugins are potentially going to have different features and the implementations will also have different features.

We think abstracting over the differences in the plugin features can be done in a way that is worth the tradeoff of losing plugin-specific features.

That doesn't make any sense to me. If a runtime offered something "cool" in their plugin that no one else does, they must then educate all their users that if their application was created to use the Boost plugin they need to change it back to using their custom plugin to do the "cool" thing.

 

The Boost 'package' goal handles installing a runtime dependency into the project 'target' directory (optionally installing other key dependencies like DBs), deploying an application to it, and configuring that runtime using the boost configuration layer , and building a package from the app + runtime.   When combined with Boost start/stop/run/debug goals, the developer ends up getting a simple, common goal->phase mapping ("lifecycle" if that's not too overloaded),  which makes up for the loss of customization you'd get by pushing the unique aspects out of the user pom.xml and into the Boost plugin.

To me, what you describe above is very much traditional Java EE Application Server type deployment situations.

Not all runtimes have a runtime dependency that is "installable" into the target directory, to then create a combined app and runtime package.

How does Boost work when there is no single runtime piece and it's a combination of Maven dependencies?

You presume that all plugins offer start/stop/run/debug goals. Is that the case today?

 

Was there another plugin use case you had in mind here that would not be as easy to generalize over?

And also... dealing with the different features and different configuration mechanisms among implementations is a whole other matter.      I'm not sure this was even part of your objection here though so don't mean to dive into that.   The short answer is that on this we think this would eventually become a topic for the Boost community to address. 

 

In terms of updating Starter, it's an additional hurdle for new implementations, and possibly versions of an implementation, that they need to be present within the "Boost" plugin, and have the release done and updated in Starter before they can be added to the Starter.

It's hard to compare the difficulty in updating Starter now vs. with Boost since we haven't really shared any vision on an adapter architecture or mechanism to judge against (having taken shortcuts in keeping this all in one project/repo). 

But if you imagine something like with Arquillian adapters where you implement a Boost-defined "adapter" SPI and then release an artifact (with someone maybe later updating the core Boost project BOM), then it doesn't necessarily sound harder for an implementation.   

For an implementation that has an existing Maven plugin with existing goals and config, well, pushing up the POM snippet into https://github.com/eclipse/microprofile-starter/blob/master/src/main/resources/pom-servers.xml is pretty straightforward.  

But for a new implementation without an existing Maven plugin, etc., implementing the Boost SPI might be simpler than creating a new plugin.     If the adapters can be written to support Maven and Gradle both this could allow a core Boost Gradle plugin too to extend Gradle support to these implementations at the same time. 

Even if it took the approach of the Arquillian style adapters, it's an additional hurdle for implementors to develop, maintain, and release these adapters, maybe in conjunction with updates to the plugin. Maintenance is higher as it needs to account for Boost plugin changes that necessitate updating these adapters.

I can't remember if it was mentioned during the call, but how does Gradle play into this? Though the Starter I think only deals with Maven, if it were to add Gradle support how does the Boost plugin work with Gradle?

 

Scott

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/98334323-9743-46b0-bc02-291d2a2c580b%40googlegroups.com.

[Scott Kurz]

On Thursday, May 2, 2019 at 2:41:45 PM UTC-4, Ken Finnigan wrote:

I don't think moving application packaging details to a plugin solves the problem. If a developer has defined the Maven project to be of type WAR, but the runtime support WAR packaging, does the user get an error? If so, how is that less user friendly than needing to use custom plugin configuration per runtime?

I think this would make the supported packaging type + runtime pairs easier to work with and the unsupported packages no worse.

The MP Starter runtime-specific logic could still play a role for less-experienced users, steering them to a supported/preferred packaging type (e.g. WAR vs. JAR)  for a given runtime.   The simple, common boost plugin configuration could improve the user experience with supported packaging type + runtime combinations, plus make it simpler to add without having to refer back to or regenerate from the MicroProfile starter.

 

 We think abstracting over the differences in the plugin features can be done in a way that is worth the tradeoff of losing plugin-specific features.

That doesn't make any sense to me. If a runtime offered something "cool" in their plugin that no one else does, they must then educate all their users that if their application was created to use the Boost plugin they need to change it back to using their custom plugin to do the "cool" thing.

...

 

To me, what you describe above is very much traditional Java EE Application Server type deployment situations.

Not all runtimes have a runtime dependency that is "installable" into the target directory, to then create a combined app and runtime package.

(Replying to both points):

But for MicroProfile implementations where the developer workflow/lifecycle does map well to this set of abstractions / operations (package, run/start/debug, stop), whether because of a Java EE heritage or not, the Boost plugin simplifies the Maven / Gradle developer experience. 

This type of packaging is used today by a significant set of implementations, which are served today by implementation-specific plugins which must be learned, just a means to deploy the app to the runtime which maybe contains the innovation the developer is really interested in.

If an implementation did wanted to enhance the Maven/Gradle "package" experience for Boost users, this could be added into that implementation's Boost adapter.  

There are questions to work through like what happens if the Boost plugin / runtime configuration does not have every config option available and I need to drop into the "native" impl-specific plugin and/or runtime configuration?     If these end up being just a relative few "corner cases" then I could see them getting value from using the Boost-defined dependencies even while perhaps not using the Boost plugin (or using it alongside the native plugin).

But I think the bigger objection might be the question:  what if an implementation wanted to innovate in a way such that the lifecycle (including "package", etc.) were no longer a good fit?     

 

How does Boost work when there is no single runtime piece and it's a combination of Maven dependencies?

We haven't developed this case any, but I could imagine we have some generic adapters like ExecutableJarAdapter in the Boost project itself.    

 

You presume that all plugins offer start/stop/run/debug goals. Is that the case today?

Each implementation will need to write an adapter, either pointing to an implementation-specific plugin's analogous goal or writing some other code to do the same.

 

It's hard to compare the difficulty in updating Starter now vs. with Boost since we haven't really shared any vision on an adapter architecture or mechanism to judge against (having taken shortcuts in keeping this all in one project/repo). 

But if you imagine something like with Arquillian adapters where you implement a Boost-defined "adapter" SPI and then release an artifact (with someone maybe later updating the core Boost project BOM), then it doesn't necessarily sound harder for an implementation.   

For an implementation that has an existing Maven plugin with existing goals and config, well, pushing up the POM snippet into https://github.com/eclipse/microprofile-starter/blob/master/src/main/resources/pom-servers.xml is pretty straightforward.  

But for a new implementation without an existing Maven plugin, etc., implementing the Boost SPI might be simpler than creating a new plugin.     If the adapters can be written to support Maven and Gradle both this could allow a core Boost Gradle plugin too to extend Gradle support to these implementations at the same time. 

Even if it took the approach of the Arquillian style adapters, it's an additional hurdle for implementors to develop, maintain, and release these adapters, maybe in conjunction with updates to the plugin. Maintenance is higher as it needs to account for Boost plugin changes that necessitate updating these adapters.

So I'd like to address this by putting out there an adapter SPI design.   I don't believe every implementation even has a Maven/Gradle plugin, so I'm not sure this is necessarily a higher maintenance cost, but it's probably better to have the discussion against a more concrete proposal and we haven't done that yet.   Will follow-up soon, maybe this week.

I can't remember if it was mentioned during the call, but how does Gradle play into this? Though the Starter I think only deals with Maven, if it were to add Gradle support how does the Boost plugin work with Gradle?

Yes, we had planned to have a core Boost Maven & Gradle plugin.   As far as the adapter, it would seem nice to allow each implementation to have one adapter that could handle each, rather than each of a Maven + a Gradle adapter.   Still, we are just prototyping this now so again, I will follow-up shortly with a proposal.

Scott

[Ken Finnigan]

On Mon, May 6, 2019 at 11:39 AM Scott Kurz <scot...@gmail.com> wrote:

On Thursday, May 2, 2019 at 2:41:45 PM UTC-4, Ken Finnigan wrote:

I don't think moving application packaging details to a plugin solves the problem. If a developer has defined the Maven project to be of type WAR, but the runtime support WAR packaging, does the user get an error? If so, how is that less user friendly than needing to use custom plugin configuration per runtime?

I think this would make the supported packaging type + runtime pairs easier to work with and the unsupported packages no worse.

The MP Starter runtime-specific logic could still play a role for less-experienced users, steering them to a supported/preferred packaging type (e.g. WAR vs. JAR)  for a given runtime.   The simple, common boost plugin configuration could improve the user experience with supported packaging type + runtime combinations, plus make it simpler to add without having to refer back to or regenerate from the MicroProfile starter.

I fear this creates a plugin that needs to be all things to all runtimes, which isn't realistic in my view.

 

 

 We think abstracting over the differences in the plugin features can be done in a way that is worth the tradeoff of losing plugin-specific features.

That doesn't make any sense to me. If a runtime offered something "cool" in their plugin that no one else does, they must then educate all their users that if their application was created to use the Boost plugin they need to change it back to using their custom plugin to do the "cool" thing.

...

 

To me, what you describe above is very much traditional Java EE Application Server type deployment situations.

Not all runtimes have a runtime dependency that is "installable" into the target directory, to then create a combined app and runtime package.

(Replying to both points):

But for MicroProfile implementations where the developer workflow/lifecycle does map well to this set of abstractions / operations (package, run/start/debug, stop), whether because of a Java EE heritage or not, the Boost plugin simplifies the Maven / Gradle developer experience. 

My concern here is that what is proposed takes the developer out of the typical Maven or Gradle build lifecycle they might expect, and hides it all away inside a new plugin.

 

This type of packaging is used today by a significant set of implementations, which are served today by implementation-specific plugins which must be learned, just a means to deploy the app to the runtime which maybe contains the innovation the developer is really interested in.

If an implementation did wanted to enhance the Maven/Gradle "package" experience for Boost users, this could be added into that implementation's Boost adapter.  

There are questions to work through like what happens if the Boost plugin / runtime configuration does not have every config option available and I need to drop into the "native" impl-specific plugin and/or runtime configuration?     If these end up being just a relative few "corner cases" then I could see them getting value from using the Boost-defined dependencies even while perhaps not using the Boost plugin (or using it alongside the native plugin).

But I think the bigger objection might be the question:  what if an implementation wanted to innovate in a way such that the lifecycle (including "package", etc.) were no longer a good fit?

That's the point I made previously around what goals are supported. You either end up in a situation where a runtime wants everyone to move to their own plugin because it has functionality that isn't present in Boost, or Boost has goals that don't work for all runtimes. Neither is a great situation to be in.

 

 

How does Boost work when there is no single runtime piece and it's a combination of Maven dependencies?

We haven't developed this case any, but I could imagine we have some generic adapters like ExecutableJarAdapter in the Boost project itself.    

As the Boost plugin has evolved from the idea of traditional Application Server deployments, until such time as it can be shown to work with packaging options for all runtimes, it's really a non starter.

 

 

You presume that all plugins offer start/stop/run/debug goals. Is that the case today?

Each implementation will need to write an adapter, either pointing to an implementation-specific plugin's analogous goal or writing some other code to do the same.

So if a runtime doesn't offer a "debug" goal, for instance, should Boost still offer "debug" and just spit out an error if a runtime doesn't support it?

As I mentioned previously, requiring runtimes to do all this work to be part of the Boost plugin increases the effort threshold for potential new implementations.

 

 

It's hard to compare the difficulty in updating Starter now vs. with Boost since we haven't really shared any vision on an adapter architecture or mechanism to judge against (having taken shortcuts in keeping this all in one project/repo). 

But if you imagine something like with Arquillian adapters where you implement a Boost-defined "adapter" SPI and then release an artifact (with someone maybe later updating the core Boost project BOM), then it doesn't necessarily sound harder for an implementation.   

For an implementation that has an existing Maven plugin with existing goals and config, well, pushing up the POM snippet into https://github.com/eclipse/microprofile-starter/blob/master/src/main/resources/pom-servers.xml is pretty straightforward.  

But for a new implementation without an existing Maven plugin, etc., implementing the Boost SPI might be simpler than creating a new plugin.     If the adapters can be written to support Maven and Gradle both this could allow a core Boost Gradle plugin too to extend Gradle support to these implementations at the same time. 

Even if it took the approach of the Arquillian style adapters, it's an additional hurdle for implementors to develop, maintain, and release these adapters, maybe in conjunction with updates to the plugin. Maintenance is higher as it needs to account for Boost plugin changes that necessitate updating these adapters.

So I'd like to address this by putting out there an adapter SPI design.   I don't believe every implementation even has a Maven/Gradle plugin, so I'm not sure this is necessarily a higher maintenance cost, but it's probably better to have the discussion against a more concrete proposal and we haven't done that yet.   Will follow-up soon, maybe this week.

I'm pretty sure all the implementations I've looked at all either have their own plugin for packaging, or they use some combination of plugins to achieve it.

Whether they have an existing plugin or not, it definitely increases the maintenance cost and effort for implementors to support a Boost plugin.

 

I can't remember if it was mentioned during the call, but how does Gradle play into this? Though the Starter I think only deals with Maven, if it were to add Gradle support how does the Boost plugin work with Gradle?

Yes, we had planned to have a core Boost Maven & Gradle plugin.   As far as the adapter, it would seem nice to allow each implementation to have one adapter that could handle each, rather than each of a Maven + a Gradle adapter.   Still, we are just prototyping this now so again, I will follow-up shortly with a proposal.

Scott

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7e2b79f4-e470-42f4-933e-09ba6f6191df%40googlegroups.com.

[Emily Jiang]

Thank you Scott and Ken for sharing your views!

Ken, let me try to address your concerns.

1. It is not the intention to force all runtimes to adopt this plugin. We would like to share our plugin in the community so that the interested parties can use it. At the moment, David B (Tomitribe) likes it. I also asked Rudy from Payara. Rudy would like us to share the code first. We will share the code under sandbox. Then I will get in touch with Helidon, Kumuluzee etc to see whether they would like to use boost.

2. The value of using boost: we try to reduce duplication on plugins among runtime, so we decided to opensource the boost plugin under microprofile community. At the moment, there are separate plugins scattered around. it is different for developers to find out the details. If we centralise the plugin, we can work together to improve the base and share our knowledge and innovate and improve together. If one runime does not provide  a particular capability, e.g. debug phrase in your example, the lack of support in that area will encourage that runtime to provide such capability, which eventually benefit that runtime and end users. Before such phase is provided, that runtime should not be opted in, in order to avoid problems.

3. For your comment of flexible plugins, I am wondering what extra capabilities the specific plugin you refer to. Can you share here so that we will see whether we can innovate together to expand the boost plugin.

Since we have a starter now, it is great to commonarise the runtime plugins to create a seamless ecosystem under our MicroProfile community. I see this provides a common ground to innovate and work together. I see plugin has different targets as listed by Scott. All internal stuff should be in the runtime integration part.

Just summarise again, the boost plugin is optional, based on opt-in pattern. If some runtime does not want to use it, it is fine. Our MP starter still calls the dedicated plugin. Having boost plugin does not complicate starter but rather simplify a bit (at least Open Liberty and TomEE will share the similar pom.xml and I am hoping the list will grow soon).

Please stay tuned with the code drop in under sandbox.

Thanks

Emily

[Ken Finnigan]

Emily,

You state the intention is not to force runtimes to adopt the plugin, but by virtue of there being a plugin that other runtimes use and one runtime may not be part of, it creates implicit forcing to adopt the plugin or be excluded from use with the runtimes that do adopt it. For me, that adds a large additional barrier to entry, perceived or otherwise.

Saying the Boost plugin is optional doesn't mean anything as having some of the runtimes using it creates a view that others are being excluded, and that they must implement to get the same exposure.

I'll say it again. For what the benefits of the plugin achieve, there are far too many cons from my point of view.

Ken

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/204baa25-2de8-4f6d-8bb7-2fd1fe25ef83%40googlegroups.com.

[Emily Jiang]

Ken,

If one runtime wants to maintain its own plugin, it might have something special or something else. I don't think this is a valid reason to block others from sharing something in common. At the moment, we have 6 or 7 plugins. With this effort, we can reduce some duplication and reduce the number of plugins and create some seamless migration, so that end users can easily move around among app servers.

Let's see the sandbox code and then follow up.

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Ken Finnigan]

Emily,

I really don't see any benefit to a common plugin, and only lots of pain and annoyance. We already have a starter where it's possible to select any runtime. If we want to enable switching, then maybe we update the starter to support adding all runtimes for a given MP version into different profiles, as opposed to a common plugin that will struggle to be all things to everyone. Otherwise we're trying to create a solution to a non problem.

Are we arguing that a common plugin is better than 100 lines in a pom.xml? Is this really something MP should be concerned with?

Having a common plugin doesn't reduce duplication at all, it just hides it into a single thing. All the duplication is still there, as every runtime has their own way to package/start/stop/etc.

Having a goal of seamless migration between runtimes is not something we've ever strived for in MicroProfile. For sure we endeavor to make MP application code portable, but to say we should try to make switching runtimes "zero effort" is a very different goal.

You mention that it's fine if some runtimes don't want to participate in the common plugin, but then we've created a two tier system of runtimes. Runtimes that have their own plugins, and runtimes that shoe-horned their plugin into the common one. There will also be a perception that runtimes that don't support the common plugin are somehow less portable, even though that wouldn't be the case at all.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b1fdcb79-f0b1-477b-a59e-9ee4eed0a859%40googlegroups.com.

[Scott Kurz]

We're not just intending to hide impl-specific differences for the sake of portability, but also to make working with the individual plugins easier.    The MicroProfile starter is a good first step, but it's not going to generate every line of pom.xml you'll ever need to write.

We also see Boost helping with the "flattening" of impl-specific config into:

1. Boost properties 
2. Maven dependencies.

E.g. the demo app https://github.com/OpenLiberty/boosted-microprofile-rest-client/blob/master/pom.xml showed default Datasource configured via the boost.db.url  property plus JDBC driver dependency and the JAX-RS endpoint port via boost.http.port.

So right now, if I want to give a new implementation a try, I have to read the documentation for how to add a JDBC driver either through the impl-specific plugin and/or something like dependency or download plugin, and add the impl-specific parameter/property or whatever.

Maybe the JDBC driver is a first-class dependency or maybe not.    (I don't think the MicroProfile starter today helps with this either; it never intended to.)

The next component, however, may then be pulled in and configured totally differently, in each implementation.

So that's a significant learning curve working with new function in new implementation.   To the extent that adding something new is just "add a boost property" and/or "add a dependency", it could make things easier.   

---

Now, we can fast-forward to the case where the simplified Boost configuration layer isn't enough for a given function + implementation.     Boost isn't going to immediately, magically add configuration for every property in every implementation in the foreseeable future.

So should Boost be architected to seamlessly allow you to also use the "native" impl-specific plugin in the same project?   Or do we shoot to cover 80% of cases (or maybe "all" the starter-generated projects) with Boost and recognize that there are going to be special cases where Boost isn't a good fit and deal with that somehow?    

That'd be a good question.   It's something we need to discuss but we wanted to start by trying to put something out there to make development easier for new users, even without having settled all that at this point.

Scott

[Scott Kurz]

On Thursday, May 16, 2019 at 5:53:00 PM UTC-4, Scott Kurz wrote:

We're not just intending to hide impl-specific differences for the sake of portability, but also to make working with the individual plugins easier.   

Sorry for the chatter.. maybe obvious but I should point out I meant to say "intending.... to make working with the individual implementations easier".

(not "plugins")

Scott

[Hristo Stoyanov]

Scott,

I previously had issues with the existing OpenLiberty gradle plugin as documented here:

https://github.com/WASdev/ci.gradle/issues/167

The issue was closed because the packaging in OL is way too simplistic and could not fit my use cases. My concern is that the universal  plug-in you suggest will fail even more.

[Bruno Borges]

Hi all,

As a user, thought about sharing my point of view here.

The universal plugin doesn't have to cover 100% of the use cases. If it covers 60-80% of the use cases, and if it covers *really well* quickstart scenarios, then that is already a success. The challenge to any developer who's looking to invest in MicroProfile, is on getting started, and that includes learning APIs as much as toolchain. Having a good generic plugin solves the toolchain for sure.

Before this discussions tries to evaluate whether the plugin might fail or not, I'd say we should first decide what success means to a hypothetical generic plugin.

I have advocated for years for start.microprofile.io, and I am extremely happy to see that project came to life. I have also advocated for years to have a generic toolchain for Java EE in the past, and I'd say this is the right thing to do as well for MicroProfile.

For users who have obtained enough knowledge and have chosen specific runtimes, then of course they might as well move on to the specific plugins of those runtimes, for more advanced setups and scenarios - perhaps even for commercial support.

m2c

[Ladislav Thon]

Hi all,

sorry for not commenting sooner, I wanted to comment on this thread for quite some time.

As a user, I'm very much not a fan. I don't want to be stuck with the lowest common denominator of all MicroProfile implementations -- and since the implementations vary a lot, the lowest common denominator is low indeed. When the time comes to move from the common ground to runtime-specific level (be it additional APIs, additional deployment features etc.), this will be more work from me than if I started directly with the runtime-specific stuff. (Personally, I have never liked opinionated solutions, because you can't possibly know what I need better than me. I'm competent enough to choose what runtime I want and how to use it.)

As a developer of one of the runtimes that support MicroProfile, I'm not a fan either. We already have a Maven plugin, and I'm not terribly excited about having to support another one for our users. We offer more features than just MicroProfile (I've seen there's a "booster" for JPA??), we have a rich configuration model, we have an extra Arquillian adapter, etc. When our users want to use these things, I want that to be completely seamless. For example, can we abstract over Arquillian adapters? I doubt that. When our users want to write integration tests for their code, they will already have to use runtime-specific stuff. When they want to configure more than what Boost decides to offer, again they have to resort to runtime-specific features. That's gonna feel alien, and it will be more complex and more time-consuming. To be blunt -- I fear that Boost is going to shoehorn our users into a little subset of what we can provide.

Also, what is it that we're trying to "standardize" here? It's not APIs, it's not production deployment, so is it a developer experience? If so, again it seems it's a small subset, and I personally don't feel we've reached a point where developer experience is a done deal ready for commoditizing.

LT

pá 17. 5. 2019 v 1:46 odesílatel Bruno Borges <bruno....@gmail.com> napsal:

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5bce1a37-a960-41d7-a261-431860dfbdf0%40googlegroups.com.

[Emily Jiang]

+1 Bruno! You nailed it! The other advantage I can see that developers created their microservice for one runtime and then later on want to try on a different server, all he/she needs to do is to change a few character in the project's pom.xml. I cannot wait to demo it.

Hristo, I am sorry to hear your experience. When  bringing the plugin under MicroProfile, it has a greater potential to expose to a big audience and get connected with other communities e.g. gradle,  maven community better. Andres Almiray, Gradle Advocate, mentioned to me a few times that he would like to see gradle support in MicroProfile and would like to help. If MicroProfile plugin hits a gradle limitation, I think it has a bigger impact in gradle community than a single vendor.

We should not stop doing something just because we worry it might fail. We should try our best to make it work.

Thanks
Emily

[Ken Finnigan]

One thing I haven't mentioned previously, it needs to be noted that the ideas around a Maven plugin would change the goals of MicroProfile and what we've strived to do so far. "Optimizing Java for an Enterprise Architecture" as a mission is very much focused on APIs and functionality, at least in my opinion. What is being proposed would push MicroProfile into the realm of all things "tooling", which is an extremely huge ecosystem where every developer has their own preferences for tools and ways of working.

With respect to your comments Scott, I have some feedback:

1. Sure the MicroProfile Starter isn't going to generate every line of a pom.xml that might be needed. But why should it? To me that indicates a developer isn't capable of understanding what needs to be done, so we're going to do it for you. When you go down that road, we get an outcome that no one is happy with because it's too opinionated and follows a very specific usage path
2. Boost properties are a bad idea. Yes they make it fast to run locally by setting some properties in a plugin, but what happens for production, or deploying to Cloud environments? The properties for the plugin are meaningless at that point. All we've done is delay the developer from needing to know what the properties might be for a particular runtime. If we really think that some common properties for HTTP port, etc are necessary, then let's define some MP level properties that are expected to be used by a runtime.
3. One of the properties you mention is DB URL. As MP doesn't have any data solution at present, offering property settings related to solutions outside MP doesn't make any sense. Expecting a runtime to convert this DB URL for use with Hibernate or EclipseLink, or any data solution, even though MP doesn't have a spec around any of those is not realistic.

One other point of note. Though I wasn't at the MP Starter meeting the other day [1], it was mentioned that Payara Micro will not work with the plugin. From the looking at the plugin code I've done, I don't believe it would work for Thorntail or Quarkus either.

[1] - https://docs.google.com/document/d/1qH5PoOAvr25P6ObVbc09tJNjWJvU2FbPhzVg5zblqx8/edit

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/96b745fb-3068-4739-a933-e58b3ae8938e%40googlegroups.com.

[Emily Jiang]

One of MicroProfile missions is to support portability and interoperability. With the common plugin, it is much easier to move among app servers. 

Though I wasn't at the MP Starter meeting the other day [1], it was mentioned that Payara Micro will not work with the plugin. 

I was at that meeting and was involved in the conversation. I think you misunderstood the minutes. Rudy just said Payara does not support composable images at the moment, which is a requirement by the tool though. He would like to see the source code of plugin. He didn’t say Payara doesn’t work with the plugin. Besides we are not trying to universally generate same images. 

Thanks 

Emily 

On May 17, 2019 at 1:44 pm, <Ken Finnigan> wrote:

One thing I haven't mentioned previously, it needs to be noted that the ideas around a Maven plugin would change the goals of MicroProfile and what we've strived to do so far. "Optimizing Java for an Enterprise Architecture" as a mission is very much focused on APIs and functionality, at least in my opinion. What is being proposed would push MicroProfile into the realm of all things "tooling", which is an extremely huge ecosystem where every developer has their own preferences for tools and ways of working.

With respect to your comments Scott, I have some feedback:

1. Sure the MicroProfile Starter isn't going to generate every line of a pom.xml that might be needed. But why should it? To me that indicates a developer isn't capable of understanding what needs to be done, so we're going to do it for you. When you go down that road, we get an outcome that no one is happy with because it's too opinionated and follows a very specific usage path
2. Boost properties are a bad idea. Yes they make it fast to run locally by setting some properties in a plugin, but what happens for production, or deploying to Cloud environments? The properties for the plugin are meaningless at that point. All we've done is delay the developer from needing to know what the properties might be for a particular runtime. If we really think that some common properties for HTTP port, etc are necessary, then let's define some MP level properties that are expected to be used by a runtime.
3. One of the properties you mention is DB URL. As MP doesn't have any data solution at present, offering property settings related to solutions outside MP doesn't make any sense. Expecting a runtime to convert this DB URL for use with Hibernate or EclipseLink, or any data solution, even though MP doesn't have a spec around any of those is not realistic.

One other point of note. Though I wasn't at the MP Starter meeting the other day [1], it was mentioned that Payara Micro will not work with the plugin. From the looking at the plugin code I've done, I don't believe it would work for Thorntail or Quarkus either.

[1] - https://docs.google.com/document//1qH5PoOAvr25P6ObVbc09tJNjWJvU2FbPhzVg5zblqx8/edit

On Thu, May 16, 2019 at 5:53 PM Scott Kurz <scot...@gmail.com> wrote:

We're not just intending to hide impl-specific differences for the sake of portability, but also to make working with the individual plugins easier.    The MicroProfile starter is a good first step, but it's not going to generate every line of pom.xml you'll ever need to write.

We also see Boost helping with the "flattening" of impl-specific config into:

1. Boost properties 
2. Maven dependencies.

E.g. the demo app https://github.com/OpenLiberty/boosted-microprofile-rest-client/blob/master/pom.xml showed default Datasource configured via the boost.db.url  property plus JDBC driver dependency and the JAX-RS endpoint port via boost.http.port.

So right now, if I want to give a new implementation a try, I have to read the documentation for how to add a JDBC driver either through the impl-specific plugin and/or something like dependency or download plugin, and add the impl-specific parameter/property or whatever.

Maybe the JDBC driver is a first-class dependency or maybe not.    (I don't think the MicroProfile starter today helps with this either; it never intended to.)

The next component, however, may then be pulled in and configured totally differently, in each implementation.

So that's a significant learning curve working with new function in new implementation.   To the extent that adding something new is just "add a boost property" and/or "add a dependency", it could make things easier.   

---

Now, we can fast-forward to the case where the simplified Boost configuration layer isn't enough for a given function + implementation.     Boost isn't going to immediately, magically add configuration for every property in every implementation in the foreseeable future.

So should Boost be architected to seamlessly allow you to also use the "native" impl-specific plugin in the same project?   Or do we shoot to cover 80% of cases (or maybe "all" the starter-generated projects) with Boost and recognize that there are going to be special cases where Boost isn't a good fit and deal with that somehow?    

That'd be a good question.   It's something we need to discuss but we wanted to start by trying to put something out there to make development easier for new users, even without having settled all that at this point.

Scott

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/96b745fb-3068-4739-a933-e58b3ae8938e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/wKnUcj23URo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe78nkOrhBs4--%2B%2BZG75JoYxQ6sGpJn1DWqTbtxNATjGtQ%40mail.gmail.com.

[Erik Mattheis]

On Friday, May 17, 2019 at 11:46:15 AM UTC-4, Emily Jiang wrote:

One of MicroProfile missions is to support portability and interoperability. With the common plugin, it is much easier to move among app servers.

Personally, as a developer, the portability and interoperability I expect from MP ends with my application code and its dependencies. When I make the choice of where to run my service, I expect to wire it into that ecosystem and I expect to change that wiring from time to time. I do not want magic in my build system that does that for me.

On of the tenets of Java EE is the separation of roles - e.g. product provider, component developer, application assembler, etc. - and a clear definition of responsibilities for those roles. With DevOps being all the rage these days, we tend to seek tools that make specialized tasks easier, but we shouldn't overlook the fact that these responsibilities are still specialized. In any reasonable production environment for a MP application, it will be someone's responsibility to pick a platform and decide how to configure it. At that point, having an abstract tool is somewhat silly as it will almost certainly include trade offs that make access to the actual system.

In short, I think the boost plugin idea is interesting from a "getting started" perspective, but I think it ends up being a difficult thing to keep relevant in the long run and make the MP concept more opinionated than it should be. I think the reason developers seek abstractions like MP is because they want to see differentiation and competition among implementations. If we try to fit all implementations into the same mold for the sake of packaging deployments we're going to end up glossing over the potentially useful unique features each platform has to offer.

Perhaps a middle ground here is to standardize some goals and properties that all MP implementations should include in their plugins. I could certainly get behind the idea that certain configuration is universal and there should always be a target that produces a runnable JAR file. In that way it would be possible for simple applications to migrate between implementations by simply changing some plugin coordinates in the POM. It would also make it possible to build profiles that target implementations in a single pom. Having a unified plugin that knows how to do packaging for well-known implementations just seems untenable in the long run for all the reasons this never worked in the Java EE world.

On a somewhat related note, has there been any research done around MP adoption and desired features? This particular issue feels like a solution in search of a problem to me, but I don't know if I'm in the minority among MP users. As the platform becomes more complex it would be great to know what the larger community is actually looking for MP to provide.

-- 

Erik

[Ondro Mihályi]

Hi,

Reading whole this thread, I'm sorry to see so much time wasted with this discussion. I recommend that IBM just start their own separate project with Boost and invite everybody to join or add runtime-specific extensions. In a similar way how Red Hat created SmallRye and invited everybody to participate. I think that Boost is an extension to MicroProfile, can have its own project and shouldn't be discussed within the MicroProfile community.

I'd say that everybody now has a good understand what the plugin does and what are its benefits. Just do it and launch the project on github :)

Ondro

[Emily Jiang]

Well explained, Ondro! We discussed this with Rudy on Monday this week. I think all set. Sorry we should have put a response here. 

Currently Karm is working to expose an endpoint for IntelliJIDEA to call. This will require internet connection. The next phase is to support offline mode by directly calling APIs. 

We are after anyone who has written IntelliJIDEA extension to help. Please shout if you can help.

Thanks 

Emily 

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/wKnUcj23URo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/50c50b77-6213-4dc3-9a98-f1de4a6171b8%40googlegroups.com.

[Ken Finnigan]

Emily,

I don't understand your response. You're talking about Intellij extensions. 

Ondro was talking about the Boost plugin

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1468599a-a363-4766-8df5-af7cb94bb443%40Emilys-iPhone.

[Emily Jiang]

oops. That was intended for this thread. sorry. I'll port there.

Thanks

Emily

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/50c50b77-6213-4dc3-9a98-f1de4a6171b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.