juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Haumer" <phau...@us.ibm.com>
Subject Re: Microservice packaging.
Date Fri, 30 Jun 2017 19:11:19 GMT

Hello.
I was on vacation and could not work on it before I left. What is the
conclusion then? (there were many emails afterwards, so I might have missed
it)

I was not thinking of any "enforcement" either, but just the simplest way
to package it one way out of the box. In the end it is people's code, the
pom shows and kind of docs the dependencies, but they can package however
they want. However, as users most likely have Maven already to build Juneau
or load it as a dependency, using Maven to package it as a simple uber-jar
that can be started via command line for quick testing seems straight
forward and we would not have to maintain a much more complex ant file. The
other problem I want to solve is that the template is currently not
included in the distribution. The Javadoc mentions a dead download link.
So, I want to include it into the source and bin release zips, so that
people can use it as a starting point. Again, they do not have to use the
template, but it would really convenient if they use Maven.


Thanks and best regards,
Peter Haumer.
______________________________________________________________



From:	James Bognar <james.bognar@salesforce.com>
To:	dev@juneau.incubator.apache.org
Date:	06/14/2017 07:41 AM
Subject:	Re: Microservice packaging.



I agree.  We shouldn't enforce packaging.

Today, it has 1 packaging requirement:  That the config file be co-located
with the jar, or that the config file location be passed in as a parameter.


> The core libraries should just provide how to run
> an application, not its deployment methodology.  If we can just publish
the
> JAR and provide instructions on how to package it that would make more
> sense.

That's pretty much what the template project is.  The juneau-all jar
provides all the infrastructure.  The template project provides you with a
default POM and Hello World resource to make it easy to create your own
microservice.  The default POM in this project would define a target for
building your microservice as an uber-jar, but you can package it any way
you like.  We should probably provide instructions as packaging it as 1) an
uber-jar, 2) a war, 3) other?

I'm not familiar with Capsule....so maybe?  The RestMicroservice class is a
main class that can be invoked directly.  We do that in the unit tests.  It
just needs the config file location to be specified.


On Wed, Jun 14, 2017 at 10:22 AM, John D. Ament <johndament@apache.org>
wrote:

> I've always been of the mindset that microservices shouldn't enforce
> packaging requirements.  The core libraries should just provide how to
run
> an application, not its deployment methodology.  If we can just publish
the
> JAR and provide instructions on how to package it that would make more
> sense.
>
> E.g. can I use Juneau Microservices with Capsule?
>
> John
>
> On Wed, Jun 14, 2017 at 9:14 AM James Bognar <jamesbognar@apache.org>
> wrote:
>
> > Peter has expressed interest in updating the microservice-template
> project
> > to include changes to the POM to allow you to generate uber-jars using
> the
> > Maven Shade plugin for easy startup....
> >
> > java -jar juneau-microservice-template-1.0.0.jar microservice.cfg
> >
> > The current build.xml file used to be able to create uber-jars but is
> > out-of-date.  If you wanted to include 3rd-party libraries, you had to
> copy
> > them into your project lib directory and then they would be included in
> the
> > final jar.  I like this idea of a pure Maven-based solution for
> uber-jars.
> >
>



--
James Bognar



Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message