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: Quick update on status of code.
Date Mon, 08 Aug 2016 20:51:09 GMT

I think it needs to be consistent for both cases as the classpath should be
defined by Maven for running it directly as a Maven command as well as
running it via a m2e Maven launch for debugging.  Maven will set the
classpath in both instances to the resource directory so that files can be
found there. When building a jar it will (afaik so far learning Maven) only
pick the files from the resource dir and ignore files in the packages dirs.
So if we want to support that customers can build and run microservices as
a jar, which was build by a pom then we should move the files around to
simplify the building process. Where I got stuck and ran out of time last
was loading the microservice settings file. If you could help moving that
file and updating the loader code for that that would be helpful. There are
various files that you know much better about when and how they are loaded
(e.g. icon files) where I would have to do a lot of debugging first.

Thanks and best regards,
Peter Haumer.


PETER HAUMER, Dr. rer. nat.
IBM zSystems Software

From:	James Bognar <james.bognar@salesforce.com>
To:	dev@juneau.incubator.apache.org
Date:	08/08/2016 12:52 PM
Subject:	Re: Quick update on status of code.

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
> 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:
> 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
> 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
> the files, which also improved maintainability of non-Java resource files
> imho. The other reason that drives decision making is about how to debug
> 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
> 7, and 8.
> One interesting note is that I'm seeing consistent timing differences
> 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
> 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
> REST microservices on port 10000 and 10001 respectively (they get built
> executable jars).  The JUnits in those projects run against those
> 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
> I'd like to keep this capability.
> --
> James Bognar

James Bognar

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