I wonder should we pull mrm-maven-plugin into apache and use that instead
On 28 August 2012 02:11, Brian Fox wrote:
> There are lots of tests that are trying to use file based repositories
> for certain conditions. This is why in 2.0.9 I had added the
> external:* :
>
> external:* matches all re
Hi,
The vote has passed with the following result :
+1 (binding): Olivier Lamy, Hervé Boutemy, Kristian Rosenvold
+1 (non binding): Tony Chemit, Mirko Friedenhagen
I will promote the artifacts to the central repo.
Kristian
-
To
I definitely use external:*
I didn't even notice the book doesn't.
On Aug 27, 2012, at 9:11 PM, Brian Fox wrote:
> There are lots of tests that are trying to use file based repositories
> for certain conditions. This is why in 2.0.9 I had added the
> external:* :
>
> external:* matches all rep
There are lots of tests that are trying to use file based repositories
for certain conditions. This is why in 2.0.9 I had added the
external:* :
external:* matches all repositories except those using localhost or
file based repositories. This is used in conjunction with a repository
manager when y
Oh I think I'm slowly catching what you meant.
You were not talking about but the
inside the maven-shade-plugin declaration, right?
In that case A.) doesn't kick in, true. Guess the easiest way would be to keep
the original jar somewhere as you already proposed.
LieGrue,
strub
- Orig
Hi Benson!
> However, a dependency *has* changed,
Yea, thanks for the example! I think I kind of know what you mean now (I hope).
That is why I introduced point A.) in the WiKi description [1].
"If any of those tests indicate a change then we force a 'clean' on the module
and on all depending
On Mon, Aug 27, 2012 at 5:56 PM, Mark Struberg wrote:
> It's a chain.
> The maven-compiler-plugin sees that there are stale sources or changed
> dependencies and compiles the sources.
> The jar plugin sees that there are changed classes which have a newer
> timestamp than the jar file, so it cre
It's a chain.
The maven-compiler-plugin sees that there are stale sources or changed
dependencies and compiles the sources.
The jar plugin sees that there are changed classes which have a newer timestamp
than the jar file, so it creates the jar again.
The maven-shade-plugin will see the md5 of t
Mark, I don't see how this helps. If the jar plugin hasn't rebuilt the
jar, the shade plugin can't rebuild the jar, even if, for other
reasons, it needs to. It has knowledge that the jar plugin lacks.
On Mon, Aug 27, 2012 at 4:04 PM, Mark Struberg wrote:
> the shade plugin would just need to st
There are some plugins which should not act incremental by default. Mainly the
test stuff. People would not like it if they invoke
$> mvn test
and their test would not run because they already did run some time before and
no code/dependency changed since.
Thus I propose to introduce 2 new Mav
I've wrote up some stuff in our Wiki:
https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds
Feel free to add more info/ideas.
LieGrue,
strub
PS: a small test app can be found on https://github.com/struberg/maventest
Try this with the latest compiler plugin 2.6-SNAPSHOT from trunk
+1 (non-binding) tested on one multi-module project.
Regards Mirko
On Sun, Aug 26, 2012 at 10:11 PM, Hervé BOUTEMY wrote:
> Hi,
>
> We solved 5 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142&version=18715&styleName=Html
>
> There are still a couple of issues left in J
the shade plugin would just need to store a local status file with the md5 of
the created result.
Or add the info to the manifest as you proposed.
The main point is that this should be up to the maven-shade-plugin, as it is
the only one who knows when to repeat this step.
LieGrue,
strub
>__
The issue (for benson) is when the shade plugin modifies after the class
files have changed... the jar plugin will currently skip recreating the
jar, and he has no way of knowing if the jar file has been shaded or
not the solution is to have the manifest.mf include an entry that
indicates creat
+1 (non-binding)
Regards Mirko
On Mon, Aug 27, 2012 at 6:57 PM, Hervé BOUTEMY wrote:
> +1
>
> Hervé
>
> Le samedi 25 août 2012 00:11:55 Kristian Rosenvold a écrit :
>> Hi,
>>
>> We solved 11 issues:
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=18
>> 704
>>
>> 2.1
+1 and thanks for the great teamwork!
Robert
Op Mon, 27 Aug 2012 21:36:20 +0200 schreef Tony Chemit
:
On Mon, 27 Aug 2012 15:13:21 +0200
Olivier Lamy wrote:
+1 (none binding),
works fine to me.
well done guys,
tony.
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNot
On Mon, 27 Aug 2012 15:13:21 +0200
Olivier Lamy wrote:
+1 (none binding),
works fine to me.
well done guys,
tony.
> Hi,
>
> We solved 10 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18713
>
> Staging repo:
> https://repository.apache.org/
+1 (non-binding). Tested this with one of my multi-module projects, looks good.
Regards Mirko
On Mon, Aug 27, 2012 at 3:13 PM, Olivier Lamy wrote:
> Hi,
>
> We solved 10 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18713
>
> Staging repo:
> ht
On Mon, Aug 27, 2012 at 1:27 PM, Martin Gainty wrote:
>
> Benson
>
> any chance of *forcing* the second iteration to re-jar with
> true
> http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#forceCreation
Yes, in my personal projects. That does not solve the real problem, in
my opinio
Not sure if I get the problem.
The timestamp of the input files is still < than the timestamp of the jar file.
Regardless if it later got modified by the shade-plugin or not.
LieGrue,
strub
>
> From: Stephen Connolly
>To: Maven Developers List
>Cc: Mark Str
On 27 August 2012 19:10, Stephen Connolly
wrote:
> On 27 August 2012 18:09, Benson Margulies wrote:
>
>> On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg
>> wrote:
>> > build1 and build 2 are different modules or different mvn invocations
>> with some time inbetween?
>> >
>> > Of course we will n
On 27 August 2012 18:09, Benson Margulies wrote:
> On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg wrote:
> > build1 and build 2 are different modules or different mvn invocations
> with some time inbetween?
> >
> > Of course we will need to test all plugins to behave incremental like!
> Means t
Benson
any chance of *forcing* the second iteration to re-jar with
true
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#forceCreation
Martin
__
..place long-winded disclaimer here..
> Date: Mon, 27 Aug 2012 13:09:59 -0400
> Subject
On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg wrote:
> build1 and build 2 are different modules or different mvn invocations with
> some time inbetween?
>
> Of course we will need to test all plugins to behave incremental like! Means
> the maven-shade-plugin should check itself whether it need
+1
Hervé
Le samedi 25 août 2012 00:11:55 Kristian Rosenvold a écrit :
> Hi,
>
> We solved 11 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=18
> 704
>
> 2.12.3 should be slightly faster than previous versions, but don't
> expect too much.
>
> There are stil
build1 and build 2 are different modules or different mvn invocations with some
time inbetween?
Of course we will need to test all plugins to behave incremental like! Means
the maven-shade-plugin should check itself whether it needs shading or not at
all.
But the worst thing happening would be
I've been thinking about my abortive attempt to deal with multiple
builds colliding over the dependency-reduced-pom.xml. My attempt was
to move the thing into 'target', but that blew up relative pathnames.
Here's another plan: give the thing a uuid-based name, instead. Can
anyone think of a proble
On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg wrote:
> We might implement this by storing the list of all activated profiles + all
> resolved environment properties in a file in target/ somewhere.
> That would be part of a.) in my previous mail to Romain.
How about the situation with shade?
Bu
GitHub user jsenko opened a pull request:
https://github.com/apache/maven-enforcer/pull/2
[MENFORCER-138] Rule to ban all transitive dependencies
In some projects it's desirable to have all dependencies specified in pom.
It would be nice to have an enforcer rule that would ban all t
Hi,
The Apache Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.5.1
The dependency plugin provides the capability to manipulate artifacts.
It can copy and/or unpack artifacts from local or remote repositories
to a specified location.
http://maven.apache.org/
+1!!!
thanks,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 27, 2012 at 3:13 PM, Olivier Lamy wrote:
> Hi,
>
> We solved 10 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?proj
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18713
Staging repo:
https://repository.apache.org/content/repositories/maven-015/
Staging site:
http://maven.apache.org/skins/maven-fluido-skin-1.3.0/
Guide to testing staged release
We might implement this by storing the list of all activated profiles + all
resolved environment properties in a file in target/ somewhere.
That would be part of a.) in my previous mail to Romain.
LieGrue,
strub
- Original Message -
> From: Anders Hammar
> To: Maven Developers List ;
The assembly plugin example is perfectly fine if the dependencies are defined
in a section. If a SNAPSHOT dependency did change, then it will
get a different md5. Of course if plugins resolve some dependencies
programmatically, then those cases will not work easily. But that is considered
bad
+1
-Lukas
Hervé BOUTEMY wrote:
> Hi,
>
> We solved 5 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142&version=18715&styleName=Html
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11142&status=
On Sat, 25 Aug 2012 00:11:55 +0200
Kristian Rosenvold wrote:
+1
works fine to me,
thanks,
tony.
> Hi,
>
> We solved 11 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=18704
>
> 2.12.3 should be slightly faster than previous versions, but don't
> expect to
Hi,
The full invremental is great but not always possible (think to assembly
plugin, some case xill be very hard to handle in snapshot mode i guess)
Maybe it is time to get a maven daemon to help to be able to store
information?
- Romain
Le 27 août 2012 12:24, "Anders Hammar" a écrit :
> > +0
> +0 for auto detecting changed scenarios. If someone changes a profile or the
> whole pom, then I'd expect he invokes a clean manually. We have to document
> this expectation of course.
What do others think of this? I'm thinking it would be awesome (but
maybe difficult) if plugins could determ
+1
2012/8/25 Kristian Rosenvold :
> Hi,
>
> We solved 11 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=18704
>
> 2.12.3 should be slightly faster than previous versions, but don't
> expect too much.
>
> There are still lots of issues left in JIRA:
> http://jir
+1
2012/8/26 Hervé BOUTEMY :
> Hi,
>
> We solved 5 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142&version=18715&styleName=Html
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11142&status=1
>
> St
+1
S.
On Sun, Aug 26, 2012 at 10:11 PM, Hervé BOUTEMY wrote:
> Hi,
>
> We solved 5 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142&version=18715&styleName=Html
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?re
agree for common framework. Maybe using the existing
o.s.p.b.i.BuildContext (or an other new one)
others inline.
2012/8/27 Mark Struberg :
> +1 for a common framework in maven-shared or similar.
>
> +0 for auto detecting changed scenarios. If someone changes a profile or the
> whole pom, then I'd
Hi,
The vote has passed with the following result.
+1 (binding): Stephen Connolly, Kristian Rosenvold, Stephan Nicoll,
Hervé Boutemy, Olivier Lamy
+1 (non binding): Keith Sader, Tony Chemit
I will continue the release process.
Thanks!
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitt
+1
2012/8/24 Olivier Lamy :
> Hi,
> I'd like to release Maven Dependency Plugin 2.5.1.
> This release contains a regression issue fix and a perf improvement
> (https://jira.codehaus.org/browse/MDEP/fixforversion/18718)
>
> Staging repository:
> https://repository.apache.org/content/repositories/ma
+1 for a common framework in maven-shared or similar.
+0 for auto detecting changed scenarios. If someone changes a profile or the
whole pom, then I'd expect he invokes a clean manually. We have to document
this expectation of course.
LieGrue,
strub
- Original Message -
> From: And
+1
key looks fine, source builds fine, reports ok in my project.
LieGrue,
strub
- Original Message -
> From: Stephen Connolly
> To: Maven Developers List
> Cc:
> Sent: Monday, August 27, 2012 9:53 AM
> Subject: Re: [VOTE] Release Maven Project Info Reports Plugin version 2.5.1
>
>
> I already started tweaking the m-compiler-plugin and found quite scary
> issues. There is e.g. MCOMPILER-21 (open since 2005) which prevents
> incremental build and would kick in in your scenario.
This is interesting. I've looked a bit at Mojo's JAXB plugin in the
context of detecting stale ge
1. Source distribution builds with ITs passing [OK]
2. RAT report [OK]
There is only one file missing a header in the RAT report, and I am willing
to bet that the file format for that file does not support comments.
+1 from me
-Stephen
*
Summa
Hi Olivier!
I already started tweaking the m-compiler-plugin and found quite scary issues.
There is e.g. MCOMPILER-21 (open since 2005) which prevents incremental build
and would kick in in your scenario.
I talked about 2 scenarios
a.) all phases >= package, e.g. mvn verify, mvn install, ...
Hi,
Sounds good idea trying to improve that.
My question: on what is based the md5 calculation ?
If people don't use 'install' but only 'test' (perso I use that to
avoid too much io with jar creation etc..), so in such case we cannot
do md5 calculation on the produced artifact.
2012/8/26 Mark Stru
50 matches
Mail list logo
