Ron Wheeler wrote > What is the underlying problem for which a solution is sought? > > Why are the jars so volatile? > Why is it so important to use the "latest" version and then track the > history so carefully? > Describe the "release" cycle of the final product. > > It sounds like this problem needs to be restated in higher level terms > in order to get a reasonable solution.
Great question and thanks for asking. OK, let me describe in more detail: There are two software projects in play here. One is mine (QA), we'll call that project "TESTER". The other is built by our sw-dev team, we'll call that "SERVER". Sequence of events: 1) "SERVER" is built nightly by sw-dev, with no advanced build tools or artifact mgmt, etc. The net result is that the build server has a new directory with: The installer for "SERVER", and a few .jar files. 2) "TESTER" is intended to build on a CI server (teamcity), which essentially ends up being a regression testing harness. It builds my java project "TESTER", which is made up of testNG tests. 3) The first test "TESTER" runs, is to take the installer for "SERVER", and run it on a remote machine. 4) All subsequent tests run on "TESTER" end up running tests across the network (webservices, etc), against the now remotely-installed-and-running "SERVER". "SERVER" has a client UI, a java applet. I don't want to automate testing at the client UI level for a number of reasons, I want to automate testing just under the client UI. This way, the tests will exercise as much of the real code path as possible (i.e. 1/2 the client code, and then that code will communicate with the server across the network, etc.). Here's the issue: some of the libraries that "TESTER" uses, are some of the libraries built in the nightly build (i.e. they would be some of the libraries used by the client app). If I run tests on deployed server build 123, but I'm still using some of the client libraries that were built in build 122, I might miss a bug they've introduced in build 123, etc. Tests might pass that should fail, or fail that should pass, etc. So... when I build "TESTER", I want to ensure that it's using the 3-4 jars that were specifically built for the same version of the server I've just installed. The problem is that the sw-dev build team doesn't manage these artifacts, etc. I have access to them in a reliable network share, but that's about it. Hopefully that describes the problem a little better. Thanks in advance! -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722736.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
