Should all services run on all vendor platforms

[Iain Duncan]

Hi,

I was testing to make sure all the services could still run on Liberty earlier and accidentally created a PR into the main repo.

I'd done a previous test on Liberty about a month ago and had at that time expected all services to run on all vendors platforms so that they could use the application as a sample to show MP on their own stack.  However, when I came to merge this into the repo we decided that it should be one vendor per service as discussed here:

https://github.com/microprofile/microprofile-conference/pull/43

I thought I'd create a discussion here as suggested by Martijn on the latest PR:

https://github.com/microprofile/microprofile-conference/pull/98

As he had also thought that it was ok to run all services on all vendors platforms.

What is the general consensus, should we be able to demonstrate all the services running locally on a single vendor platform?

Two other points, I definitely agree that the default should be to run each service on the different platforms.  I believe tomee is already setup to run all the WARs on tomee in the config in the web-application pom's but I may be mis-interpreting this:

<plugin>
    <groupId>org.apache.tomee.maven</groupId>
    <artifactId>tomee-maven-plugin</artifactId>
    <configuration>
        <tomeeVersion>${version.tomee}</tomeeVersion>
        <tomeeClassifier>webprofile</tomeeClassifier>
        <!--@formatter:off-->
        <webapps>
            <webapp>${project.groupId}:microservice-speaker-web:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-session:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-schedule:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-vote:${project.version}</webapp>
        </webapps>
        <!--@formatter:on-->
    </configuration>
</plugin>

Cheers,

Iain

[Ken Finnigan]

On Friday, November 4, 2016 at 7:53:25 AM UTC-4, Iain Duncan wrote:

Hi,

I was testing to make sure all the services could still run on Liberty earlier and accidentally created a PR into the main repo.

I'd done a previous test on Liberty about a month ago and had at that time expected all services to run on all vendors platforms so that they could use the application as a sample to show MP on their own stack.  However, when I came to merge this into the repo we decided that it should be one vendor per service as discussed here:

https://github.com/microprofile/microprofile-conference/pull/43

I thought I'd create a discussion here as suggested by Martijn on the latest PR:

https://github.com/microprofile/microprofile-conference/pull/98

As he had also thought that it was ok to run all services on all vendors platforms.

What is the general consensus, should we be able to demonstrate all the services running locally on a single vendor platform?

My understanding was that the microservice-sample repository was canonical examples that could be executed on any implementation via profiles,

but that the conference demo was to showcase interoperability between implementations.

Two other points, I definitely agree that the default should be to run each service on the different platforms.  I believe tomee is already setup to run all the WARs on tomee in the config in the web-application pom's but I may be mis-interpreting this:

<plugin>
    <groupId>org.apache.tomee.maven</groupId>
    <artifactId>tomee-maven-plugin</artifactId>
    <configuration>
        <tomeeVersion>${version.tomee}</tomeeVersion>
        <tomeeClassifier>webprofile</tomeeClassifier>
        <!--@formatter:off-->
        <webapps>
            <webapp>${project.groupId}:microservice-speaker-web:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-session:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-schedule:${project.version}</webapp>
            <webapp>${project.groupId}:microservice-vote:${project.version}</webapp>
        </webapps>
        <!--@formatter:on-->
    </configuration>
</plugin>

Andy originally created the ability to run all services in TomEE as WARs to facilitate faster development of the UI.

I'm ok with that approach for development, but maybe it shouldn't be the default?

Ken

 

Cheers,

Iain

[Emily Jiang]

I think interop is one spec to showcase. Making all microservices running on each vendor can show case the portability. I think we should do what Iain suggested as well. Perhaps, we can configure it somehow so that we can easily switch vendors. My 2 cents.

Thanks
Emily

[agumb...@tomitribe.com]

Short answer, yes, all services on all vendors.  The web app is currently configured to run on TomEE, but that was just while I was initially hacking on the UI. Goal there is to profile the build for all vendors. It'd be great to do something like mvn - Ptomee ,  mvn -Pwildfly ,  etc. and see the vendor fire up everything in their containers.  I'm sure we'll nail it down during devoxxbe this week. 

Andy. 

agumb...@tomitribe.com

http://www.tomitribe.com

Sent from my mobile device.

--
You received this message because you are subscribed to the Google Groups "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/1c6f887b-b599-4bed-b9d6-ef12d24632ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Heiko Rupp]

+1 for "on all vendors".

Java EE in the past only met this half-heartedly with all those proprietary descriptors, that made it a pain porting an application. The more we "unify" the better for the Mircoprofile-effort at all.

[Martijn Verburg]

Hi all,

I've been battling away with the quick start and a bunch of the individual services.  I've put up 2-3 issues on Github that the existing vendor/service owners might want to take a look at.

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@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/8f800dd9-d646-48c0-84bd-43f29260eec8%40googlegroups.com.

[Ken Finnigan]

I guess it depends on the "goals" of the conference demo.

Is it to showcase interoperability and portability? Or is it focused on interoperability with a view to advancing areas of the MicroProfile that need work and investigation?

I fear that pushing for this demo to support portability will result in a morass of custom implementation configuration files that are selectively included/excluded from a build depending on which Maven profile might be active on that run.

Such a situation makes it very hard for anyone to quickly grasp what each service requires in terms of implementation specific settings.

I always felt that this demo was better suited to a single service per implementation to show the interoperability, coordination, and cooperation between all the implementations,

both at a technical and personal level.

Granted right now there are a couple of implementations that don't have a service, but if we revisit the architecture and maybe expand the scope we should be able to resolve that.

I'll finish by saying, not everything MicroProfile produces as an example or demo needs to have every service run on every implementation.

Ken

[Emily Jiang]

We are only creating one demo application. It will be brilliant if we can showcase both interoperability and portability. Both of these features are important to the community. By the way, all microservices can be configured on WebSphere Liberty (see readme https://github.com/microprofile/microprofile-conference) . Besides, in this way, we can make sure the MicroProfile implementations not diverge too much in the future.

Emily

[John Clingan]

The consensus occurred a while back (although opinions can change). We want to show both Interop and portability. Since we don't have the equivalent of a TCK, the idea is for the conference app to fulfill that role for now. The implication means every service must run on every implementation. The only reason we started with one service per MicroProfile runtime was out of necessity to try and a reach JavaOne deadline, so each vendor (or community member) picked a service to implement on a runtime.

[Mark Little]

+1

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

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@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/dcf23c78-c916-44ac-ad9a-5e9ca576909f%40googlegroups.com.

[Werner Keil]

+1

Would be great to have a Hudson or Jenkins instance showing the successful deployment of such portability test app to all relevant containers.

[Alasdair Nottingham]

I think right now getting PRs built prior to acceptance would be good. Several breaks in run up to Devoxx talk due to everyone rushing to finish. 

Alasdair Nottingham

On Nov 11, 2016, at 10:51 AM, Werner Keil <werne...@gmail.com> wrote:

+1

Would be great to have a Hudson or Jenkins instance showing the successful deployment of such portability test app to all relevant containers.

--
You received this message because you are subscribed to the Google Groups "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/138804bb-788f-46fe-b3b1-6df89a297a19%40googlegroups.com.

[Katherine Stanley2]

+1

Kind regards,

Katherine (Kate) Stanley

Software Engineer - WebSphere Liberty

Phone: 44-1962-816474

E-mail: kath...@uk.ibm.com

Twitter: @KateStanley91

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ED7B12E7-84FD-420C-97CD-E66B7FF3ABA9%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[John Clingan]

This has been discussed, with the idea being a continually running live demo across multiple vendors, and we actually do CD to update the live demo with new features. We just need to "get it done". Unclear if the Eclipse Foundation has the (runtime) resources to do this or if we have to host it ourselves. We'll get there.

[Ondrej Mihályi]

It would be great to have each service of the conference app deployable to any implementation. However, I believe the foremost goal of the conference repo is to provide an example how to use MicroProfile implementations together and a vision what can be MicroProfile useful for. 

As a TCK, I think it is better to grow the set of example apps, which are in https://github.com/microprofile/microprofile-samples repo. Each app in the repo includes a set of tests and a maven profile for each implementation, including Hammock. It is also good to demonstrate how to build an app on top of the core MicroProfile API - For example, the Swagger app does that for Swagger. It is necessary to show people how to integrate other tools/libs with MicroProfile because mP is far from providing a complete stack at current stage. Otherwise they would think mP is just a toy.

If I'm wrong, please clarify and remind me again what are the main purposes of the conference and samples repos.

--Ondrej

Dňa piatok, 11. novembra 2016 16:30:31 UTC+1 John Clingan napísal(-a):

[Ken Finnigan]

Ondrej,

That was also my thoughts on the purpose of the conference app, not as a TCK but more a showcase and interoperability example.

Making it TCK like with all services able to run on all implementations, especially as we add more services/implementations, makes the setup more confusing and prone to errors in my view.

Ken

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@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/dcd43247-dcb4-462f-aec1-873ef197cd0e%40googlegroups.com.

[John D. Ament]

It also assumes that each runtime has a common way to deploy applications.  Right now, not even that is consistent.

John

[Martijn Verburg]

Hi all,

Coming late to this conversation, but is Travis on GitHub not a sufficient place to start this work (even before/if we go to Eclipse)?

Please excuse my ignorance of the nitty gritty tech details :-).

Cheers,
Martijn

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1aae753c-716f-4b36-ab0e-48d787cf2461%40googlegroups.com.

[Kevin Sutter]

Hi,
It might be nice if we could have a single app/sample that could provide both interop and portability testing, but I'm starting to agree with Ken and others that this could get messy and complicated.  We will want something to easily demonstrate the capabilities of MicroProfile.  And, then we'll need another set of samples/tests that can be used to verify that a given implementation can satisfy all of the goals of MicroProfile (ala TCK).  Based on my past experiences with TCKs and the CTS buckets, this latter piece of work can involve considerable configuration and setup to get the expected results.

So, my vote is to have a separate "conference app" that can demonstrate interop and other key capabilities.  And, then also provide a "samples" repo that has a wider gamut of tests.  Interop may very well be part of this, but it's much more.

Kevin

On Friday, November 11, 2016 at 1:52:27 PM UTC-6, Ken Finnigan wrote:

Ondrej,

That was also my thoughts on the purpose of the conference app, not as a TCK but more a showcase and interoperability example.

Making it TCK like with all services able to run on all implementations, especially as we add more services/implementations, makes the setup more confusing and prone to errors in my view.

Ken

On Fri, Nov 11, 2016 at 2:45 PM, Ondrej Mihályi <ondrej....@gmail.com> wrote:

It would be great to have each service of the conference app deployable to any implementation. However, I believe the foremost goal of the conference repo is to provide an example how to use MicroProfile implementations together and a vision what can be MicroProfile useful for. 

As a TCK, I think it is better to grow the set of example apps, which are in https://github.com/microprofile/microprofile-samples repo. Each app in the repo includes a set of tests and a maven profile for each implementation, including Hammock. It is also good to demonstrate how to build an app on top of the core MicroProfile API - For example, the Swagger app does that for Swagger. It is necessary to show people how to integrate other tools/libs with MicroProfile because mP is far from providing a complete stack at current stage. Otherwise they would think mP is just a toy.

If I'm wrong, please clarify and remind me again what are the main purposes of the conference and samples repos.

--Ondrej

Dňa piatok, 11. novembra 2016 16:30:31 UTC+1 John Clingan napísal(-a):

This has been discussed, with the idea being a continually running live demo across multiple vendors, and we actually do CD to update the live demo with new features. We just need to "get it done". Unclear if the Eclipse Foundation has the (runtime) resources to do this or if we have to host it ourselves. We'll get there.

On Friday, November 11, 2016 at 1:51:45 AM UTC-8, Werner Keil wrote:

+1

Would be great to have a Hudson or Jenkins instance showing the successful deployment of such portability test app to all relevant containers.

--
You received this message because you are subscribed to the Google Groups "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.

[Erin Schnabel]

I would like to suggest: all the services in the conference app should run on all of the vendors. 

Let's see how messy it is rather than speculating ahead of time. I believe we can all learn something about how we all do things a little differently, and I think that will do us all good in the long run. What may have been true in the past is not true anymore: everything is lighter weight than it was. If things get too FAT, then perhaps we will each be motivated to improve and make things simpler (which, again, benefits everyone).

[Mike Croft]

+1 Erin.

David made the point at Devoxx that this whole process has given/is giving us a taste of users' pain points. If it's an overly difficult process, then it seems like that's a good pointer to an area we should be focusing on making better.

It's pretty unlikely that any particular user would be deploying more than 1 microprofile implementation, but they would need to solve very similar problems to those faced by the conference app in terms of interoperability.

[Emily Jiang]

+1 on showcasing interoperability and portability. Creating another sample app and maintaining it probably is more daunting than having one demonstrating two aspects.  I think most people voted for this anyway.

[John Clingan]

The long-term goal isn’t for the conference app to be a TCK, it is intended a temporary measure to prove that we all comply with MicroProfile (a mini-TCK). We’ll have to figure out the long-term strategy on what it means to be MicroProfile compatible, or even if that is even a long-term goal.

[Alasdair Nottingham]

Last week at Devoxx it was observed that the pom.xml files for each service look long and complicated, and most of that is because they have information in to enable them to run on multipel runtimes. I agree with the principle here, but it would be good if we can find a way to address the requirements without making hte pom files overly complicated.

Alasdair

-- 
You received this message because you are subscribed to the Google Groups "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/4C22D45B-5220-442C-B66A-F602F7A057A7%40redhat.com.

[Andy Gumbrecht]

I've seen profiles being set up in the pom files to run services on other vendors.
This wasn't the intent of this thread I think?

Each vendor has basically sponsored a service. The corresponding pom should only contain each vendors maven build for their service. If we start adding profiles to each pom for each vendor we'll end up with a bit of a mess I think. It'll be really hard for the community users to see what is what.

The idea was to add just a profile to the local startup.

Currently, there is a local startup option -

mvn clean package tomee:run -pl :web-application -DskipTests

This deploys and runs all services in a single TomEE instance. It's been used to develop the UI so far, rather than firing up the services individually.

So, I think it is this process that needed addressing. Each vendor should have this option (not just TomEE).

mvn clean package -P[vendor] -pl :web-application -DskipTests <-- This is the intended goal.

The gulpfile.js would need some tailoring, and the web-application pom needs the profiles defining.

Andy.

[Ken Finnigan]

On Mon, Nov 14, 2016 at 2:22 PM, Andy Gumbrecht <agumb...@tomitribe.com> wrote:

I've seen profiles being set up in the pom files to run services on other vendors.
This wasn't the intent of this thread I think?

Each vendor has basically sponsored a service. The corresponding pom should only contain each vendors maven build for their service. If we start adding profiles to each pom for each vendor we'll end up with a bit of a mess I think. It'll be really hard for the community users to see what is what.

I agree, as I've already stated, that having every service buildable by every implementation (especially if we reach 5+ implementations) becomes unwieldy and difficult to maintain.

 

The idea was to add just a profile to the local startup.

Currently, there is a local startup option -

mvn clean package tomee:run -pl :web-application -DskipTests

This deploys and runs all services in a single TomEE instance. It's been used to develop the UI so far, rather than firing up the services individually.

So, I think it is this process that needed addressing. Each vendor should have this option (not just TomEE).

mvn clean package -P[vendor] -pl :web-application -DskipTests <-- This is the intended goal.

I like the idea, but in practice it requires a common build process for all implementations.

It may be that a common build process might be a long term goal, but i'm not sure on that right now.

It also means an implementation is unable to provide custom configuration for every service without "cracking open" the Uber jar, assuming a single build, to add things into it.

Given how each implementation handles a "build" slightly differently, I don't think there's any way to provide vendor specific solutions to running the web application unless we dictate that all services are just WARs and that any implementation must be able to have a WAR deployed to it. But that would completely negate Uber jars and be no different to us deploying everything to WildFly, WebSphere, Weblogic, etc.

We already have the microprofile-samples repo, I would be in favor of making that the place to handle portability testing of MicroProfile functionality.

Ken

The gulpfile.js would need some tailoring, and the web-application pom needs the profiles defining.

Andy.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@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/a5a010e0-6cf8-4ddb-ba86-c0d51aac6493%40googlegroups.com.

[Ondrej Mihályi]

If we want to have any application to be used with more than one mP impl., we should agree on the proper way to do this - and having multiple profiles in one pom is in my opinion unwieldy.

It is true that there is no common way of packaging, but we should be able to separate the code from the build process by extracting the code into a JAR project, which would be used as a dependency for in an impl-specific project, with an impl-specific project for every impl.

As an example, for the schedule service, we could have these maven modules instead of just one WAR module right now:

 - Schedule JAR module with the app that creates schedule.jar (with the app source code, dependent only on the 3 mP API + any 3rd party libs if needed)

 - Schedule-{impl} WAR module for every WAR-based impl that would depend on the Schedule JAR module ({impl} being WFSwarm, Liberty, TomEE, Payara)

 - Schedule-{impl} JAR module for every JAR-based impl that would depend on the Schedule JAR module ({impl} being Hammock so far)

Provided that this is possible with every impl (I believe it is), this would make it possible to keep the main app pom file clean and separate build process for every impl. It also makes it easy adding support for additional impl without interfering with other impls config.

If we want to use the conference services as reference apps (runnable on any impl) and a kind of TCK, we should definitely separate source code from the build process. And even if not, this could be very useful for the microprofile-samples repo, if samples in that repo will be considered as a TCK.

With the conference app, if we also add a common "start" profile into all impl-specific modules to eecute the service, we can easily add various impl combinations for running the app in the current "start" module, just by defining various profiles, which specify the correct modules:

 - e.g. running mvn -Pstart,reference package in the current "start" maven module would run all services and web app according to the "reference" profile

<profile>
    <id>reference</id>

<!-- runs every service on a different impl -->
    <modules>
      <module>../microservice-speaker/speaker-tomee</module>
      <module>../microservice-session/session-wfswarm</module>
      <module>../microservice-schedule/schedule-payara</module>
      <module>../microservice-vote/vote-liberty</module>
      <module>../web-application</module>

    </modules>

</profile>

<profile>
    <id>tomee-separate</id>

<!-- runs every service on tomee, each service in separate process -->
    <modules>
      <module>../microservice-speaker/speaker-tomee</module>
      <module>../microservice-session/session-tomee</module>
      <module>../microservice-schedule/schedule-tomee</module>
      <module>../microservice-vote/vote-tomee</module>
      <module>../web-application</module>

    </modules>

</profile>

<profile>
    <id>tomee-single</id>

<!-- runs every service on a single tomee instance (for development) -->
    <modules>
      <module>tomee/tomee-single</module>
      <module>../web-application</module>

    </modules>

</profile>

--Ondrej

Dňa pondelok, 14. novembra 2016 20:45:24 UTC+1 Ken Finnigan napísal(-a):

On Mon, Nov 14, 2016 at 2:22 PM, Andy Gumbrecht <agumb...@tomitribe.com> wrote:

I've seen profiles being set up in the pom files to run services on other vendors.
This wasn't the intent of this thread I think?

Each vendor has basically sponsored a service. The corresponding pom should only contain each vendors maven build for their service. If we start adding profiles to each pom for each vendor we'll end up with a bit of a mess I think. It'll be really hard for the community users to see what is what.

I agree, as I've already stated, that having every service buildable by every implementation (especially if we reach 5+ implementations) becomes unwieldy and difficult to maintain.

 

The idea was to add just a profile to the local startup.

Currently, there is a local startup option -

mvn clean package tomee:run -pl :web-application -DskipTests

This deploys and runs all services in a single TomEE instance. It's been used to develop the UI so far, rather than firing up the services individually.

So, I think it is this process that needed addressing. Each vendor should have this option (not just TomEE).

mvn clean package -P[vendor] -pl :web-application -DskipTests <-- This is the intended goal.

I like the idea, but in practice it requires a common build process for all implementations.

It may be that a common build process might be a long term goal, but i'm not sure on that right now.

It also means an implementation is unable to provide custom configuration for every service without "cracking open" the Uber jar, assuming a single build, to add things into it.

Given how each implementation handles a "build" slightly differently, I don't think there's any way to provide vendor specific solutions to running the web application unless we dictate that all services are just WARs and that any implementation must be able to have a WAR deployed to it. But that would completely negate Uber jars and be no different to us deploying everything to WildFly, WebSphere, Weblogic, etc.

We already have the microprofile-samples repo, I would be in favor of making that the place to handle portability testing of MicroProfile functionality.

Ken

The gulpfile.js would need some tailoring, and the web-application pom needs the profiles defining.

Andy.

--
You received this message because you are subscribed to the Google Groups "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.

[John D. Ament]

Didn't we try that already at https://github.com/microprofile/microprofile-samples ?

On Monday, November 14, 2016 at 9:32:12 AM UTC-5, Kevin Sutter wrote:

[Ken Finnigan]

Ondrej,

I would agree that in principle what you're proposing should work, but I would contest whether it's a good idea to do so.

If we took such an approach we'd currently have (numServices * numImplementations) + numServices as a totality of Maven modules. Right now that would equate to (4 * 5) + 4 -> 24!

When we expand the demo, and also the number of implementation options, we're going to have anywhere up to 100 Maven modules for the demo! From my perspective that's excessive.

I firmly believe that trying to make the demo showcase interoperability AND portability will result in a maintenance burden and difficulty in users comprehending what's going on.

If we took this approach, there's no way for a user to "pluck" out a service from an implementor as a single Maven module to use as a basis for local testing or their own project. A single view of a service is spread across multiple Maven modules, increasing complexity and reducing understanding.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@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/d512f08f-f622-4d48-81f5-75b6f286f264%40googlegroups.com.

[Andy Gumbrecht]

The less clutter in the poms the better. I just don't want anyone thinking that TomEE is trying hog the show with that startup - Nearly done on a PR where we won't need it (ie. just using npm with a fallback json file). I'm pretty sure that none of us have a problem deploying the current war files from any vendor (as the TomEE startup currently proves).

Andy.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5BPG90qH5zgzj-LQMDSyd-_FKH1hdaBXDKO%3DEtnsUCGA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com