> no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to
3.2.x, isn't it?
Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
That may be a change you want to have in mind, though I personally don't
care about JDK 5.
+1 indeed.
Cheers
Le mer. 29 oct. 2014
+1
29. Okt. 2014 03:24 skrev "Hervé BOUTEMY" følgende:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x, and I started to define som
+1 (non-binding)
Gary
On Tue, Oct 28, 2014 at 10:24 PM, Hervé BOUTEMY
wrote:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x, and
+1
On Wed, Oct 29, 2014 at 10:22 AM, Manfred Moser
wrote:
> +1 to that. Good idea imho..
>
> manfred
>
> Hervé BOUTEMY wrote on 28.10.2014 19:24:
>
> > we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> > which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
> >
> > I see why
+1 to that. Good idea imho..
manfred
Hervé BOUTEMY wrote on 28.10.2014 19:24:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x,
+1
same strange "Default target for maven-compiler-plugin version 3.1"JDK
requirement [1] as Maven Clean Plugin
we'll probably have something to do to improve this, because it seems updated
parent pom puts this for every plugin...
Regards,
Hervé
[1]
http://maven.apache.org/jxr-archives/jxr-L
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I started to define some backports I'd like to put in it [1]
But I don't see why we wou
Le lundi 27 octobre 2014 09:13:47 Karl Heinz Marbaise a écrit :
> Hi Michael,
>
> On 10/27/14 7:23 AM, Michael Osipov wrote:
> > Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise:
> >> Hi,
> >>
> >> We solved 10 issues:
> >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085&versio
see doxia-integration-tools DefaultSiteTool populateParentMenu(...) [1] and
populateModulesMenu(...) [2] called by getDecorationModel(...)
then getDecorationModel(...) is called from
AbstractSiteRenderingMojo.createSiteRenderingContext(...)
But looking at MPIR-279, I fear you're fighting again
+1
Regards,
Hervé
Le dimanche 26 octobre 2014 22:06:40 Michael Osipov a écrit :
> Hi,
>
> We solved 9 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325&projectId=117
> 61
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/browse/MSHARED-168?j
+1
notice that the JDK requirement is "Default target for maven-compiler-plugin
version 3.1" [1]: I don't know what it means nor why we have such result (first
time I see), but this is hard to understand
Regards,
Hervé
[1]
http://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/pl
GitHub user Tibor17 opened a pull request:
https://github.com/apache/maven-surefire/pull/63
[SUREFIRE-1053] Suppress warning message if file.encoding is set using
argLine
Fix for http://jira.codehaus.org/browse/SUREFIRE-1053
You can merge this pull request into a Git repository by
+1 (non binding), tested with my internal builds
On Tue, Oct 28, 2014 at 12:33 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> here my +1...
>
> Kind regards
> Karl Heinz Marbaise
> On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> We solved 6 issues:
>> http://jira.codehaus.org/secure/Re
+1
2014-10-26 22:06 GMT+01:00 Michael Osipov :
> Hi,
>
> We solved 9 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325&projectId=11761
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/browse/MSHARED-168?jql=project%20%3D%20MSHARED%20AND%20resol
Unfortunately filtering into tar/zip is broken
(http://jira.codehaus.org/browse/MASSEMBLY-722), and users of
filtering/line endings must use a previous version or wait for 2.5.1,
which will be released fairly soon.
Kristian
2014-10-27 5:50 GMT+01:00 Kristian Rosenvold :
> The Apache Maven team i
2014-10-28 17:54 GMT+01:00 Benson Margulies :
> Personally, I wonder why we don't merge them.
>
> Failsafe adds some lifestyle phase bindings and then changes some
> defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to
> have the extra executions with shifted defaults for things
Hi,
On 10/28/14 8:57 PM, Michael Osipov wrote:
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise:
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues
found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
versio
Hi,
i'm completely against merging maven-failsafe-plugin into the life cycle...
Running maven-failsafe-plugin within integration-test phase is one
solution...but sometimes you have other things to do for integration
tests
In pre-integration-test phase it's often the case to start an
app
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise:
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
version 2.5 to 39 in version 2.6...created an appropria
Hi,
here my +1...
Kind regards
Karl Heinz Marbaise
On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128&version=20685
There are still 2 issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
version 2.5 to 39 in version 2.6...created an appropriate jira for it
http://jira.codehaus.org/browse/MSHA
Hi,
I'd like to fix MPIR-279 and by applying the logic from above. I am
having a hard time to find that spot which actually evalutes the snippet
above.
Does someone know?
Thanks,
Michael
-
To unsubscribe, e-mail: dev-unsub
I wrote it before I had my apache commit bit.
there are pluses and minuses to combining them.
For instance it is harder to configure different defaults for goals when
they are the same plugin.
But in any case, for either path changing the bindings to make them easier
to use will still require ad
If my memory serves me right, the failsafe plugin was conceived/developed
by a third party -- perhaps codehaus. Then it was later adapted by Apache.
I think this is maybe why the two haven't been merged (yet).
Cheers,
Paul
On Tue, Oct 28, 2014 at 12:06 PM, Jeff Jensen <
jeffjen...@upstairstechno
>
> Integrating Failsafe in the same way as Surefire would be great for a lot
> of people I think.
I agree!
Personally, I wonder why we don't merge them.
I've wondered the same thing... is there a technical reason why it "won't"
or is difficult to make work?
On Tue, Oct 28, 2014 at 11:54 AM
Personally, I wonder why we don't merge them.
Failsafe adds some lifestyle phase bindings and then changes some
defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to
have the extra executions with shifted defaults for things like test
class names?
On Tue, Oct 28, 2014 at 11:50 A
@Paul: Yes I think so or we find a way more convenient in this moment.
@all: I think this shows perfectly why Failsafe should be integrated as
Surefire already is.
Oliver
Am 28.10.14 16:02, schrieb Paul Benedict:
Thanks. Now I know when to use this. For my situation, which is integration
tes
Thanks. Now I know when to use this. For my situation, which is integration
testing against an existing database, I don't need to setup an environment;
this explains why I never needed to use the plugin. There are other cases
the plugin will be valuable, but I wonder if this is why most others stic
The answer is on the index page of the failsafe plugin [1].
"If you use the Surefire Plugin for running tests..."
/Anders
[1] http://maven.apache.org/surefire/maven-failsafe-plugin/
On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict wrote:
> I have always used surefire for integration tests with a
I have always used surefire for integration tests with a Maven profile (to
activate them on demand since they are time consuming). What benefit am I
missing not using failsafe?
Cheers,
Paul
On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer
wrote:
> Hi,
>
> I see a lot of people using *Surefir
Hi,
I see a lot of people using *Surefire for intergation tests instead of
Failsafe*. I think the reason for this is that *Failsafe* is from my
perspective is *not integrated* in Maven *as is possible*.
While unittest (*Test.java) are executed if we place them in
|src/test/java| for integrat
31 matches
Mail list logo
