How to partition a JSF project for developers vs UI coders, when using Git as the code repository

2
votes

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.

1
eclipsegitjsfmavenjenkins
Do you not want the designers to have Java code out of security (or similar) concerns, or just because you don't want them to have to download extra stuff to do their work? – Roman
Like other version control software, you should provide permission for your users to read/write on files and folders. I haven't worked with Git yet, but I guess this could be configured easily with a Git administrator tool. – Luiggi Mendoza
@RomanArmy - mainly because I want to keep it simple for them, and not have to download all the code and libs, etc. when they won't need it. Also, will have fewer issues even with optimistic locking by not "checking out" objects to people who won't use them. I have thought about security as well - I'm not paranoid about it but there is no need to unnecessarily increase risk. – Ramesh
@LuiggiMendoza In Git you will clone the whole repository which means you have the full control over it on your local harddrive. So there no option to control the access within the local repository. – khmarbaise
Realistically, it would probably be easier for them to just check out the entire project. Only the initial clone would be slow, and the rest of the operations will be fast. You could split it up by putting the UI part into a submodule of the project, but it might make it more awkward for everyone else to work. – Roman

1 Answers

1
votes

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