-
1. Re: How to resolve ${user.home} parameter when using propertiesFile ?
sonecabr May 4, 2016 8:03 PM (in response to haiaw)Hi Colin,
Did you used profles on your pom.xml? That variable are parsed if you activate <filtering>true</filtering> on resource attribute on your pom.xml. You may also try use assenbly to copy specific files to specifc folders.
-
2. Re: How to resolve ${user.home} parameter when using propertiesFile ?
haiaw May 6, 2016 5:44 AM (in response to sonecabr)It doesnt help, I changed a bit a popular wildfly example jsf-primefaces-wildfly to show this problem. Just do mvn wildfly:run and see the logs and the application starts at http://localhost:9090/codenotfound/
and there you can also see the problem in firstName field.
See the attachment.
You must change pom.xml to point to your Wildfly server:
<jboss.home>C:\Data\applications\wildfly-9.0.2.Final</jboss.home>
and
<jbossHome>${jboss.home}</jbossHome>
-
3. Re: How to resolve ${user.home} parameter when using propertiesFile ?
jamezp May 5, 2016 7:57 PM (in response to haiaw)In the pom.xml in your script you have the jboss-home configuration property set to WLF_HOME which is not defined in your pom.
<jbossHome>${WLF_HOME}</jbossHome>
That should be set to ${jboss.home} which is defined as
<jboss.home>C:\DANE\Java\wildfly-9.0.2.Final</jboss.home>
For the run goal you can also just leave that parameter off and WildFly will be downloaded. Though I guess that would break the copy-resource goal.
I'd be curious to know why JPA and logging have been removed from the container though. This could actually be done with CLI so there would be no need for the standalone.xml to be copied.
Another note is com.sun.faces dependencies should be marked as <scope>provided</scope>. These should already be supplied by the container.
--
James R. Perkins