juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <james.bog...@salesforce.com>
Subject Re: Quick update on status of code.
Date Mon, 08 Aug 2016 19:52:36 GMT
Hi Peter,

Sounds good.  But note that we don't need to have the microservices
packaged as jars in order to execute them.  We can simply invoke the Java
main method.  Does that simplify things?

I assume the exec-maven-plugin will also allow you to shut down the
process.  If not, the microservice exposes a "shutdown" resource for
killing it via a REST call.

On Mon, Aug 8, 2016 at 3:44 PM, Peter Haumer <phaumer@us.ibm.com> wrote:

> Hello.
> My thinking was that we would use the Exec Maven Plugin to start the
> servers and then run the tests against them and shut them down afterwards:
> http://www.mojohaus.org/exec-maven-plugin/. There is also the process
> plugin that I saw mentioned in some Stackoverflow threads that I was
> planning to check out: https://github.com/bazaarvoice/maven-process-plugin
>
> To be able to run the servers as jar files there were problems with the
> way Maven is building and finding resource files and then resolving the
> classpath to load them over how you did it before. In Maven you place all
> files in the Resources folder hierarchy and Maven add them automatically to
> the jar. We would have to move all the resources that you currently store
> with the Java package directories over and update the various location
> where you load them; or we would have to write a custom pom that package
> the jar with the resource files where there are now. I was planning to move
> the files, which also improved maintainability of non-Java resource files
> imho. The other reason that drives decision making is about how to debug in
> the IDE. Once we move the files we should also use Maven to start the
> debugger; or you would have to maintain classpath information in Eclipse
> project properties and launches, which I assume John won't like ;-)
>
>
>
> Thanks and best regards,
> Peter Haumer.
>
> ______________________________________________________________
>
> PETER HAUMER, Dr. rer. nat.
> IBM zSystems Software
> ______________________________________________________________
>
> [image: Inactive hide details for James Bognar ---08/06/2016 12:05:10
> PM---Here's a quick update from the past week.... I cleaned up th]James
> Bognar ---08/06/2016 12:05:10 PM---Here's a quick update from the past
> week.... I cleaned up the Eclipse .settings folders and removed
>
> From: James Bognar <james.bognar@salesforce.com>
> To: dev@juneau.incubator.apache.org
> Date: 08/06/2016 12:05 PM
> Subject: Quick update on status of code.
> ------------------------------
>
>
>
> Here's a quick update from the past week....
>
> I cleaned up the Eclipse .settings folders and removed the PDE and WTP
> natures from all the projects.  The PDE nature was messing with the maven
> classpath and causing the server JUnits to fail with "signer information
> does not match signer information of other classes in the same package"
> errors. There were a couple of other errors I noticed when running under
> Java 8 that I also fixed. I'm now able to cleanly run all tests on Java 6,
> 7, and 8.
>
> One interesting note is that I'm seeing consistent timing differences when
> running the core JUnits under different versions of Java...
> Java 6 - ~8 seconds
> Java 7 - ~10 seconds
> Java 8 - ~4.5 seconds
>
> The HashMap optimizations in Java 8 help explain why that's so much faster
> since we use HashMap extensively throughout the code.  I don't know why
> Java 7 seems to be consistently slower than Java 6 though.
>
> Still missing is running the server JUnits as part of the Maven build.
> These are tricky and I don't know enough about Maven yet to know how to
> handle these.  The oaj.samples and oaj.server.test projects get executed as
> REST microservices on port 10000 and 10001 respectively (they get built as
> executable jars).  The JUnits in those projects run against those services
> using the RestClient API.  The old ANT script used to execute those jars
> and then run the JUnits.  We'll need to do something similar using Maven.
>
> Also, we were using Jacoco for test coverage reports in ANT.  If possible,
> I'd like to keep this capability.
>
> --
> James Bognar
>
>
>
>


-- 
James Bognar

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