Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Project as usual consists of a set of modules. In my experience sometime even better to have some modules in separate source-controls repositories. For example, some utility-module or core-module like web-framework or DAO (ORM) module. In this case you able to use branches in source-controls as they <strong>should</strong> be used - to support trunk-development and support of each released version in the same source-controls repository to have ability to merge branches. </p> <p>So I propose you re-design structure of your application modules in such way that allows you to separate core (open-source) functions from commercial (customer dependent) customization. So to manage open-source &amp; commercial releases you need to have a separate assembly procedures - they can be more-or-less similar or even commercial release can use an open-source release as set of complete artifacts and extends they.</p> <p>In fact that is very interest task - I've spent a lot of time on it last year. My decision is to have one core-repositoy (open-source) with fully functioned maven task to release it. And a separate repo for each customer that keeps only design customization &amp; some customer-specific business-logic (just use aliases in customer's spring XML to override your "core" Spring services - see <a href="http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/beans/factory/support/DefaultListableBeanFactory.html#setAllowBeanDefinitionOverriding%28boolean%29" rel="nofollow">BeanDefinitionOverriding</a>) and the maven-task for my customer is based on usage of core-artifacts (often extends some of them - see for example "overlays" in <a href="http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#overlays" rel="nofollow">maven-war-plugin</a> that allows to extend existed WAR). Dealing in such way you will never have a clone of the same class in another branch - you will use it or extends it exactly like you use log4j classes in your application. You should just extends the open-source release.</p> <p>Another interest task is how to manage config-files. I recommend you to see on <a href="http://maven.apache.org/plugins/maven-remote-resources-plugin/" rel="nofollow">Maven Remote Resources Plugin</a> instead of default <a href="http://maven.apache.org/plugins/maven-resources-plugin/" rel="nofollow">Maven Resources Plugin</a>. It allows you o have a template of configuration files and move all values to <a href="http://maven.apache.org/guides/introduction/introduction-to-profiles.html" rel="nofollow">maven profiles</a> that should be specific for each customer. And see on <a href="https://github.com/maoo/maven-tiles/blob/master/tiles-maven-plugin/pom.xml" rel="nofollow">Maven Tiles Plugin</a> - it helps me to dramatically simplify "pom.xml" in customer's project (I can re-use "tiles" of maven build &amp; assembly procedure)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload