Asked  7 Months ago    Answers:  5   Viewed   27 times

I have two JSF projects that share a lot of code - java classes, xhtml files, tag libraries, css and javascript files etc. My dev environment/platform consists mainly of Eclipse, Ant, Perforce and Tomcat.

Has anyone found a way to create and organize the shared code so that the common code can stay within one set of folders?

Eclipse makes it easy to add external folders for java sources, but falls short on the other file types. I'd appreciate any ideas.



Create a new "Java Project" in Eclipse. Add it as another project to the Deployment Assembly property of the main dynamic web project. This way it will automatically end up as a JAR in /WEB-INF/lib of the build of the web project. Since newer Eclipse versions, you can also create the project as "Web Fragment Project". This way the Deployment Assembly step will be done automatically.

Put all those shared JSF2/Facelets resource files in /META-INF/resources folder of the Java project. Just treat it like WebContent/resources of the main web project. Tagfiles can just be kept in their own /META-INF/tags folder.


 |    |-- resources
 |    |    `-- common
 |    |         |-- css
 |    |         |    `-- some.css
 |    |         |-- js
 |    |         |    `-- some.js
 |    |         |-- images
 |    |         |    `-- some.png
 |    |         |-- components
 |    |         |    `-- somecomposite.xhtml
 |    |         `-- sometemplate.xhtml
 |    |-- tags
 |    |    `-- sometag.xhtml
 |    |-- beans.xml
 |    |-- faces-config.xml
 |    |-- some.taglib.xml
 |    |-- web-fragment.xml
 |    `-- MANIFEST.MF


<h:outputStylesheet library="common" name="css/some.css" />
<h:outputScript library="common" name="js/some.js" />
<h:graphicImage library="common" name="images/some.png" />
<common:somecomposite />
<common:sometag />
<ui:include src="/common/sometemplate.xhtml" />

In case you're using Maven, the /META-INF folder has to be placed in src/main/resources and thus NOT src/main/java.

If you want to trigger the JSF2 annotation scanner as well so that you can put @ManagedBean, @FacesValidator, @FacesConverter and consorts in that project as well, create a JSF2 compatible /META-INF/faces-config.xml file as well (it can even be kept empty).

<?xml version="1.0" encoding="UTF-8"?>

That's all.

See also:

  • Splitting up shared code and web.xml from WAR project to common JAR project
  • JSF facelets template packaging
  • Obtaining Facelets templates/files from an external filesystem or database
Tuesday, June 1, 2021
answered 7 Months ago

So, I recently did something similar, and found that the strategy below is the best option. I'm going to assume that you are familiar with git branching at this point, as well as Heroku remotes. If you aren't, you should read this first:

The main strategy I'm taking is to have a single codebase (a single Git repo) with:

  • A master branch that contains all your shared code: templates, views, URLs.
  • Many site branches, based on master, which contain all site-specific customizations: css, images, settings files (if they are vastly different).

The way this works is like so:

First, make sure you're on the master branch.

Second, create a new git branch for one of your domains, eg: git checkout -b

Third, customize your branch so that it looks the way you want.

Next, deploy live to Heroku, by running heroku create --remote

Now, push your branch code to your new Heroku application: git push This will deploy your code on Heroku.

Now that you've got your branch deployed with its own Heroku application, you can do all normal Heroku stuff by adding --remote to your normal Heroku commands, eg:

  • heroku pg:info --remote
  • heroku addons:add memcache:5mb --remote
  • etc.

So, now you've basically got two branches: a master branch, and a branch.

Go back to your master branch, and make another new branch for your next domain: git checkout master; git checkout -b Then customize it to your liking (css, site-specific stuff), and deploy the same way we did above.

Now I'm sure you can see where this is going by now. We've got one git branch for each of our custom domains, and each domain has it's own Heroku app. The benefit (obviously) is that each of these project customizations are based off the master branch, which means that you can easily make updates to all sites at once.

Let's say you update one of your views in your master branch--how can you deploy it to all your custom sites at once? Easily!

Just run:

  • git checkout
  • git merge master
  • git push # deploy the changes

And repeat for each of your domains. In my environment, I wrote a script that does this, but it's easy enough to do manually if you'd like.

Anyhow, hopefully that helps.

Tuesday, August 3, 2021
answered 4 Months ago

Mat be the JSF page Designer (or now "Web Page Editor") could do what you want?
It is illustrated in this myeclipse page

alt text

As mentioned in this thread, you can make the Visual Page Designer the default editor for JSP pages

The JSF Tools Project-contributed Web Page Editor is NOT registered as the default editor for JSP files.
You can make the WPE the default editor for JSP files by following these steps:

  • Navigate to "Window" -> "Preferences..." -> "General" -> "Editors" -> "File Associations"
  • In the "File types" section, select "*.jsp"
  • In the "Associated editors" section, select "Web Page Editor"
  • Select the "Default" button
Friday, August 13, 2021
answered 4 Months ago

Looking at the Settings panel that Maheshbabu Jammula posted, you can see an Inline Elements list. Just remove <tr> and <td> tags from the list and those tags will always land in a new line. Take Care!

Preferences > Web > HTML Files > Editor

enter image description here

Monday, October 11, 2021
Little Monkey
answered 2 Months ago

The cn1lib approach is definitely a good one but not always easy or practical.

An approach we offered to some developers is to create one version of the app as usual (free or pro) then add a new package name for the other version e.g. if your app is com.mycompany.myfreeapp then you can add the package com.mycompany.myproversion after the fact.

Your pro main class can derive the free main class and even have the same exact name (since they are in different packages) and so you can have one project with two versions.

To get this to actually work you will need two tricks, copy your files and replace all mentions of the package (and main class if you changed that too) to the pro/free version. You will also need to replace the provisioning profiles for iOS (just re-run the wizard).

To run this in the debugger just edit the run section in the project preferences to point at the right main class.

You can codify this into a small script that does all of those things once you go thru this process.

Friday, November 26, 2021
Andrew Nguyen
answered 1 Week ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :