1

I'm building a project using maven and I need to ensure it works over Java SE and different Java EE containers. There're already integration tests written for WildFly container. And now I'm moving to Java SE.

But face to this multiple test environments, how should I handle them in maven ? Should I use <profile>, <module> or something else ?

  • <profile> is useful to switch between different profiles and each of them can have their specific dependencies. So in my case, there might be profiles: wildfly-embedded, wildfly-managed, java-se etc. But I need to ensure the project works on every profile, is it possible to run all the profiles in one command ?

  • <module> can handle project inheritance. After reading the post SO • Why and when to create a multi-module Maven project?, I'm still confused about if I should use it in my case.

Can somebody give me some ideas ? That will be very helpful, thanks.

Community
  • 1
  • 1
Mincong Huang
  • 5,284
  • 8
  • 39
  • 62

1 Answers1

1

If you keep in mind that the resulting artifact should always be the same no matter the activated profiles, then you should understand that profile is not the correct solution (although it is very often abused for it. Don't try to go for that advice!) Configuration should be outside the artifact, so you can reuse the same artifact over and over again. Since many people ask for the proper solution with embedded configuration, Karl Heinz created https://github.com/khmarbaise/multienv-maven-plugin . This is probably the closest you'll get to a valid Maven project setup.

Robert Scholte
  • 11,889
  • 2
  • 35
  • 44
  • Thanks for your advice, @RobertScholte. I agree with you about profile and so I'll avoid using it. As for the Karl Heinz's project, this is an interesting plugin, but I'm looking for something native without additional "dependency". – Mincong Huang Jun 26 '16 at 19:18
  • What do you mean by additional "dependency" ? – khmarbaise Jun 26 '16 at 19:18
  • I guess it's about attached/classified artifacts. In that case you need to let Maven do only the building part. Let the process doing the tests (e.g. Jenkins) be responsible to embed the right configuration. – Robert Scholte Jun 26 '16 at 20:59
  • @RobertScholte, actually, I mean I don't want any plugin to do this because I'm an intern of Hibernate and I'm not sure they're ready to add a plugin to their framework. They handle already tests over different envs, e.g all the db, all the container. So I must follow these structure and add my own test cases when I add my commit. However, it's difficult to understand their pom when you're new ... – Mincong Huang Jun 28 '16 at 10:00
  • As far as I know, we can separate a project into multiple modules. Then we can create a module for integration tests in Java SE, another for integration tests in Java EE. Is that a good approach ? – Mincong Huang Jun 28 '16 at 10:02
  • Okay, I have a more clear picture of your question. If these integration-tests are never released you can choose to go for profiles, since it'll never result in any artifact. Choosing between modules or profiles depends on the implementation of your integration tests. It also depends on the way you execute the plugins. If you give the execution-block per profile a unique id, you should be able to run them all at once. – Robert Scholte Jun 28 '16 at 17:54
  • Okay, I understand what you say. In this case, I'll use profiles and give them unique ids. Thanks, @RobertScholte. I'll pose another question if I still need helps :) – Mincong Huang Jun 29 '16 at 09:29