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
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, ...
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
*
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
+1
key looks fine, source builds fine, reports ok in my project.
LieGrue,
strub
- Original Message -
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Monday, August 27, 2012 9:53 AM
Subject: Re: [VOTE] Release Maven
+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:
+1
2012/8/24 Olivier Lamy ol...@apache.org:
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:
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
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 strub...@yahoo.de:
+1 for a common framework in maven-shared or similar.
+0 for auto detecting changed scenarios. If someone changes a profile or the
whole
+1
S.
On Sun, Aug 26, 2012 at 10:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=18715styleName=Html
There are still a couple of issues left in JIRA:
+1
2012/8/26 Hervé BOUTEMY herve.bout...@free.fr:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=18715styleName=Html
There are still a couple of issues left in JIRA:
+1
2012/8/25 Kristian Rosenvold kristian.rosenv...@gmail.com:
Hi,
We solved 11 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=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
+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
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 and...@hammar.net a
On Sat, 25 Aug 2012 00:11:55 +0200
Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
+1
works fine to me,
thanks,
tony.
Hi,
We solved 11 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=18704
2.12.3 should be slightly faster than previous versions,
+1
-Lukas
Hervé BOUTEMY wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=18715styleName=Html
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11142status=1
The assembly plugin example is perfectly fine if the dependencies are defined
in a dependency 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
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=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
+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 ol...@apache.org wrote:
Hi,
We solved 10 issues:
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.
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
On Mon, Aug 27, 2012 at 8:40 AM, Mark Struberg strub...@yahoo.de 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
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
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
+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=10541version=18
704
2.12.3 should be slightly faster than previous versions, but don't
expect too much.
There are still lots of
On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de 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
Benson
any chance of *forcing* the second iteration to re-jar with
forceCreationtrue/forceCreation
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#forceCreation
Martin
__
..place long-winded disclaimer here..
Date: Mon, 27 Aug
On 27 August 2012 18:09, Benson Margulies bimargul...@gmail.com wrote:
On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de 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
On 27 August 2012 19:10, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
On 27 August 2012 18:09, Benson Margulies bimargul...@gmail.com wrote:
On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg strub...@yahoo.de
wrote:
build1 and build 2 are different modules or different mvn
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 stephen.alan.conno...@gmail.com
To: Maven
On Mon, Aug 27, 2012 at 1:27 PM, Martin Gainty mgai...@hotmail.com wrote:
Benson
any chance of *forcing* the second iteration to re-jar with
forceCreationtrue/forceCreation
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#forceCreation
Yes, in my personal projects. That does
+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 ol...@apache.org wrote:
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18713
Staging
On Mon, 27 Aug 2012 15:13:21 +0200
Olivier Lamy ol...@apache.org 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=11430styleName=Htmlversion=18713
Staging repo:
+1 and thanks for the great teamwork!
Robert
Op Mon, 27 Aug 2012 21:36:20 +0200 schreef Tony Chemit
che...@codelutin.com:
On Mon, 27 Aug 2012 15:13:21 +0200
Olivier Lamy ol...@apache.org wrote:
+1 (none binding),
works fine to me.
well done guys,
tony.
Hi,
We solved 10 issues:
+1 (non-binding)
Regards Mirko
On Mon, Aug 27, 2012 at 6:57 PM, Hervé BOUTEMY herve.bout...@free.fr 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=10541version=18
704
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
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
+1 (non-binding) tested on one multi-module project.
Regards Mirko
On Sun, Aug 26, 2012 at 10:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=18715styleName=Html
There are still a couple of
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
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
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 strub...@yahoo.de wrote:
the shade plugin
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
On Mon, Aug 27, 2012 at 5:56 PM, Mark Struberg strub...@yahoo.de 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
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
Oh I think I'm slowly catching what you meant.
You were not talking about dependency but the configurationartifactSet
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
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
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
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
-
48 matches
Mail list logo
