Home/ Questions/Q 8410259
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T00:07:52+00:00

I am migrating my JSF application to Cloudbees – basically a Maven/Jenkins/Git platform. Unfortunately,

  • 0

I am migrating my JSF application to Cloudbees – basically a Maven/Jenkins/Git platform. Unfortunately, I don’t have a lot of experience with Maven/Jenkins/Git.

I want to create a simple way that UI developers can stay in synch with the xhtml and related UI files, without needing the Java code on their machines. Java developers would need both the UI code and the java code. In both cases, when they push their content, it should be integratable with Jenkins continuous build process.

Is there a good pattern or suggestion you could make to partition the project, so that the UI developers have their XHTML and other files (images, CSS, etc), while the Java developers have everything? This would need to work with Maven, Git, and Jenkins. Thanks for all the help.

One last thing – java developers will be using Eclipse. UI developers don’t need to use Eclipse, so the link will be Git.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is really just a Maven/JSF question. Jenkins does not really enter the equation, and neither does CloudBees (note we [cloudbees] also support Subversion hosted repositories which may or may not fit your project structure better… in any case GIT is IMHO “better” so I would go for GIT over Subversion if it was me)

    You have three options really.

    1. Keep the XHTML in a separate GIT repository

    2. Keep everything in one repository.

    3. A kind of mix of 1 & 2

    Option 1

    This will drive you down the road of GIT submodules… that is the one case where I would favour Subversion over GIT… and no I don’t mean that svn:externals is better that GIT, more that Subversion allows you to check out a portion of the repository, so the UI team could just check out the sub-path where the XHTML files live, IOW

    $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk/web-module/src/main/webapp web-content
$ cd web-content

    would work for the UI team and

    $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk jsf-app
$ cd jsf-app
$ mvn package

    will work for the Java developers.

    To achieve the same with GIT requires the use of sub-modules, so you would have one sub-module at web-module/src/main/webapp in the jsf-app GIT repo.

    Where this becomes a pain is when the Java developers need to make tweaks to the XHTML files as well, depending on the IDE it can be tricky to get the commits in the submodule to take correctly. Also you now do not have a single revision to track, the two repos can move independently… which can degrade some of the features of GIT.

    When you want to use the Maven release plugin (and you should want to) Submodules will prevent you, as both the idea of tagging submodules is not currently supported by the release plugin, and there is that two separate repos to track issue again.

    Option 2

    This really is the better option… even though it is doing exactly what you said you didn’t want to do.

    The trick here is to make the UI developer’s life easier.

    You should set up a nice Maven profile with a default goal which ends up running the web application with e.g. jetty:run see for example This pom profile If you check out that project and just run

    $ mvn -Pdemo

    It will fire up the web application from the sub-module having built all the dependent modules.

    Using this approach means that the UI guys can also test the UI changes integrated into the JSF app reducing the load on the Java guys.

    Option 3

    This is a kind of mix, you have separate GIT modules for the XHTML and the Java, but they are valid Maven projects.

    You can achieve this in two ways…

    • Have the XHTML module be a <packaging>war</packaging> which is extracted into the Java web-app using Maven War Overlays

    • Have the XHTML module be a <packaging>war</packaging> which has the Java dependencies pulled in directly.

    The first has the advantage that the Java developers can work with the Java code quickly, but the side-effect is fixing XHTML is tricky e.g. data-binding attributes

    The second makes tweaking the Java harder (have to keep running mvn install), the UI guys have to pull down the Java .JARs from the remote Maven repo if they want to spin up the Maven packaging, and hence you may expose some of your java internals to the UI guys.

    TL;DR

    Personally, unless keeping things secret from the UI guys is something that is important, I would pick Option 2

    • 0