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
> To: Mark 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" 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 course there
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
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 (incl
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" a écrit :
> > I may be missing something, but if all plugins implement this logic,
> > how it will be different from implicitly doing "clea
> 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, openjpa-m
How will this help if I delete an old file, one that simply hasnt been
changed? Also, won't the list just grow infinitely ?
re executions; search for "a tribute to Linus Torvalds" in the
surefire source to find a really neat workaround that solves several
of your other problems..
Kristian
Den 6.
I may be missing something, but if all plugins implement this logic,
how it will be different from implicitly doing "clean" during each
build? Or, put differently, are there plugins that do not need to clean
their previous output to be absolutely sure they properly handle
incremental rebuilds?
--
Hi,
The vote has passed with the following result:
+1 (binding): Hervé Boutemy, Mark Struberg, Olivier Lamy
+1 (non binding): Tony Chemit
I will continue the release process.
Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---
same here
but I'm convinced git can help in some cases, like maintaining branches in
parallel
so I'm finally +1
Regards,
Hervé
Le jeudi 6 septembre 2012 20:53:39 Dennis Lundberg a écrit :
> +0
>
> I personally don't have the git knowledge to be able to help, but I'm
> interested in learning
github pull requests can be accepted even though we are ASF hosted, in
fact github will automatically close the corresponding
pull request as the commit is pushed back through the git mirroring
from asf->github.com/apache. I think github is extremely
important, but they have also managed to be smar
2012/9/6 Jesse Glick :
> On 09/05/2012 08:39 AM, Olivier Lamy wrote:
>>
>> I'm a bit curious to see if that will increase externals contributions.
>
>
> I think plain Git is only marginally more friendly for external contributors
> than Subversion. Yes you can create a local branch and update it ag
forget pulls from github.
Everyone can create a commit which is allegedly from you (email and name) and
others will have no whatever chance to verify that!
Now combine that with complex scenarios where you pull in more than a simple
change which you can track manually and you have the perfect w
Answers inside.
LieGrue,
strub
- Original Message -
> From: Anders Hammar
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Thursday, September 6, 2012 9:51 PM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
> What you talk about here is somet
Hi Vincent!
I've now looked at the code and it appears that this is a relatively easy
approach. It is still better than the current state.
It's kind of my bullet A. (invoke a 'clean') but extends this idea to the own
input sources.
This will work fine as long as you only strictly have default
What you talk about here is something that BuildContext should
provide, if we stay with that. There's a scanner for changes and a
deleteScanner.
The really tricky thing is when one source file has more than one
output/target file (like inner classes). The plugin needs some way of
knowing what targe
Hi,
the topic has been raised a long time ago, someone even wrote a plugin to
try to address this problem.
see http://maven-incremental-build.java.net/site/index.html
Vincent
2012/9/6 Romain Manni-Bucau
> Ok so bad thread but the not stays valid. Triggering a clean is not a
> solution for me
On 09/05/2012 08:39 AM, Olivier Lamy wrote:
I'm a bit curious to see if that will increase externals contributions.
I think plain Git is only marginally more friendly for external contributors than Subversion. Yes you can create a local branch and update it against trunk changes, but
you still
Ok so bad thread but the not stays valid. Triggering a clean is not a
solution for me
Le 6 sept. 2012 21:05, "Mark Struberg" a écrit :
> Hi Romain,
>
> Should have prefaced the baseline ;)
>
> I am now only focusing on plugin internal work inside a single maven pom
> module. See bullet B. in [1]
Hi Romain,
Should have prefaced the baseline ;)
I am now only focusing on plugin internal work inside a single maven pom
module. See bullet B. in [1]
The Maven Reactor code will trigger a 'clean' on the whole module if it detects
an external dependency change / pom change / profile change /
What about browsing the build tree to detect the dep modules which needs to
be built (avoid a real clean which can cost really too much to make incr
feature useful)? Can be done in parallel and can be pretty fast
Le 6 sept. 2012 20:53, "Mark Struberg" a écrit :
>
>
> Hi!
>
> I had some idea for d
I can help out a bit with documentation as I've helped authoring a guideline
over at the CouchDb and DeltaSpike projects (where we both use GIT)
http://wiki.apache.org/couchdb/Git_At_Apache_Guide
http://wiki.apache.org/couchdb/SVNvsGIT
Some of it needs updating. Especially since I consider the '
+0
I personally don't have the git knowledge to be able to help, but I'm
interested in learning the new technology.
In my view the tooling for git is not yet as good as for SVN, but it's
getting there.
We have two important things to look out for:
1. Support for git at the ASF, and documentatio
Hi!
I had some idea for detecting stale changes in maven which is pretty generic
The problem hits us if you compile BeanA and BeanA2 in a project where BeanA2
is using BeanA.
On a
$> mvn clean compile
you will get both BeanA.class and BeanA2.class in target/classes
Now delete BeanA.java
Cu
Can you list specific caches/leaks you see?
There are few caches that were specifically added to support use of
maven core inside long-lived processes, like m2e for example, where
ability to effectively execution build of the same project multiple
times is critical. This is an important usecase,
> [+1] Move to git scm
> [0] No interest
> [-1] don't move to git (please explain why)
+0.5
Sorry but I will be no help, I have little git experience except as an end user.
Wayne
-
To unsubscribe, e-mail: dev-unsubscr...@maven.a
The Maven team is pleased to announce the release of the Maven Shade Plugin,
version 2.0
Repackages the project classes together with their dependencies into a single
uber-jar, optionally renaming classes
or removing unused classes.
http://maven.apache.org/plugins/maven-shade-plugin/
You s
Hi,
The vote has passed with the following result :
+1 (binding): bimargulies, olamy, hboutemy, dkulp, mstruberg
I will promote the artifacts to the central repo.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For a
Hi,
As Kristian said, there's already a Zillion articles referencing it.
Personnally, (DVCS advantage) I really like being able to work
locally/offline, going back and forth in the history and branches, *very
quickly*. Having no difficulty to navigate between ideas without much
burden.
Being able t
It's obviously a bug ;)
Kristian
2012/9/6 Sascha Vogt :
> Hi all,
>
> last week I created http://jira.codehaus.org/browse/MCOMPILER-179 after
> a short discussion on maven-user.
>
> I bring this up on the dev list, as I think this is quite an issue
> because it makes compile errors really hard t
+1, I've got problems with caching in netbeans integration. Managed to
lower the long term memory usage significantly by resetting the
ProjectBuildingRequest on the MavenProject instance. That one was
holding quite a few Model instances, I''ve looked at the other caches
but I was not entirely clear
Hi all,
last week I created http://jira.codehaus.org/browse/MCOMPILER-179 after
a short discussion on maven-user.
I bring this up on the dev list, as I think this is quite an issue
because it makes compile errors really hard to spot (if one has a few
warnings one cannot get rid of).
So the quest
We have quite a few caches all over the place in our code base (and
some in plexus), quite a lot of them caching stuff based on this or
that class (or method).
Almost all of them leak class references, as far as I can understand
bloating permgen requirements (and hence memory usage) of maven.
Mos
And, as I commented in
https://cwiki.apache.org/confluence/display/MAVEN/Scheme+for+managing+Maven+source+in+Git,
I think we're perfectly happy just to keep the current module
structure. There may be some opportunities related to changing it, but
I think most of us can agree on just keeping up the
OMG, had a similar experience only recently.
We should incorporate a module which got created by another company. We
requested to get the source and so we got access to their SVN repo.
The first thing I saw was 35 directories with almost identical sources. And no,
that was not managed as SVN br
+1
LieGrue,
strub
- Original Message -
> From: Hervé BOUTEMY
> To: Maven Developers List
> Cc:
> Sent: Thursday, September 6, 2012 12:22 AM
> Subject: Re: [VOTE] Apache Maven Install plugin 2.4
>
> +1
>
> Hervé
>
> Le lundi 3 septembre 2012 22:29:36 Olivier Lamy a écrit :
>> Hi,
On Wed, 5 Sep 2012 14:46:28 +0200
Olivier Lamy wrote:
+1,
works fine to me.
thanks,
tony.
> Hi,
> I'd like to release Apache Maven Scm 1.8.
> We fixed 10 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18444
>
> Staging repository:
> https://repository.apac
On Mon, 3 Sep 2012 22:29:36 +0200
Olivier Lamy wrote:
+1,
tony.
> Hi,
> I'd like to release Maven Install plugin 2.4
>
> We fixed 5 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=15112&styleName=Text&projectId=11136
> Staging repository:
> https://repository.apache.org/con
38 matches
Mail list logo
