I may be missing something, but if all plugins implement this logic,
how it will be different from implicitly doing clean during each
build?
There is actually a huge difference
a.) yes, there are quite a few of such plugins which do not need this. Think
about sql-maven-plugin,
You cant do it dor surefire. Tests are sometimes done by reflection and you
cant ask a dep tree by test.in real world.
Le 7 sept. 2012 08:37, Mark Struberg strub...@yahoo.de a écrit :
I may be missing something, but if all plugins implement this logic,
how it will be different from implicitly
Hi Kristian!
How will this help if I delete an old file, one that simply hasnt been
changed?
This is applicable for all plugins which process all input files, like the
compiler plugin does.
In the case you mentioned we will first delete all *.class files created by the
previous run
Romain, we can perfectly do that!
We just need to check whether anything on the input classpath got changed
(jars, classes, etc).
Of course there are cases where you like to manually re-run tests over again.
For those cases we would need to introduce a 'force' flag somehow.
LieGrue,
strub
How? If i change a class in main/java but the test is done by reflection
youll miss it
Le 7 sept. 2012 08:46, Mark Struberg strub...@yahoo.de a écrit :
Romain, we can perfectly do that!
We just need to check whether anything on the input classpath got changed
(jars, classes, etc).
Of
I guess you missed me. I will not hand-pick which tests to run but run ALL
tests of a module if a SINGLE file got changed on the input
classpath/dependencies.
It's all or nothing to be on the safe side.
LieGrue,
strub
- Original Message -
From: Romain Manni-Bucau
The Maven team is pleased to announce the release of the Apache Maven
Install Plugin, version 2.4
The Install Plugin is used during the install phase to add artifact(s)
to the local repository. The Install Plugin uses the information in
the POM (groupId, artifactId, version) to determine the
Ok, not the best but sure
Le 7 sept. 2012 08:52, Mark Struberg strub...@yahoo.de a écrit :
I guess you missed me. I will not hand-pick which tests to run but run ALL
tests of a module if a SINGLE file got changed on the input
classpath/dependencies.
It's all or nothing to be on the safe
+1
2012/9/5 Olivier Lamy ol...@apache.org:
Hi,
I'd like to release Apache Maven Scm 1.8.
We fixed 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527version=18444
Staging repository:
https://repository.apache.org/content/repositories/maven-037/
Staging site:
It's just been fixed. I'll see if I can schedule a round of minor
bugfix releases late next week.
We're looking at compiler-plugin and surefire ( 2-3 minimal fixes
needed to make 2.12.4 next parent-pom version)
In the meantime you can update plexus-compiler-javac dependency in the
+1
Emmanuel
On Wed, Sep 5, 2012 at 2:46 PM, Olivier Lamy ol...@apache.org wrote:
Hi,
I'd like to release Apache Maven Scm 1.8.
We fixed 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527version=18444
Staging repository:
Hi Kristian,
that's awesome. And even with an easy workaround :D - Well, I'll see if
I want to tinker with our parent poms ;) or wait till the fix is released.
Again, thanks a lot...
Greetings
-Sascha-
Am 07.09.2012 10:14, schrieb Kristian Rosenvold:
It's just been fixed. I'll see if I can
Maybe I miss something but we don't have any associated jira entry for
reference in release notes neither core it test.
Do you have a bit of time for that ?
Thanks
--
Olivier
2012/9/3 jvan...@apache.org:
Author: jvanzyl
Date: Mon Sep 3 01:07:31 2012
New Revision: 1380105
URL:
Maybe this even should bump the version to v3.1?
/Anders
On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy ol...@apache.org wrote:
Maybe I miss something but we don't have any associated jira entry for
reference in release notes neither core it test.
Do you have a bit of time for that ?
Thanks
There are no visible user changes, so I don't think so. There aren't even any
changes to integrators unless they want to use take advantage of the changes.
On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:
Maybe this even should bump the version to v3.1?
/Anders
On Fri, Sep 7, 2012 at
I know. But there wasn't much visible change in v3.0 either. And I'm
thinking that it would be easier to communicate a dependency on Maven
3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
Version numbers are cheap. Why not bump and get some attention? :-)
/Anders
On Fri, Sep 7,
On 12-09-07 2:37 AM, Mark Struberg wrote:
I may be missing something, but if all plugins implement this
logic, how it will be different from implicitly doing clean
during each build?
There is actually a huge difference
a.) yes, there are quite a few of such plugins which do not need
this.
openjpa-maven-plugin is actually an interesting case. openjpa:enhance,
for example, will make it very hard or impossible for
maven-compiler-plugin to decide if it needs to rebuild anything or not.
No, not a problem at all. It detects if the classes are already implementing
PersistenceCapable
I have an enhancement I offer to contribute, if this mail is going to
the wrong place i apologize and ask Where should I send it?.
I have been looking for a good way to download an artifact from the
command line. dependency:get can put the file to my local repo or
optionally in a named file,
Hi Andreas,
The best way to handle this suggested improvement is to file a JIRA
ticket [1]. You're very welcome to discuss it here at the dev list,
but it always good to keep track of suggested changes in JIRA. Also,
important comments etc should be added to the ticket as well. This is
for future
20 matches
Mail list logo
