Has anyone stopped to ask any other projects (both apache and non-apache)
who have done what is being proposed here:
- How they found it?
- What did they do well?
- What did they do poorly?
- What pain points did they have?
- What would they do differently, if they had to do it again?
- What
I think it would be a very pragmatic move to simply leave the
maven-plugins project unmigrated
until we have established documentation and tool support to a level
where we're happy with whatever solution we choose.
I think the only really disasterous version we could end up with is
the one which
2012/9/6 Chris Graham chrisgw...@gmail.com:
The fact that a lot of people have said +1 and there are still discussions
around how to best set up a repo, means to me, that there is lots more room
for dissussion.
We have a hundred projects or more ;) A substantial group of people
here have been
+1 (non binding).
Willing to help. Git shows clear advantages over svn.
Le 5 sept. 2012 14:37, Garvin LeClaire garvin.lecla...@gmail.com a
écrit :
+1 (non-binding)
--
Regards,
Garvin LeClaire
garvin.lecla...@gmail.com
On Wed, Sep 5, 2012 at 8:33 AM, Anders Hammar and...@hammar.net
On Mon, 3 Sep 2012 22:29:36 +0200
Olivier Lamy ol...@apache.org 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=15112styleName=TextprojectId=11136
Staging repository:
On Wed, 5 Sep 2012 14:46:28 +0200
Olivier Lamy ol...@apache.org 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=10527version=18444
Staging repository:
+1
LieGrue,
strub
- Original Message -
From: Hervé BOUTEMY herve.bout...@free.fr
To: Maven Developers List dev@maven.apache.org
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
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
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
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.
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
+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
It's obviously a bug ;)
Kristian
2012/9/6 Sascha Vogt sascha.v...@gmail.com:
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
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
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
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
[+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:
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,
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
+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
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
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 strub...@yahoo.de a écrit :
Hi!
I had some
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 /
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 strub...@yahoo.de 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
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
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 rmannibu...@gmail.com
Ok so bad thread but the not stays valid. Triggering a clean is not
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
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
Answers inside.
LieGrue,
strub
- Original Message -
From: Anders Hammar and...@hammar.net
To: Maven Developers List dev@maven.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Thursday, September 6, 2012 9:51 PM
Subject: Re: [incremental build] Detect leftovers from a
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
2012/9/6 Jesse Glick jgl...@cloudbees.com:
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
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
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 the
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
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?
--
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.
36 matches
Mail list logo
