Hi Christian,
Thank you for all your time and effort.
> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT
In my tests, setting a version property in the POM still does not override
the version as it did in 3.3.9:
https://gist.github.com/ctruede
Hi Stephane,
Why can't we have the best of both worlds? Backwards compatibility, but
with a "stop sucking" flag which enables the new better behavior?
As I said previously, unless the previous behavior is preserved, all of my
communy's existing releases (hundreds of projects, thousands of tags) w
On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte wrote:
> Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > reviewing things. So current state of this is: "That's the behaviour
> > requested and tested during commiting to MNG-5971. Cannot override
> > properties? Really requested behaviour?
Am 08/15/16 um 20:49 schrieb David Hoffer:
> I will try to test with 3.2.2 but I can confirm that 3.2.5 does not have
> this behavior as that is our official build version for this application.
> I am trying to move to latest maven version and discovered this.
A project to reproduce this would be
I will try to test with 3.2.2 but I can confirm that 3.2.5 does not have
this behavior as that is our official build version for this application.
I am trying to move to latest maven version and discovered this.
Regards,
-Dave
On Mon, Aug 15, 2016 at 12:40 PM, Christian Schulte wrote:
> Am 08/1
Am 08/15/16 um 20:30 schrieb David Hoffer:
> I'm testing with build 110 and have found an error with one of our current
> builds (it works through 3.3.9). It's a bit of an odd-ball case.
>
> We have a child parent pom module that has several children if its own.
> One of those child modules uses
I'm testing with build 110 and have found an error with one of our current
builds (it works through 3.3.9). It's a bit of an odd-ball case.
We have a child parent pom module that has several children if its own.
One of those child modules uses a variable for the module name. E.g.
exchange
that works too
-D
On Mon, Aug 15, 2016 at 10:52 AM, KARR, DAVID wrote:
> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Monday, August 15, 2016 10:28 AM
> > To: Maven Users List
> > Subject: Re: Strategies for building Docker image for Tomcat with Maven-
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Monday, August 15, 2016 10:28 AM
> To: Maven Users List
> Subject: Re: Strategies for building Docker image for Tomcat with Maven-
> built webapps with docker-maven-plugin
>
> use destFileName
> http://maven.apache.o
use destFileName
http://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html#artifactItems
-D
On Mon, Aug 15, 2016 at 10:22 AM, KARR, DAVID wrote:
> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, August 10, 2016 9:15 AM
> > To: Maven U
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Wednesday, August 10, 2016 9:15 AM
> To: Maven Users List
> Subject: Re: Strategies for building Docker image for Tomcat with Maven-
> built webapps with docker-maven-plugin
>
> with optoinal set to true is your fri
AFAIK: jetty plugin is implemented only for the war deployment in-container
integration tests that jeff mentioned
There are maven-failsafe-plugin integration-test(s) such as multiple-summaries
which do not use jetty e.g.
/failsafe-plugin/src/it/multiple-summaries/target/failsafe-reports/failsa
On Mon, Aug 15, 2016 at 8:52 AM, Richard W. Adams wrote:
> Can someone clarify how to separate unit & integration tests in the Maven
> standard directory layout? The documentation says to use src/test/java for
> "test source," but src/it for "integration tests (primarily) for plugins."
>
> Does t
On Mon, Aug 15, 2016 at 8:35 AM, Richard W. Adams wrote:
> I've been taking a first look at documentation for the Failsafe plugin. It
> looked straightforward until I got to the part that discussed Jetty. I
> found the Jetty section confusing, as it seems to imply that Jetty is
> required to Fai
Can someone clarify how to separate unit & integration tests in the Maven
standard directory layout? The documentation says to use src/test/java for
"test source," but src/it for "integration tests (primarily) for plugins."
Does that mean we should use src/it only when developing a plugin?
Are
I've been taking a first look at documentation for the Failsafe plugin. It
looked straightforward until I got to the part that discussed Jetty. I
found the Jetty section confusing, as it seems to imply that Jetty is
required to Failsafe. I hope I'm misunderstanding it, and that Failsafe
can be
On 13/08/2016 01:47, Christian Schulte wrote:
> Am 08/12/16 um 15:58 schrieb Samuel Langlois:
> > Thanks for your answer Robert.
> > It is a bit more complicated than just being unable to override a
> property.
> > It's more that you can't change a dependencyManagement defined above by
> > overridi
I wish to define the distributionManagement values for all my projects in a
common parent pom.
parent pom.xml
${site.url}
file:///Users/macuser/Sites
${site.base.url}/${project.artifactId}
local
${site.url}
The effective pom f
Hi guys,
I have a long-running shutdown hook registered for the JVM(s) forked by
Surefire (org.apache.maven.plugins:maven-surefire-plugin:2.14). The hook
uploads all kinds of analysis results (collected during JUnit tests) to a
remote backend. All this upload can take up to a couple of minutes.
N
Hi,
Due to some special characters in my language, I need to embed font into PDF
file. I read a lot of pages about FOP, and I figured out I need
configuration file like this:
20 matches
Mail list logo
