Peter Johnson

I'm trying to handle any exceptions thrown by the code, in which case a different object is returned (this object is used specifically to wrap the error message). So all of my methods can return either the requested object or the error object. I don't want the stack trace or other exception paraphernalia being returned for an error. And to manage that without having error handling boilerplate code present for every request (I inherited a project that did that, what a mess), I have a centralized method that all request go through. But your code has given me an idea, let me see if that works.

@Stephan, I know that, and when I have a collection embedded within another class, I used that annotation there. But here, I am asking about the XML being returned when I do a "GET /students" call and the server code, to return the collection of students, does this:

@GET @PATH("/students") public Response list() {  List<StudentInfo> list = --- code that builds the collection ---  return new GenericEntity<List<StudentInfo>>(list) {} }

The XmlElementWrapper is not a valid class annotation (though that would have been a simple solution).

I'm using Jersey 2. I have a class such as:

@XmlRootElement(name = "student") public class StudentInfo {

When I GET a single student, the XML returned by Jersey looks like:

<student>  . . . </student>

But when I get a collection of student, the XML returned by Jersey looks like:

<StudentInfoes>  <student>    . . .  </student>  <student>    . . .  </student>  . . . </StudentInfoes>

How would I go about convincing Jersey (or JAXB) to instead return (i.e., how to rename the base collection tag):

<students>  <student>    . . .  </student>  <student>    . . .  </student>  . . . </students>

junitparams looks interesting, now if I could only place the @Parameters annotation of the @BeforeClass or @Before method, and that in turn would cause all the test cases to be rerun, that would be ideal. But I can't see annotating over a hundred test cases with the exact same @Parameters annotation, that would again be a maintenance headache if another configuration gets added.

Spock, on the use hand, would require some more investigation because I din't see anything obvious that would would do what I need.

But thanks for the suggestions, it's appreciated!

I have a situation where I would like to repeat a set of tests but with a different configuration. For example, assume a test class with 4 test cases, and where I have three different possible configurations (all valid at the same time). What I would like to do is run the test class three times, once with each configuration and have the junit test report show a total of 12 test cases being run.

I've looked at using TestSuite and the JUnit4TestAdapter class to define the tests to run, and using a for loop to run the tests multiple times changing the configuration between runs. And that works fairly well, but reporting is lacking (shows up as only a single test in the report). I have also looked into using the @Suite.SuiteClasses annotation, but that allows running the test cases only once; I guess I could declare 3 test suite classes with the @Suite.SuiteCLasses annotation and in each one set up the configuration but that isn't much better than the workaround I am using right now (more on the workaround later).

Of course, what I have given here is a simple example. I really have about a dozen classes with well over a hundred test cases that I need to run in 5 different configurations. To make things even more interesting, I have about another 50 test classes with perhaps 6-700 test cases that are configuration independent. My goal is, in a single integration test run, to run the configuration independent tests once and the configuration dependent test cases 5 time each, each time with a different configuration, and to end up with a single report showing the total number of individual test cases run (approx 1200 test cases total).

My current workaround is for the configuration dependent test classes, I have an abstract class with the test cases defined, then 5 subclasses each with only an @BeforeClass methods that sets the configuration. This works. But it is a miantenance headache if I have to add a new configuration (need to create a lot of new subclasses) and is also a pain when in a particular test environment only a subset of the configurations are available (right now I have the @BeforeClass methods checking if the configuration is present). I do have an API where I can determine the available configurations, so ideally I'd like to do a loop that runs the configuration specific tests once for each available configuration. And as I mentioned I can run the tests in a loop, but the final report doesn't include the individual tests. (If I knew how to grab the TestResult object being used by Maven to report on the tests, that would probably work for me as I could pass it off to TestSuite.run().)

Any ideas, thoughts or suggestions would be appreciated.

By the way, I'm using JUnit 4 and running the tests within Maven.

Try editing you settings.xml file and specifying a mirror. In my environment, all remote repository access goes through our Nexus server, and I use a mirror to redirect all calls to it. Example:

<mirrors>
<mirror>
<id>name-of-our-nexus-server</id>
<mirrorOf>*</mirrorOf>
<url>https://name-of-our-nexus-server/content/groups/public/</url>;
</mirror>
</mirrors>

See http://maven.apache.org/settings.html#Mirrors

If you right-clcikc the project and choose Team > Commit, what files are listyed as having been changed? It times, I have found that various Eclipse .settings or project are what are changed. This can happen if you don't store the Eclipse files in Subversion. If that is the case, you might want to configure subclipse to ignore such files.

The Maven command within Ant does not exactly match the Maven comment you showed from the command line. Could that be the problem?

Also, please post the error you are seeing with the Ant run. It's hard to offer assistance if we don't know what the problem is.

Sounds to me like whoever created the original build took a single logical project and created separate JAR files only for organizational purposes. My first recommendation would be to forget about the 20 JAR files and instead have only one project and create only one JAR file. Beyond that, if you can determine separate groups of cunctionality, you might be able to split this one project into 2 or more projets. For example, if there are utility classes in a util package and those don';t depend on anything else, there is one separate JAR. Then perhapds there are some packages that define an API or interface, and they depend on on the classes in the util packkage, those could go into another.

However, it you still want 20 JARs, there is a way to do it. One of the projects I migrated from Ant created a JAR of all classes in all packages, and then create a second JAR that contains only a few of the classes (less than 10). I couldn't break those classes into a separate projet because there were cross dependencies with the rest of the classes in the larger project. So I used the Maven JAR plugin to create a second JAR file containing only the desired classes, which I attached to the project using a classifier. In other words, I ended up with the following artifacts in the repository:
- xxx.pom
- xxx.jar
- xxx-foo.jar

Here is how I set up the plugin:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.4</version> <executions> <execution> <id>build-agenda-jar</id> <goals> <goal>jar</goal> </goals> <configuration> <archive> <manifestFile></manifestFile> <manifest> <addDefaultImplementationEntries>true</addDefaultImplementationEntries> </manifest> </archive> <includes> <include>**/package/xxx.class</include> </includes> <classifier>foo</classifier> </configuration> </execution> </executions> </plugin>

Then for any other projects that needed this particular JAR, I included the classifier in the dependency.

All of our official builds are done using the mvn command line (no Eclipse involved). But we do have each project configured for Eclipse with m2e; as Jeanne pointed out it makes manual Eclipse project configuration unnecessary because m2e will update the eclipse project config with the info in the pom.xml. Personally, I do my bootleg builds from the command line but most of my colleagues build their bootlegs within Eclipse.

I use CDBurnerXP: https://cdburnerxp.se/en/home

It is free for personal use only, see https://www.vmware.com/products/player/compare.html

You need to set up an LDAP Security realm . The security guide at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/ should provide the help you need.

Are you looking for something like what is present on the Changes page for a job? Or are you looking for something else? I suspect for release notes you would want all of the changes that were made since the prior release, which means you would need to have Jenkins keep all builds since the prior release; then the Changes page would have the full list for the component(s) built by that one job.