Version plugin with Maven 3.0.2
Hi, We have recently shifted to Maven 3.0.2 and we are facing the following issue while running the version plugin. Any clues? 24439 02/07/11 06:40PM EXEC [java] [INFO] Searching for local aggregator root... 24440 02/07/11 06:40PM EXEC [java] [INFO] Local aggregation root: C:\BFB\xyz\main\build\main 24441 02/07/11 06:40PM EXEC [java] --- 24442 02/07/11 06:40PM EXEC [java] constituent[0]: file:/C:/apache-maven-3.0.2/bin/../lib/aether-api-1.9.jar 24443 02/07/11 06:40PM EXEC [java] constituent[1]: file:/C:/apache-maven-3.0.2/bin/../lib/aether-connector-wagon-1.9.jar 2 02/07/11 06:40PM EXEC [java] constituent[2]: file:/C:/apache-maven-3.0.2/bin/../lib/aether-impl-1.9.jar 24445 02/07/11 06:40PM EXEC [java] constituent[3]: file:/C:/apache-maven-3.0.2/bin/../lib/aether-spi-1.9.jar 24446 02/07/11 06:40PM EXEC [java] constituent[4]: file:/C:/apache-maven-3.0.2/bin/../lib/aether-util-1.9.jar 24447 02/07/11 06:40PM EXEC [java] constituent[5]: file:/C:/apache-maven-3.0.2/bin/../lib/commons-cli-1.2.jar 24448 02/07/11 06:40PM EXEC [java] constituent[6]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-aether-provider-3.0.2.jar 24449 02/07/11 06:40PM EXEC [java] constituent[7]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-artifact-3.0.2.jar 24450 02/07/11 06:40PM EXEC [java] constituent[8]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-compat-3.0.2.jar 24451 02/07/11 06:40PM EXEC [java] constituent[9]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-core-3.0.2.jar 24452 02/07/11 06:40PM EXEC [java] constituent[10]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-embedder-3.0.2.jar 24453 02/07/11 06:40PM EXEC [java] constituent[11]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-model-3.0.2.jar 24454 02/07/11 06:40PM EXEC [java] constituent[12]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-model-builder-3.0.2.jar 24455 02/07/11 06:40PM EXEC [java] constituent[13]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-plugin-api-3.0.2.jar 24456 02/07/11 06:40PM EXEC [java] constituent[14]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-repository-metadata-3.0.2.jar 24457 02/07/11 06:40PM EXEC [java] constituent[15]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-settings-3.0.2.jar 24458 02/07/11 06:40PM EXEC [java] constituent[16]: file:/C:/apache-maven-3.0.2/bin/../lib/maven-settings-builder-3.0.2.jar 24459 02/07/11 06:40PM EXEC [java] constituent[17]: file:/C:/apache-maven-3.0.2/bin/../lib/nekohtml-1.9.6.2.jar 24460 02/07/11 06:40PM EXEC [java] constituent[18]: file:/C:/apache-maven-3.0.2/bin/../lib/plexus-cipher-1.4.jar 24461 02/07/11 06:40PM EXEC [java] constituent[19]: file:/C:/apache-maven-3.0.2/bin/../lib/plexus-component-annotations-1.5.5.jar 24462 02/07/11 06:40PM EXEC [java] constituent[20]: file:/C:/apache-maven-3.0.2/bin/../lib/plexus-interpolation-1.14.jar 24463 02/07/11 06:40PM EXEC [java] constituent[21]: file:/C:/apache-maven-3.0.2/bin/../lib/plexus-sec-dispatcher-1.3.jar 24464 02/07/11 06:40PM EXEC [java] constituent[22]: file:/C:/apache-maven-3.0.2/bin/../lib/plexus-utils-2.0.4.jar 24465 02/07/11 06:40PM EXEC [java] constituent[23]: file:/C:/apache-maven-3.0.2/bin/../lib/sisu-guice-2.9.1-noaop.jar 24466 02/07/11 06:40PM EXEC [java] constituent[24]: file:/C:/apache-maven-3.0.2/bin/../lib/sisu-inject-bean-1.4.3.1.jar 24467 02/07/11 06:40PM EXEC [java] Exception in thread main java.lang.StackOverflowError 24468 02/07/11 06:40PM EXEC [java] constituent[25]: file:/C:/apache-maven-3.0.2/bin/../lib/sisu-inject-plexus-1.4.3.1.jar 24469 02/07/11 06:40PM EXEC [java] at java.io.FileInputStream.readBytes(Native Method) 24470 02/07/11 06:40PM EXEC [java] constituent[26]: file:/C:/apache-maven-3.0.2/bin/../lib/wagon-file-1.0-beta-7.jar 24471 02/07/11 06:40PM EXEC [java] at java.io.FileInputStream.read(FileInputStream.java:199) 24472 02/07/11 06:40PM EXEC [java] constituent[27]: file:/C:/apache-maven-3.0.2/bin/../lib/wagon-http-lightweight-1.0-beta-7.jar 24473 02/07/11 06:40PM EXEC [java] at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) 24474 02/07/11 06:40PM EXEC [java] constituent[28]: file:/C:/apache-maven-3.0.2/bin/../lib/wagon-http-shared-1.0-beta-7.jar 24475 02/07/11 06:40PM EXEC [java] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) 24476 02/07/11 06:40PM EXEC [java] constituent[29]: file:/C:/apache-maven-3.0.2/bin/../lib/wagon-provider-api-1.0-beta-7.jar 24477 02/07/11 06:40PM EXEC [java] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) 24478 02/07/11 06:40PM EXEC [java] constituent[30]:
Re: [maven-failsafe-plugin] Running integration test with its own profile
Hi Ron, I've been reading quite some of your posts in the forum, and it actually changed my mind about deployment configuration. Enlightening indeed. I would now try to favor a single artifact deployment that could be configured externally - say JNDi, this really makes sense. That said, I don't want to compromise on the ease of deployment. Up to now our customer just had to drop the war in it's app server, and that was it. Plus, we were app server agnostic, we could deploy on whichever server WITHOUT ANY configuration. Trying to figure a way to combine both requirement, here is what I'm imagining, and I'd like to hear your opinion on this, whether it makes sense and if it's possible with JNDI. 1) If we use JNDI to configure the WAR on runtime, and if we want to have a 'dropping war only' deployment, the only option is to include all the needed JNDI configuration IN the war. Is this at all possible? 2) there need to be a way to select the adapted JNDI configuration: I'm thinking environment variable here, it'd certainly be the simplest configuration on top of installing the app server. What do you think? cheers -- View this message in context: http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3375605.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse:eclipse maven 3.0.1 not adding dependency
Hi again, I have fixed this now but it didn't help with just mvn clean:clean install to get it in the local repository. I also needed to mvn eclipse:eclipse on all referencing projects to get it to work. This was not necessary when working on the pc. Thanks for your help. -- View this message in context: http://maven.40175.n5.nabble.com/eclipse-eclipse-maven-3-0-1-not-adding-dependency-tp3330388p3375620.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 support for org.apache.maven.user-settings
Benjamin Bentmann wrote: There is no alternative but support for the system property can be restored if there's a valid use case for it. Benjamin we have a hudson CI server running builds for multiple (maven) projects, each with its own repositories. it would be nice to seperate the settings.xml between builds, and not lump them all together - for that i'd need to override the location of the settings file. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-tp3261146p3375624.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-failsafe-plugin] Running integration test with its own profile
JNDI is not the only way.
Another good way is the .properties file on the classpath
This can work even better if you have default properties in your war,
so you do something like
public static final class Configuration {
private static final class ResourceHolder {
private static final Configuration INSTANCE = newConfiguration();
}
private final Properties config;
private Configuration() {
Properties defaultConfig = new Properties();
InputStream is = null;
try {
is = Configuration.class.getResource(Configuration.class.getSimpleName()
+ .properties); // load the defaults from the war
if (is != null) {
defaultConfig.load(is);
}
} catch (IOException e) {
// unable to load defaults, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
config = new Properties(defaultConfig);
InputStream is = null;
try {
is = Configuration.class.getResource(/ +
Configuration.class.getSimpleName() + .properties); // load the
customer config from the classpath
if (is != null) {
config.load(is);
}
} catch (IOException e) {
// unable to customer config, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
}
public static Configuration getInstance() {
return ResourceHolder.INSTANCE;
}
...
}
Obviously there's more you can do.
you put the default configuration resource in the same package as the
Configuration class.
the customer just puts the Configuration.properties in the root
package, so in JBOSS they just put their config in
$JBOSS_HOME/server//conf
in Tomcat 5.x it's $CATALINA/shared/classes I'd have to dig out the
location for 6.x and 7.x
etc.
If you go the properties route (and you could use an XML file or a
YAML file or whatever you want the config file to be in) I'd consider
implementing periodic scanning for changes or else tell customers they
need to restart the webapp to pick up the config changes.
-Stephen
On 8 February 2011 09:29, nodje nodje...@gmail.com wrote:
Hi Ron,
I've been reading quite some of your posts in the forum, and it actually
changed my mind about deployment configuration. Enlightening indeed.
I would now try to favor a single artifact deployment that could be
configured externally - say JNDi, this really makes sense.
That said, I don't want to compromise on the ease of deployment. Up to now
our customer just had to drop the war in it's app server, and that was it.
Plus, we were app server agnostic, we could deploy on whichever server
WITHOUT ANY configuration.
Trying to figure a way to combine both requirement, here is what I'm
imagining, and I'd like to hear your opinion on this, whether it makes sense
and if it's possible with JNDI.
1) If we use JNDI to configure the WAR on runtime, and if we want to have a
'dropping war only' deployment, the only option is to include all the needed
JNDI configuration IN the war.
Is this at all possible?
2) there need to be a way to select the adapted JNDI configuration: I'm
thinking environment variable here, it'd certainly be the simplest
configuration on top of installing the app server.
What do you think?
cheers
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3375605.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Distibute an webapp as an ear and multiple wars
Hello I have this project that consists of multiple war modules, and the requirement to distributed the artifacts as an ear, but also a collection of single wars so they can be deployed in an environment that does not support ear deployment. The problem is that I am using skinny wars and i would like to inject the common libraries in each war. My first approach was using the multiple executions of the war plugin with different overlays to generate skinny and fat wars, but i would like to just generate a single artifact per module. I was thinking of creating a new module that could inject the common libraries in each war and assembly the wars within a zip for simple distribution. Is this possible? For some context here is my project structure Project - WebApp1 - WebApp2 - WebApp3 - common - ear Best regards João Ferreira
Re : Unable to get the mvn release:prepare work
Hi, Can you run svn status in your project folder (I asume you are using SVN). Regards, Julien - Message d'origine De : ravi_atluri raviteja.atl...@gmail.com À : users@maven.apache.org Envoyé le : Lun 7 février 2011, 21h 39min 11s Objet : Re: Unable to get the mvn release:prepare work Hi Anders, I have locally modified files which I committed to my repository but still I get this. Thanks. On 7 February 2011 12:34, Anders Hammar [via Maven] ml-node+3374881-938815243-147...@n5.nabble.com wrote: You have locally modified files? The release plugin checks that all files are in sync with scm. More info at [1]. /Anders [1] http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html On Mon, Feb 7, 2011 at 21:07, ravi_atluri [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=0 wrote: Hi when I am trying to run the mvn release:prepare for my project it is giving me this error: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Cannot prepare the release because you have local modifications : [Accounts/pom.xml:modified] [Storage-Web/pom.xml:modified] [Product/pom.xml:modified] [Personalization/pom.xml:modified] [SocialNetworking/pom.xml:modified] [DeviceLogs/pom.xml:modified] [Community/pom.xml:modified] [LogAnalysis/pom.xml:modified] [DB/pom.xml:modified] [AddrBook/pom.xml:modified] [UsageLogs/pom.xml:modified] [Render-Web/pom.xml:modified] [pom.xml:modified] [QA/Web-PerformanceTests/pom.xml:modified] [QA/Web-IntegrationTests/pom.xml:modified] Any help would be greatly appreciated. Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374840.htmlhttp://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374840.html?by-user=t Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=2 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374881.html To unsubscribe from Unable to get the mvn release:prepare work, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3374840code=cmF2aXRlamEuYXRsdXJpQGdtYWlsLmNvbXwzMzc0ODQwfDEyOTM0NjQzMDg=. -- View this message in context: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374890.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re : Unable to get the mvn release:prepare work
On Tue, Feb 8, 2011 at 3:01 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Can you run svn status in your project folder (I asume you are using SVN). The plugin output indicates that it is some of the pom files that have local modifications. If you want local files to be in your directory, but don't want them checked in, have a look at the svn propedit command: svn propedit svn:ignore ./ which will let you ignore certain files if you need. Regards, Julien - Message d'origine De : ravi_atluri raviteja.atl...@gmail.com À : users@maven.apache.org Envoyé le : Lun 7 février 2011, 21h 39min 11s Objet : Re: Unable to get the mvn release:prepare work Hi Anders, I have locally modified files which I committed to my repository but still I get this. Thanks. On 7 February 2011 12:34, Anders Hammar [via Maven] ml-node+3374881-938815243-147...@n5.nabble.com wrote: You have locally modified files? The release plugin checks that all files are in sync with scm. More info at [1]. /Anders [1] http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html On Mon, Feb 7, 2011 at 21:07, ravi_atluri [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=0 wrote: Hi when I am trying to run the mvn release:prepare for my project it is giving me this error: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Cannot prepare the release because you have local modifications : [Accounts/pom.xml:modified] [Storage-Web/pom.xml:modified] [Product/pom.xml:modified] [Personalization/pom.xml:modified] [SocialNetworking/pom.xml:modified] [DeviceLogs/pom.xml:modified] [Community/pom.xml:modified] [LogAnalysis/pom.xml:modified] [DB/pom.xml:modified] [AddrBook/pom.xml:modified] [UsageLogs/pom.xml:modified] [Render-Web/pom.xml:modified] [pom.xml:modified] [QA/Web-PerformanceTests/pom.xml:modified] [QA/Web-IntegrationTests/pom.xml:modified] Any help would be greatly appreciated. Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374840.html http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374840.html?by-user=t Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=3374881i=2 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374881.html To unsubscribe from Unable to get the mvn release:prepare work, click here http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=3374840code=cmF2aXRlamEuYXRsdXJpQGdtYWlsLmNvbXwzMzc0ODQwfDEyOTM0NjQzMDg= . -- View this message in context: http://maven.40175.n5.nabble.com/Unable-to-get-the-mvn-release-prepare-work-tp3374840p3374890.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Cave Systems Architect Jemstep, Inc www.jemstep.com
maven-failsafe-plugin + soapui (verifying junitresults from external tool)
Hi, Is there a way to let the failsafe-plugin verify the junit reports of an external tool (in this case: soapui-maven-plugin) without writing any integration tests in Java. Configuring the pom should be enough (in fact: I've already come this far). Or is there some other way to verify the junit-results? Just letting soapui handle the tests is not good enough, because I need to start up and shut down a server. -Robert Scholte Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: maven-failsafe-plugin + soapui (verifying junitresults from external tool)
One thing that should be done is filing a ticket on the soapui project that they create separate goals for executing the tests and verifying the outcome, like the failsafe-plugin does. I've been planning to do this for some time, but haven't got around to do it. /Anders On Tue, Feb 8, 2011 at 10:40, Scholte, Robert robert.scho...@logica.comwrote: Hi, Is there a way to let the failsafe-plugin verify the junit reports of an external tool (in this case: soapui-maven-plugin) without writing any integration tests in Java. Configuring the pom should be enough (in fact: I've already come this far). Or is there some other way to verify the junit-results? Just letting soapui handle the tests is not good enough, because I need to start up and shut down a server. -Robert Scholte Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Has the behavior of -U option changed?
Thanks but in our case there is no need to go to Maven central because the Artifactory server hosts the dependency. In a nutshell, Team 1 builds the components and Team 2 builds the applications, they both publish to the same repository. -- View this message in context: http://maven.40175.n5.nabble.com/Has-the-behavior-of-U-option-changed-tp3374270p3375920.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-failsafe-plugin] Running integration test with its own profile
Stephen has provided another good and frequently-used way to make this work.
I would also suggest thinking about how the system admin will install
the package.
1) How sophisticated are they
2) Are their installation parameters that you might also want to pick up
- PayPal accounts, domains, e-mail addresses, database parameters, etc
3) Is there are difference between a new install and an upgrade
- Do databases have to be seeded or upgraded
4) Do you want to offer a package that includes the container
5) Do you need to support different Operating Systems
6) Do you want a standard system administration methodology that hides
the variance between releases
It may be the case that you want to provide an installer that can not
only handle the JNDI or Properties files but also reduces the system
administration involved in a new install or upgrade.
I hope that this helps.
Ron
On 08/02/2011 5:06 AM, Stephen Connolly wrote:
JNDI is not the only way.
Another good way is the .properties file on the classpath
This can work even better if you have default properties in your war,
so you do something like
public static final class Configuration {
private static final class ResourceHolder {
private static final Configuration INSTANCE = newConfiguration();
}
private final Properties config;
private Configuration() {
Properties defaultConfig = new Properties();
InputStream is = null;
try {
is = Configuration.class.getResource(Configuration.class.getSimpleName()
+ .properties); // load the defaults from the war
if (is != null) {
defaultConfig.load(is);
}
} catch (IOException e) {
// unable to load defaults, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
config = new Properties(defaultConfig);
InputStream is = null;
try {
is = Configuration.class.getResource(/ +
Configuration.class.getSimpleName() + .properties); // load the
customer config from the classpath
if (is != null) {
config.load(is);
}
} catch (IOException e) {
// unable to customer config, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
}
public static Configuration getInstance() {
return ResourceHolder.INSTANCE;
}
...
}
Obviously there's more you can do.
you put the default configuration resource in the same package as the
Configuration class.
the customer just puts the Configuration.properties in the root
package, so in JBOSS they just put their config in
$JBOSS_HOME/server//conf
in Tomcat 5.x it's $CATALINA/shared/classes I'd have to dig out the
location for 6.x and 7.x
etc.
If you go the properties route (and you could use an XML file or a
YAML file or whatever you want the config file to be in) I'd consider
implementing periodic scanning for changes or else tell customers they
need to restart the webapp to pick up the config changes.
-Stephen
On 8 February 2011 09:29, nodjenodje...@gmail.com wrote:
Hi Ron,
I've been reading quite some of your posts in the forum, and it actually
changed my mind about deployment configuration. Enlightening indeed.
I would now try to favor a single artifact deployment that could be
configured externally - say JNDi, this really makes sense.
That said, I don't want to compromise on the ease of deployment. Up to now
our customer just had to drop the war in it's app server, and that was it.
Plus, we were app server agnostic, we could deploy on whichever server
WITHOUT ANY configuration.
Trying to figure a way to combine both requirement, here is what I'm
imagining, and I'd like to hear your opinion on this, whether it makes sense
and if it's possible with JNDI.
1) If we use JNDI to configure the WAR on runtime, and if we want to have a
'dropping war only' deployment, the only option is to include all the needed
JNDI configuration IN the war.
Is this at all possible?
2) there need to be a way to select the adapted JNDI configuration: I'm
thinking environment variable here, it'd certainly be the simplest
configuration on top of installing the app server.
What do you think?
cheers
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3375605.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
Re: eclipse:eclipse maven 3.0.1 not adding dependency
Ok, thought this was fixed but when running tomcat inside eclipse the jar file is not found -- View this message in context: http://maven.40175.n5.nabble.com/eclipse-eclipse-maven-3-0-1-not-adding-dependency-tp3330388p3376077.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse:eclipse maven 3.0.1 not adding dependency
When looking in .classpath this is the differens classpathentry kind=var path=M2_REPO/net/sf/ehcache/ehcache/1.2.3/ehcache-1.2.3.jar/ classpathentry kind=src path=/ftc-client-2.1/ why is my own maven project added as src? -- View this message in context: http://maven.40175.n5.nabble.com/eclipse-eclipse-maven-3-0-1-not-adding-dependency-tp3330388p3376109.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
jspc-maven-plugin java 1.6
Hello, I can't compile my jsp in Java 1.6. Here is my pom : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.codehaus.mojo.jspc/groupId artifactIdjspc-maven-plugin/artifactId version2.0-sib-alpha-3/version executions execution idjspc/id goals goalcompile/goal /goals /execution /executions dependencies dependency groupIdorg.codehaus.mojo.jspc/groupId artifactIdjspc-compiler-tomcat6/artifactId version2.0-alpha-3/version /dependency /dependencies configuration source1.6/source target1.6/target ... /configuration /plugin In the console, I have the following errors : 8 févr. 2011 15:54:27 org.apache.jasper.compiler.JDTCompiler generateClass ATTENTION: Unknown source VM 1.6 ignored. 8 févr. 2011 15:54:27 org.apache.jasper.compiler.JDTCompiler generateClass ATTENTION: Unknown target VM 1.6 ignored. 8 févr. 2011 15:54:28 org.apache.jasper.JspC processFile INFO: Built File: \jsp\Controleur.jsp Thanks. Rémy -- View this message in context: http://maven.40175.n5.nabble.com/jspc-maven-plugin-java-1-6-tp3376142p3376142.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: jspc-maven-plugin java 1.6
Hi, I ran against the same issue - I changed both source and target to 1.5. The generated Java code does compile ok with 1.6 later. It seems to me that the JSPC plugin hasn't been updated in ages - version 1.4.6 is from October 2006. For instance, on the web site the link to browse the source code is broken - you need to use FishEye which is mentioned on the plugin collection home page (http://mojo.codehaus.org/source-repository.html). Karsten On Feb 8, 2011, at 17:13 , Rémy wrote: Hello, I can't compile my jsp in Java 1.6. Here is my pom : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.codehaus.mojo.jspc/groupId artifactIdjspc-maven-plugin/artifactId version2.0-sib-alpha-3/version executions execution idjspc/id goals goalcompile/goal /goals /execution /executions dependencies dependency groupIdorg.codehaus.mojo.jspc/groupId artifactIdjspc-compiler-tomcat6/artifactId version2.0-alpha-3/version /dependency /dependencies configuration source1.6/source target1.6/target ... /configuration /plugin In the console, I have the following errors : 8 févr. 2011 15:54:27 org.apache.jasper.compiler.JDTCompiler generateClass ATTENTION: Unknown source VM 1.6 ignored. 8 févr. 2011 15:54:27 org.apache.jasper.compiler.JDTCompiler generateClass ATTENTION: Unknown target VM 1.6 ignored. 8 févr. 2011 15:54:28 org.apache.jasper.JspC processFile INFO: Built File: \jsp\Controleur.jsp Thanks. Rémy -- View this message in context: http://maven.40175.n5.nabble.com/jspc-maven-plugin-java-1-6-tp3376142p3376142.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [maven-failsafe-plugin] Running integration test with its own profile
-Original Message-
From: nodje [mailto:nodje...@gmail.com]
I've been reading quite some of your posts in the forum, and it actually
changed my mind about deployment configuration. Enlightening indeed.
I would now try to favor a single artifact deployment that could be
configured externally - say JNDi, this really makes sense.
That said, I don't want to compromise on the ease of deployment. Up to now
our customer just had to drop the war in it's app server, and that was it.
Plus, we were app server agnostic, we could deploy on whichever server
WITHOUT ANY configuration.
Trying to figure a way to combine both requirement, here is what I'm
imagining, and I'd like to hear your opinion on this, whether it makes
sense
and if it's possible with JNDI.
1) If we use JNDI to configure the WAR on runtime, and if we want to have a
'dropping war only' deployment, the only option is to include all the
needed
JNDI configuration IN the war.
I don't know about jboss, but in plain Tomcat you can include in your war a
META-INF/context.xml file which will get copied over to
$CATALINA_BASE/conf/Catalina/localhost/nameofwebapp.xml the first time the
webapp is deployed. After that, any customization that might be made to that
file will persist. This has the added benefit that you don't need to include
things like your customer's passwords in your artifact.
2) there need to be a way to select the adapted JNDI configuration: I'm
thinking environment variable here, it'd certainly be the simplest
configuration on top of installing the app server.
The way I've done this has a few different pieces:
1) I use Spring to configure things. Spring is useful, but if you're not
already using it a custom coded solution like Stephen suggested might be easier.
2) Spring has a PropertyPlaceholderConfigurer that lets you refer to java
properties within an xml config file.
3) You can use a property reference within an import line to select whatever
custom settings you need, e.g.:
import resource=classpath:config/foo-${MYVAR}.xml/
4) We include a setenv.sh script [*1] that adds on -DMYVAR=${MYVAR} to
CATALINA_OPTS to get the environment variable setting turned into a java
property.
If you don't want any extra setup like this, the other option is to build a
feature into your webapp where the first access to it asks you which
configuration to use, and you write some code to load the right one. That can
be made to have a nice slick interface, but of course then you need to figure
out how to persist that choice.
eric
[*1] Actually, two scripts: a setenv.sh script that looks for anything named
${CATALINA_BASE}/setenv.sh, and setenv.sh.foo scripts that do the per-webapp
specific setup. Tomcat automatically sources in the setenv.sh script.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: jspc-maven-plugin java 1.6
Hi,
I don't use
org.codehaus.mojo:jspc-maven-plugin:1.4.6
but
org.codehaus.mojo.jspc:jspc-maven-plugin:2.0-sib-alpha-3
http://apache.multidist.com/tomcat/tomcat-6/v6.0.32/src/apache-tomcat-6.0.32-src.tar.gz
In file org.apache.jasper.compiler.JDTCompiler.java (line 285). I don't
understand !!!???
// Source JVM
if(ctxt.getOptions().getCompilerSourceVM() != null) {
String opt = ctxt.getOptions().getCompilerSourceVM();
if(opt.equals(1.1)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_1);
} else if(opt.equals(1.2)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_2);
} else if(opt.equals(1.3)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_3);
} else if(opt.equals(1.4)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_4);
} else if(opt.equals(1.5)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
} else if(opt.equals(1.6)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_6);
} else if(opt.equals(1.7)) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_7);
} else {
log.warn(Unknown source VM + opt + ignored.);
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
}
} else {
// Default to 1.5
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
}
Thanks.
Rémy
--
View this message in context:
http://maven.40175.n5.nabble.com/jspc-maven-plugin-java-1-6-tp3376142p3376357.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 support for org.apache.maven.user-settings
Use -s command-line argument? Vincent 2011/2/8 radai radai.rosenbl...@gmail.com Benjamin Bentmann wrote: There is no alternative but support for the system property can be restored if there's a valid use case for it. Benjamin we have a hudson CI server running builds for multiple (maven) projects, each with its own repositories. it would be nice to seperate the settings.xml between builds, and not lump them all together - for that i'd need to override the location of the settings file. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-tp3261146p3375624.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
