I'm not sure I fully understand, but some general rules: 1) Keep all configuration outside the jars. If you don't want to use a database or jndi, you could always (which I very often recommend) just use a properties file read from the classpath. During runtime just make sure the properties file exists on the classpath. This type of config file might not even be handled in your scm as the configuration for each environment is not known during development. Default values (if possible) should be provided by the the application. 2) If you have other environment specific resources (images or whatever) you could handle those the same way. You could bundle those in a jar and put the jar on the classpath if you want.
/Anders On Thu, Jul 14, 2011 at 15:58, mark.angrish <[email protected]> wrote: > I sent this to Anders Hammar but i thought i would cross post this to the > community as well: > > In the past i have used profiles for environment configuration (uat, prod > etc.) but as most people know this becomes quite problematic (different > profile causes rebuild and redploy with env specific settings etc. and > what's more maven forces the recompilation.. i can think of a million more > reasons too!) > > What i currently have is just plan java projects (no j2ee, or frameworks > etc.) that are client/server based. I typically end up with a client, a > server and a 'common' jar that is shared by both other artifacts. I also > have a parent pom to control dependencies across all artifacts (but they > are > not modules as the gui can increment independantly of the server). > > - <project-name> > - pom.xml > - <project-name>-gui > - src/main/java > - src/main/resources > - pom.xml > - <project-name>-common > - src/main/java > - src/main/resources > - pom.xml > - <project-name>-server > - src/main/java > - src/main/resources > - pom.xml > > All the resources directories here contain nothing but 'static' resources > (images, dictionary files, static templates for 3rd parties i.e. these > don't > change and if they did, it would be for development reasons). > > It's at this point i get frustrated! > > What i need to achieve is: > - being able to run a configured version of the server for my desktop > (local) environment that can be run inside my IDE (eclipse or IDEA). This > is of a very high importance to my team. > - being able to deploy a configured version of the server to a particular > environment (DEV, UAT, PROD etc.). > - I don't have a database or a ubiquitious jndi server available (machines > are across firewalls) to store configuration. It also seems like overkill > for what we need. > > My current idea is as follows: > Create a project called <project-name>-build (or -package) which is a jar > project that only contains resource and deployment type directories. This > should allow me to develop locally and release to different environments > but > it does place an environment specific version of my 'resources' jar into > the > repository (due to running the assembly). This dependency can be > implemented if i make the server's pom depend on this artifact. This > project would also have the assembly descriptor to create my environment > specific tarballs as well. I don't like this idea at all but i cannot > think > about how better to seperate the jar build from the act of development and > deployment! > > - <project-name>-build > - src/main/filters > - src/main/config > - src/main/assembly > - src/main/sql > - src/main/scripts > - pom.xml > > Any help you could give me here would be greatly appreciated! > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-environment-configurations-tp4586719p4586719.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
