Using dynamic properties in POM.XML
Hi,
I'm using Maven to help manage a automated testing project for integrated
system-level testing, not unit testing. The project holds the test code, but
the device under test is something completely separate. The first test grabs
the installer (located externally) and installs the product under test on a
remote machine, and then the test code in the Maven project runs remote
tests against that deployed product. Works great.
When it's complete, it generates a test report, via the usage of
surefire-testNG, and a customized report listener, reportNG. From the POM
file, re: reportNG:
...
org.uncommons.reportng.titleAutomation Test
Report/org.uncommons.reportng.title
This ends up generating a wonderful test report.
I'd like this title to include the build number of the product under test.
This is different (and not directly tied to) the version of the Maven
project, which is the test code. I'd love to be able to do something like
this...
org.uncommons.reportng.titleAutomation Test Report: Product X
${externalProduct.buildNumber}/org.uncommons.reportng.title
... if ${project.build.directory} was a global variable that I could set
DURING my testing before testing was complete (but after testing had begun),
and then by the time Maven got to generating the report, it would use the
value of that global variable, which I had set during the beginning of my
testing (part of my testing dynamically figures out what the most recent
version is for the device-under-test --- in other words, I don't know what
that is until run-time.
Is there any way to get this to work?
Thanks in advance!
--
View this message in context:
http://maven.40175.n5.nabble.com/Using-dynamic-properties-in-POM-XML-tp5745373.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
integration-test, testNG, and a CI server
Hi, I have a maven project (Project 1) which is intended for executing integration tests. Inside this project is an additional class that helps me automate the deployment of various jars to a nexus repo. Project 1 is dependent on those jars (SNAPSHOT). Project 2 is dependent on those jars (SNAPSHOT). Project 1 is also dependent on project 2. (SNAPSHOT). STEP 1: My CI server (TeamCity) runs a daily build config called Deploy Jars @ 4:00 AM on Project 1, with Maven phase: pre-integration-test. pre-integration-test runs a testNG suite that has the class for deploying those jars to the repo. Works fine. Only that class runs. STEP 2: Next, my CI server has a build trigger for project 2 (to compile and deploy) to occur anytime Deploy Jars is successfully built. This works -- project 2 is built (and project 2 updated its SNAPSHOT dependencies on those Jars that were sent to the repo in step 1). Project 2 is compiled and it's .jar deployed to the repo as well. STEP 3: Back to Project 1. Now that all the .jars have been uploaded to the repo (various jars, including the .jar for project 2, as described in step 2), A Maven build is run with phase integration-test. THE PROBLEM: Unfortunately when I do STEP 3, Maven ends up also RE-RUNNING pre-integration test prior to integration-test, which basically reruns the actions that already occurred in STEP 1. (i.e. all those jars are sent to the repo again). That probably makes sense, in that Maven is probably hardwired to run pre-integration-test any time I ask it to run integration-test. I'd like to find a way out of this -- any suggestions? Is there another maven phase I can take advantage of here, to accomplish my objective? Basically, I don't want step 3 (integration-test) to re-copy those jars to the repo, it's a waste of time, etc. Thanks in advance! Bonus question -- am I getting 'phase' and 'goal' mixed up? My POM file says that pre-integration-test and integration-test are phases. They both have a goal of test. But in my CI server, I have pre-integration-test and integration-test listed as GOALS the maven build configuration on the CI server, and that seems to be working (for the most part). In other words the build configuration for STEP 1 only lists pre-integration-test for a goal, and that works, but the POM file only lists pre-integration-test as a phase... -- View this message in context: http://maven.40175.n5.nabble.com/integration-test-testNG-and-a-CI-server-tp5726939.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
Baptiste MATHUS wrote +1. There's many possibilities to do that. But are you aware that mvn deploy is already going to timestamp SNAPSHOTs? Isn't that sufficient? Just found that out yesterday, and am using it, awesome! My project is dependent on another maven project that I have control over, as well as 4-5 internally built jars that I don't have control over. All of these dependencies might change daily and I'd like them in the repo as snapshots. Let's call my project project 1 and the project it's dependent on, project 2. For project 2, I have control over building it, and so I have configured the nexus repo info in the POM file for that project. On my CI server, I build that project first, and I have the maven goal deploy defined, and it is properly deploying the snapshot (with timestamp) to the nexus repo. And when Project 1 builds later with the -U parameter, it is always downloading the most recent snapshot of Project 2 from the repo. Cool! My problem lies with the 4-5 jars (that are built nightly) that Project 1 is dependent on, that are NOT built by maven projects. Specifically, all I have a mounted drive to a network share and know that the (new) .jars will be there, but that's about it. I'd like to automate the process of getting those to the repo (as an updated SNAPSHOT version) immediately prior to my project building, so that I'll pull down the latest version. But unless I'm missing something, I don't see any easy way to use maven plugins to deploy those files, since they're not artifacts of a project I'm building. What is the easiest way to do that? I suppose I could write a script that runs some kind of nexus-related command line or maven command line that will somehow deploy these 4-5 files as -SNAPSHOT to the repo. But how? I think some of my confusion is probably due to never using maven at the command line. I use it via m2e, or the CI server has been invoking it for me. If there is a way to get an external file into a repo via a command line, I'm not sure how to do it. :) -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723813.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
Manfred Moser wrote Write a script that invokes the the mvn deploy plugin with the deploy goal and invoke that as separate freestyle build step before your other build e.g. mvn deploy:deploy-file -D ... More info on parameters and stuff at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html manfred Done! Was easier than I thought. I've stored the logic in a java class within project 1. On the CI server, I'll have a separate maven build step that only runs that one class as a testNG test, which will get those 4-5 jars to the repo. Then, my next maven build step in the same project (but with a -U) should enforce that it rebuilds with those guaranteed-to-be-new internal jars. Thanks for the help, all! -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723825.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
Let's say I wanted to automate the process of promoting daily snapshots to the nexus repository, and then configuring the project to always utilize the latest version in the repo. Is there a way to automate incrementing the version number and deploy to nexus? Specifically: I've used the nexus GUI before to manually upload an artifact, but that's it. If I knew the locations of the artifacts built that I need to get to the repo (and that's all I would have -- no POM file, etc), does anyone have a script I could take a look at that would accomplish deploying these to a nexus repo in such a way that projects will always download the latest version? -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723629.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
strategy for incorporating private jars into a project
Hi, My java project has several dependencies, both external (i.e. in the public repo) and private (built by our own company). It's a QA project, that can be run locally in Eclipse, and also runs on a CI server (teamcity). When it 'builds', it runs then maven phase: integration-test, which then runs testNG tests within my classes. So far so good. Unfortunately the private jars that it uses are not under any sort of control. They are built by a different team in my company, and are placed in an available network-share, but that's it. They don't seem to be properly 'versioned', and are not placed in any local (nexus) repository, unless I manually put them there. For running nightly automated testing, I want to ensure I always utilize the most recent version of those private jars. So far, I've manually placed a version of them in a local nexus repo, and they are successfully pulled down when teamcity runs the build. But I don't have a way of getting the nightly builds up inside that nexus repo. Even if I did, they would always just be version 1.0 and probably won't be re-downloaded anyway. So... I'm looking for suggestions re: a strategy on how to *ensure* that each time my project is built, that it properly grabs the new version of those private jars, of which the only reliable way to access them is in a network share drive. The other public jars are successfully managed by maven. Is there a way to use Maven to help me pull in these private jars that exist on a network share? If anyone has any suggestions on a strategy re: how I can proceed, I'd appreciate it! Thanks! -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
The suggestion (automatically upload to local repo) sounds like a good one, though I thought of a different solution that I'd like your opinion on: This project is used for running integration-level regression tests. The project is checked into source control (SVN). Conceivably, I may have a need to run the project tomorrow against an older version of code. If I were to do this, I'd want to run with the same version of the internal jars that I had used at that date. If I were to tell SVN to load the project as of date/label x (might be a release from 6 months ago..) -- and then run the project, I wouldn't want to take the latest version of those internal jars, I'd want to use the version that I used back at that date. To that end, I was thinking of creating a subdirectory within the project inside SVN reserved for holding those internal jars. This way, whenever I revert the project back to SVN version x, I'll be assured I'm using those same version of those same internal jars that I had originally used on that date/label. To ensure I'm using the latest version (when I'm trying to run 'latest'), I could write a script to auto-commit those jars to the subdirectory of my project within SVN, overwriting the previous version. In reality it seems very similar to the suggestion you had, but it's utilizing SVN to house those artifacts instead of the local nexus repo. What are your thoughts on this? If I were to do this, what would the proper configuration be for Maven, i.e. to treat this special subdirectory as a location for retrieving artifacts, and to ensure that it's not cached, so that when I build, it will always use the version in that directory? Thanks for your help. I'm fairly new at this and appreciate the guidance. -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
