OK... First off, thank you Alexander for the suggestions.
Secondly, I realized what I was trying to do... I am trying to pass in run-time configuration, and just like any consumer of my artifact, I need to send in configuration. So, I created a /src/test/config directory. In that directory I put example/reference files "log4j.properties.ref" and "db.properties.ref". I added instructions in the README.txt file that says the users/builders of this project need to make a copy of those files as "log4j.properties" and "db.properties" respectively. Then, if they want to make any changes specific to their run-time setup, they do it in those two files. For Jetty, I then passed in system properties: <systemProperties> <systemProperty> <name>log4j.configuration</name> <value>file:/${basedir}/src/test/config/log4j.properties</value> </systemProperty> <systemProperty> <name>localDBProps</name> <value>file:/${basedir}/src/test/config/db.properties</value> </systemProperty> </systemProperties> Seems to be running great, and the new users aren't intimidated... I am also thinking of adding some antrun to the "validate" phase to fail fast and descriptive if the files are not where they are expected. - Nelz On 5/18/07, Alexander Sack <[EMAIL PROTECTED]> wrote:
Hi Nelz, Let me throw some ideas at you and take what you can. Here is what I do for all our internal projects: In the project's parent POM I have this: <profiles> <profile> <id>profile-db-postgresql</id> <properties> <jdbc.driverClassName>org.postgresql.Driver</jdbc.driverClassName> <jdbc.username>someusername</jdbc.username> <jdbc.password>somepassword</jdbc.password> <jdbc.url >jdbc:postgresql://localhost:5432/somedatabase?autoReconnect=true</fjdbc.url> </properties> <activation> <property> <name>profile-db-postgresql</name> </property> </activation> </profile> </profiles> This allows me to activate databases based on a command line switch (I know you don't like this approach). Your class files are probably loading them from some properties files. That properties files can be then included in your WAR or JAR and loaded from the classpath. In the example above, I have a sub project that builds a EJB3 jar. I use the resource substitution via my pom.xml like: <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build> So within my project, I have a src/main/resources where I stick my files that I want to be filtered. Btw, the resources directory is the default directory for a JAR to pick up extra files so I know it will be included in my final target output when I launch a build. Obviously the file included in src/main/resources looks like this: someapp.jdbc.ClassName = ${jdbc.driverClassName} someapp.jdbc.userName = ${jdbc.userName} ... etc. You could even have maven filter frame specific files such as an iBatis config or Hibernate file. I actually use the above approach to filter out datasource xml files for JBoss deployments. Your looking for per user username and password I suppose, so as per: http://maven.apache.org/guides/introduction/introduction-to-profiles.html You can EASILY do this via user specific profiles (I'm using the global POM based one, but the same approach applies, just change where the profile file is loaded from). Hopefully some of this helps, -aps On 5/18/07, Nelz <[EMAIL PROTECTED]> wrote: > > Hey All... > > I think I'm hitting one of the biggest problem areas in Maven: Properties. > > I'll put my requirement first, and the wrinkles I see after that. > > 1) I need to have a default set of properties for db connection (host, > port, username, password) that end up next to my compiled .class > files. > - Ok: User resource filtering. But where to put the default property > values in the POM? > > 2) I need each user to be able to override the default in their own > environment. > - My users are new, so I'd rather not make then specify anything > "extra" at the command line. (I'd prefer documenting a changes to > "settings.xml" first.) > - Can I have them specify their values in a /settings/profiles/profile > (that is meant to be an xpath-ish descriptor for example specification > only) section? > > X-3-X) I also need this to work with the jetty:run (Jetty 6) plugin... > (I didn't know if the resource filtering would work, but I just > checked and the Jetty6 plugin has /target/classes as the first entry > in the classpath... So, I am good on this point.) > > Am I going about this the wrong way? Isn't 2-tier web-app development > explicitly requiring "non-portability"? > > - nelz > > > Here's what I've gathered so far from: > 1a) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]