0

I have a project structure, where I have some basic projects, where all the features are implemented and on top of that some projects for different kinds of usage/deployment as follows:

  • foo-core
  • foo-production, depends on foo-core (produces a war file and i delivered to customers)
  • foo-standalone, depends on foo-core (produces a war used for internal testing)
  • foo-ui-test, depends on foo-core (UI tests with Arquillian+Selenium)

Now I have a rising number of classes that are useful for foo-standalone and for foo-ui-test, but I don't want to deploy these classes to the customer. Therefore foo-core is out as a possible project where to store these classes. The two remaining options are:

  1. A new project foo-helper which depends on foo-core and make foo-standalone and foo-ui-test depend on foo-helper instead of foo-core.
  2. Make foo-ui-test depend on foo-standalone

I'd like to go for option 2 as I already have a lot of projects. The remaining problem for option 2 is that both of these projects (foo-standalone and foo-ui-test) have a Spring WebApplicationInitializer... Now I fiddled around with my build system (I use gradle) and was able to exclude the WebApplicationInitializer in the foo-standalone project and only explicitly include it when building the foo-standalone.war file.

The resulting build.gradle file for foo-standalone seems "hackish" and will break if I rename or move the WebApplicationInitializer class. I wonder, if there is another way to achieve what I'm looking for or if I have to make a new project.

Update I moved the WebApplicationInitializer class from src/main/java to src/init/java and changed the build.gradle of foo-standalone as follows:

sourceSets {
  init {
    java {
      compileClasspath += sourceSets.main.runtimeClasspath
    }
  }
}

war {
  classpath sourceSets.init.runtimeClasspath
}

I guess that's the shortest, custom way to do this, or is there any built-in gradle functionality which does this?

schauk11erd
  • 624
  • 9
  • 21

1 Answers1

0

Maven will only allow you to have a dependency to a JAR project. There is a feature where you can have war overlays, where one war project extends a child and overrides certain bits (see https://maven.apache.org/plugins/maven-war-plugin/overlays.html) this seems the relationship between your foo-standalone and foo-ui-test.

So make foo-helper a war project and make foo-standalone, foo-ui-test and foo-production extend it using war overlays.

foo-core can stay as a jar, if there are non-production bits create a foo-core-internal to depend on foo-core and ring fences the internal/test bits.

Essex Boy
  • 7,565
  • 2
  • 21
  • 24