That's a tricky one.
1st: this is probably already optimized away by the XML reader.
2nd:what about this configuration
someurl_handed_over_to_scm
In this case we really must get rid of the whitespaces, otherwise we would
probably create lots of issues with plugins.
LieGrue,
strub
+1
LieGrue,
strub
- Original Message -
> From: Stephane Nicoll
> To: Maven Developers List
> Cc:
> Sent: Friday, November 16, 2012 5:58 PM
> Subject: Re: [VOTE] Maven Compiler Plugin 3.0 and maven-shared-incremental 1.0
>
> +1
>
> S.
>
>
> On Fri, Nov 16, 2012 at 12:36 AM, Olivi
Hi folks!
I would like to also make the resource plugin incremental aware. That would
already help alot.
LieGrue,
strub
- Original Message -
> From: Anders Hammar
> To: Maven Developers List
> Cc:
> Sent: Monday, November 12, 2012 8:22 AM
> Subject: Re: Maven Compiler 3.0 plugin r
+1
LieGrue,
strub
- Original Message -
> From: Mark Hobson
> To: Maven Developers List
> Cc:
> Sent: Thursday, November 1, 2012 11:04 PM
> Subject: [VOTE] Release Maven SCM Publish Plugin version 1.0-beta-2
>
> Hi,
>
>
> Note that this release is dependent upon the maven-scm-1.8.
+1
LieGrue,
strub
- Original Message -
> From: Hervé BOUTEMY
> To: Maven Developers List
> Cc:
> Sent: Friday, November 2, 2012 12:05 AM
> Subject: Re: [VOTE] Release Maven SCM version 1.8.1
>
> +1
>
> Regards,
>
> Hervé
>
> Le jeudi 1 novembre 2012 20:35:50 Mark Hobson a écrit
+1
LieGrue,
strub
- Original Message -
> From: Dennis Lundberg
> To: Maven Developers List
> Cc:
> Sent: Thursday, November 1, 2012 11:14 PM
> Subject: [VOTE] Release ASF Parent POM version 12
>
> Hi,
>
> Changes since the last release:
> http://svn.apache.org/viewvc/maven/pom/tags
+1
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List
> Cc:
> Sent: Monday, October 29, 2012 3:39 PM
> Subject: [VOTE] Maven Shared Utils 0.1, Take 2
>
> Hi,
>
> This is the first version of maven-shared-utils, a replacement for
> plexus-util
+1
LieGrue,
strub
- Original Message -
> From: Benson Margulies
> To: Maven Developers List
> Cc:
> Sent: Saturday, October 27, 2012 11:30 PM
> Subject: Re: [VOTE] Release Maven Parent POM version 23
>
> My vote: +1
>
> On Sat, Oct 27, 2012 at 5:29 PM, Benson Margulies
> wrote:
y other thought and I guess you're right: now that we've
> completely decoupled it from plexus-utils let's just start over with the
> @since.
>
> -Robert
>
> Op Sun, 21 Oct 2012 18:50:01 +0200 schreef Mark Struberg
> :
>
>> puh that's muddy.
&
looking at a compatible replacement
>> in a different package that can be used as a replacement for 90-95% of the
>> use cases.
>>
>> I think we should release "0.9" now or at least very soon, and
> just give
>> the Xpp3Dom stuff a couple of extra we
Guys, you rock!
I also like to add my thanks to Stephen as he started the
plexus-utils-commons-bridge over in our sandbox. Without this work we would not
have been able to do this so fast. Also a thanks to all guys who helped
importing the stuff they wrote into this module.
LieGrue,
strub
sure not a show stopper. We just
need to document it in a FAQ.
I gonna refine the IT and check it in in the next days.
LieGrue,
strub
- Original Message -
> From: Mark Struberg
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 5:56 PM
> Subje
: Benson Margulies
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Thursday, October 11, 2012 5:16 PM
> Subject: Re: SLF4J integration
>
> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg wrote:
>> Benson, it's a pity that this happened to you, an
b
- Original Message -
> From: Benson Margulies
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Thursday, October 11, 2012 2:14 PM
> Subject: Re: SLF4J integration
>
> 1. I have an example of something. I don't quite know what.
>
> I wen
ployStrategy.java#L141
>
>
> Thanks,
> ~t~
>
>
> On Thu, Oct 11, 2012 at 1:26 PM, ceki wrote:
>
>> On 11.10.2012 12:43, Mark Struberg wrote:
>>
>> > ceki, really, this is perfect example why no container uses
>> > commons-logging anymore.
om: ceki
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 1:26 PM
> Subject: Re: SLF4J integration
>
> On 11.10.2012 12:43, Mark Struberg wrote:
>
>> ceki, really, this is perfect example why no container uses
>> commons-logging anymore. Do y
- Original Message -
> From: ceki
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 12:25 PM
> Subject: Re: SLF4J integration
>
> On 11.10.2012 11:18, Mark Struberg wrote:
>> Oh I missed one more constellation
>>
>> a pl
Oh I missed one more constellation
a plugin could have slf4j-1.5.x + a logging backend we do not know of.
I hope such things dont often exist, but in theory it could happen.
For all of those cases we need isolation.
LieGrue,
strub
- Original Message -
> From: Mark Struberg
&
j dependency" in a plugin, are you
> talking about dependency to slf4j-api or an slf4j impl?
>
> /Anders
>
> On Thu, Oct 11, 2012 at 10:16 AM, ceki wrote:
>> On 11.10.2012 08:37, Mark Struberg wrote:
>>
>> Hi Mark,
>>
>>> Hi Ceki
we need to revert/fix the log commit anyway for now as we don't yet have the
classloader isolation code.
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 10:19 AM
> Subject: Re: Flipping Maven Core to Git
aud Héritier
> To: Maven Developers List
> Cc: Mark Struberg
> Sent: Thursday, October 11, 2012 9:32 AM
> Subject: Re: Flipping Maven Core to Git
>
> Like Stephen I would prefer to keep them separated.
> They have a different lifecycle as we should be (we are ?) able to run ITs
I guess it affects the repo layout, isn't?
/maven-core/...
/maven-core-its/...
Or how did you intend to set this up?
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Thursday, Octo
+1
Der are quite some utility methods which return null and others which return
empty strings or Collections.EMPTY. But we are not consistent in what we do.
jsr-305 would at least make it obvious.
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers
Kristian, wait a bit.
What if we first merge the 2 repos into 1 git repo?
Imo maven-core and the ITs must fit together! Having the ITs in a separate repo
will make people forget about them.
Also for a maven-core release it isn't a problem if the ITs get tagged. I
actually would even really app
any plugin to use slf4j right now. All it needs to do
is to funnel it into our own maven logging api. We could e.g. provide a
slf4j-maven-logging backend so users could use it even more easily.
LieGrue,
strub
- Original Message -
> From: ceki
> To: Maven Developers L
Hi!
Here are a few basic observations about slf4j.
slf4j really rocks for end user applications, but when it comes to deep
container core stuff you must take care about classloader clashes much more
than within an end-user project. We just don't know what a user defined in his
sections…
If we
+1
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Tuesday, October 9, 2012 11:20 AM
> Subject: [VOTE] Apache Maven Sources plugin 2.3
>
> Hi,
> I'd like to release Maven Sources Plugin 2.3.
> We fix 1 blocking issue which prevent
I don't get it. Having shared/maven-dependency-tree hiding all that stuff will
perfectly allow us to switch to another dependency resolution approach without
having to change anything. Having maven plugins depend on aether directly is
what creates tons of problems as those plugins would not work
>>>
>>> I'm not sure this is feasible, but could we somehow fork 1.6
> support
>>> in a module and just ditch 1.5 entirely at some point in the future ?
>>>
>>> Kristian
>>>
>>>
>>> 2012/9/28 John Casey :
>&g
+1
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List
> Cc:
> Sent: Friday, September 28, 2012 10:11 PM
> Subject: Re: [VOTE] Release Maven WAR Plugin version 2.3
>
> +1
>
>
> 2012/9/28 Olivier Lamy :
>> +1
>>
>> 2012/9/28 Dennis Lundber
+1
Imo this comes hand in hand with moving maven-core to 1.6 as well and a version
bump to mvn-3.2.0 or even mvn-3.5.0
We might create a documentation page about "Strategies for targeting older Java
versions" which outlines the animal-sniffer, etc
LieGrue,
strub
- Original Message
oh, then that is another problem. The problems I see with the parallel build is
reproducible locally.
Will move back to an old commons-io which is java4
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List ; Mark Struberg
>
>
Can we switch this build to non-parallel?
It just doesn't build with -T3. Thus also all follow-up projects fail to build
(maven-plugins-ITs)
Of course it would be better to fix that, but it seems to be pretty deeply
buried in the code.
LieGrue,
strub
- Original Message -
> From: A
+1
LieGrue,
strub
- Original Message -
> From: Hervé BOUTEMY
> To: Maven Developers List
> Cc:
> Sent: Wednesday, September 26, 2012 1:04 AM
> Subject: Re: [VOTE] Release maven plugin testing 1.3 & 2.1 (Take 2)
>
> +1
>
> Hervé
>
> Le lundi 24 septembre 2012 19:07:33 Kristian Ros
Kristian, just a minor note:
I did some ugly hacks to get the SCM TCK running for maven-scm-providers-git by
checking in a unpacked git repo into our SVN.
Did that translate nicely to GIT? Did you run a build with all ITs yet?
If not, then I'll check it later today.
txs and LieGrue,
strub
runOnIncremental sounds interesting.
Is this only for m2e or could this be useful for standard maven as well? If so,
I'd rather enhance the plugin.xml
LieGrue,
strub
- Original Message -
> From: Benson Margulies
> To: Maven Developers List
> Cc:
> Sent: Sunday, September 23, 2012 7
call it bad luck, but SVN is really the only SCM that does NOT use it I think ;)
LieGrue,
strub
- Original Message -
> From: Stephen Connolly
> To: Maven Developers List
> Cc:
> Sent: Friday, September 21, 2012 3:34 PM
> Subject: Re: Scm, Surefire, Wagon migrate to git (please check
t; >>
>>> >> The authorative repo is correct, but there may be some clones
> out
>>> >> there that are unaware of the failed release and the moved
> tag.
>>> >>
>>> >> I still think the benefit of moving the tag > just tagging
> lo
; From: Stephen Connolly
>To: Maven Developers List ; Mark Struberg
>
>Sent: Friday, September 21, 2012 2:04 PM
>Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was Plan for
>git migration]
>
>
>On 21 September 2012 13:00, Mark Struberg wrote:
>
>If
If I remember correctly the section has also a element.
This stuff was initially used for CVS which is pretty similar to GIT from a
user pov when it comes to branches and tags.
It has not been used for a long time though and I'm not sure if some SVN
'fixes' (dynamic url change, anyone?) cras
ote tool could also just push the local
> release tag to the repo, so I may be complicating things.?
>
> Kristian
>
>
>
>
>
>
>
>
>
>
>
> 2012/9/20 Mark Struberg :
>> Hi folks!
>>
>> The problem is the rollback.
>> In Delt
gle-guice in case it's already been fixed
> in trunk.
>
> --
> Cheers, Stuart
>
> On 21 Sep 2012, at 08:41, Mark Struberg wrote:
>
>>
>>
>> Hi!
>>
>> I need to debug through sisu-guice as I'm searching for a bug.
>>
&g
Hi!
I need to debug through sisu-guice as I'm searching for a bug.
Problem I face is that the source and binary of e.g.
com.google.inject.internal.MembersInjectorImpl
doesn't fit together (debugger hitting empty lines and is completely
off-method).
I already dropped the jars off my loc
Hi folks!
The problem is the rollback.
In DeltaSpike we do _not_ push now. deleting a tag on one repo is not a
problem, but you would crash all downstream clones as re-trying a release is
basically a history rewrite.
In DeltaSpike I do the release locally and push the tag + release branch to my
ySnapshotScanner.java
> test/java/org/apache/maven/shared/utils/io/DirectorySnapshotScannerTest.java
>
>& quot;Listing"?
>
> Le vendredi 14 septembre 2012 20:04:23 Anders Hammar a écrit :
>> Yes, "Snapshot" is not good. "PointInTime"?
>>
Hi!
If anyone has a better name for the 'DirectorySnapshotScanner' I would be happy
to rename it.
What it makes: it takes a snapshot capture of a directory structure and
compares it with another snapshot capture of that directory to calculate a diff
(files added/removed)
Not sure though if t
Yes, that works fine already. I've already used it for releasing Apache
DeltaSpike where we do not have the pom directly under the root folder but in a
./deltaspike/ folder (in parallel to docs, etc)
LieGrue,
strub
>
> From: Olivier Lamy
>To: Maven Developer
I'm +1 for keep em.
Reason is that this allows quicker digging for some history info. I'm e.g. not
sure if moves and stuff gets fully resolved with git-svn. Structure changes are
another candidate of loosing history in git-svn (that would hit the maven-3
module).
LieGrue,
strub
- Orig
well, for gods sake and (and for the peace of the bits on my ssd) I move my
vote to +1 as well
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Tuesday, September 11, 2012 2:13 PM
> Subjec
+0 with a long explanation
I'm really a friend of GIT in general. As some might remember I am even the guy
who kicked off the GIT madness in maven land back in 2007 in the first place
[1].
But I'm also a friend of using the right tool for the right job.
GIT is great for projects which are no
FYI: I'm working on this.
Seems I broke the include/exclude rules due my incremental build fixes in
combination with the fix for MCOMPILER-120.
LieGrue,
strub
- Original Message -
> From: Apache Jenkins Server
> To: notificati...@maven.apache.org; strub...@apache.org;
> herve.bou
> Absolutely. In light of commit r1380105, the next step is for you
> (Maven folks) to formulate a policy for swapping out logging
> back-ends.
Well that is what this is all about. And we have this solution available in
Maven since 2004. There is already a logging facade which is widely used:
y grabbing the
stdout and redirecting that to the plexus logger.
LieGrue,
strub
- Original Message -
> From: Benson Margulies
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Sunday, September 9, 2012 9:44 PM
> Subject: Re: SLF4J implementation [was R
ning the integration tests for Maven and the
> integration tests for all the plugins if there's going to be an issue. I
> believe the Ceki has probably run into every integration scenario imaginable
> over the last 10 years and he'll help us if required.
>>>
>&
suasive reason to do it anyway.
>>
>>
>>
>>>
>>>
>>> I've seen such problems in the wild.
>>> This is nothing which slf4j does wrong - it's just not really
> possible to do it 100% right.
>>>
>>> We im
ven-embedder/
> maven-embedder/src/main/java/org/apache/maven/cli/]
>
> On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg wrote:
>> sorry, didn't catch this reply earlier.
>>
>> I see, but then we are back to my original problem. Once you add e.g.
> log4j-slf4j bi
- Original Message -
> From: Jason van Zyl
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Sunday, September 9, 2012 4:22 PM
> Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in
> /maven/maven-3/trunk: ./ apache-maven/
> maven-core
_
> From: Jason van Zyl
>To: Maven Developers List ; Mark Struberg
>
>Sent: Sunday, September 9, 2012 4:06 PM
>Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in
>/maven/maven-3/trunk: ./ apache-maven/
>maven-core/src/main/java/org/apa
the maven
folder and it would get picked up automatically without having to touch any
source.
wdyt?
LieGrue,
strub
- Original Message -
> From: Mark Struberg
> To: Maven Developers List
> Cc:
> Sent: Sunday, September 9, 2012 10:17 AM
> Subject: Re: SLF4J impleme
Can you again please explain me what the benefit of the SLF4J abstraction over
the already used plexus.Logger is? Both are just logging facades.
I mean you can still use whatever bridge underneath plexus.Logger. And
plexus.Logger is exclusively used by Maven, so we have a guarantee to not
intro
t; From: Igor Fedorenko
> To: dev@maven.apache.org
> Cc:
> Sent: Friday, September 7, 2012 11:44 PM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
>
>
> On 12-09-07 2:37 AM, Mark Struberg wrote:
>>> I may be missing something, but if a
t; To: Mark Struberg ; Maven Developers List
>
> Cc:
> Sent: Friday, September 7, 2012 8:48 AM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
> How? If i change a class in main/java but the test is done by reflection
> youll miss it
> Le 7 s
rue,
strub
>
> From: Romain Manni-Bucau
>To: Mark Struberg ; Maven Developers List
>
>Sent: Friday, September 7, 2012 8:41 AM
>Subject: Re: [incremental build] Detect leftovers from a previous build
>
>
>You cant do it dor surefire. T
; surefire source to find a really neat workaround that solves several
> of your other problems..
>
> Kristian
>
> Den 6. sep. 2012 kl. 20:53 skrev Mark Struberg :
>
>>
>>
>> Hi!
>>
>> I had some idea for detecting stale changes in maven which
ly 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?
>
> --
> Regards,
> Igor
>
> On 12-09-06 2:52 PM, Mark Struberg wrote
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
>
> Wha
nni-Bucau
>
>> 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 basel
ile change / etc. See bullet
A. [1]
We are now really only focusing on the plugins itself as first step (aka B.).
LieGrue,
strub
[1] https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds
>
> From: Romain Manni-Bucau
>To: Mark Struberg
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 '
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
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,
+1
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Wednesday, September 5, 2012 2:46 PM
> Subject: [VOTE] Maven SCM 1.8
>
> Hi,
> I'd like to release Apache Maven Scm 1.8.
> We fixed 10 issues:
> http://jira.codehaus.org/secure/Rel
not easily make sure that you checked all plugins!
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Wednesday, September 5, 2012 2:32 PM
> Subject: Re: Git as the canonical SCM
>
> While
> No longer true, git has sparse checkout support (I believe since 1.7.0).
I hear this argument over and over again, and it is still wrong!
The sparse checkout support is only fragmentaric at least! It's for sure not
comparable with the sparse checkout features of SVN. I'd rather call it 'farce
Now apply this to maven-scm if you like to have a test object.
This sometimes gets built in one go, sometimes as single modules, ...
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List
> Cc:
> Sent: Wednesday, September 5, 2012 9:31 AM
> Subje
?
Same applies to all other projects which are kind of 'aggregator' like
maven-core, shared, etc
LieGrue,
strub
- Original Message -
> From: Benson Margulies
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Tuesday, September 4, 2012 11:18 PM
And the Seam guys and a few others got pretty much stuck because the
granularity level needs to be up front if you move to GIT.
GIT is cool, but it is not as modular as SVN. git-submodules are still a farce
and there is nothing else which allows modularisation.
Don't get me wrong, I really like
+1
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Tuesday, September 4, 2012 2:15 PM
> Subject: Re: [VOTE] Release maven-shade-plugin 2.0 -- attempt 2
>
> +1
>
> 2012/9/3 Benson Margulies :
>> We solved 4 issues:
>>
>> ** Bug
a year now without any major issues. There was a
> problem with older IBM JVMs [1], but it is fixed now in slf4j (and
> in IBM code too, as far as I understand).
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=338252
>
> --
> Regards,
> Igor
>
>
> On 12-09
hanges. Been there, done that ...
LieGrue,
strub
>
> From: Stephen Connolly
>To: Maven Developers List ; Mark Struberg
>
>Sent: Monday, September 3, 2012 11:55 AM
>Subject: Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/
_
> From: Stephen Connolly
>To: Maven Developers List ; Mark Struberg
>
>Sent: Monday, September 3, 2012 10:42 AM
>Subject: Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/
>maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/
>ma
whats the reason for the slf4j bridge?
This is kown to trash old plugins which use log4j because it clashes with it's
namespace and only partly implements the log4j classes.
I personally ind slf4j nice, but for older projects which use commons-logging
or log4j already (and where you cant fiddl
This opens up another can of worms: how to deal with plugins which cannot be
made maven2 compatible anymore but we like to implement a new feature? How long
do we like to support maven2 at all? Will we create a branch for those plugins?
LieGrue,
strub
- Original Message -
> From: Ben
you are right. I will recheck the effective dependency versions and kill out
the versions if not needed.
LieGrue,
strub
- Original Message -
> From: Dennis Lundberg
> To: dev@maven.apache.org
> Cc:
> Sent: Saturday, September 1, 2012 11:16 PM
> Subject: Re: svn commit: r1379726 - in
inal Message -
> From: Jason van Zyl
> To: Maven Developers List
> Cc:
> Sent: Saturday, September 1, 2012 2:40 PM
> Subject: Re: the BuildContext
>
>
> On Sep 1, 2012, at 6:21 AM, Mark Struberg wrote:
>
>> Hi
+1 now, key is fine.
LieGrue,
strub
- Original Message -
> From: Mark Struberg
> To: Maven Developers List ; Benson Margulies
>
> Cc:
> Sent: Saturday, September 1, 2012 3:47 PM
> Subject: Re: [VOTE] release maven-shade-plugin version 2.0
>
>
>
> c
code builds fine,
license headers are fine,
real project builds fine as well
But your key is missing in https://svn.apache.org/repos/asf/maven/project/KEYS
Can you please add them (must be the one with yout apache.org email). I'll then
check it and cast my vote.
LieGrue,
strub
- Ori
Hi!
While doing further research on the incremental build I came accross the
org.sonatype.plexus.build.incremental.BuildContext.
There are a few things around this class which caught my interrest.
1.) This class has a package org.sonatype, the artifact name groupId
org.codehaus.plexus and
why not, the changes are good and it's a mature plugin now.
LieGrue,
strub
- Original Message -
> From: Benson Margulies
> To: Maven Developers List
> Cc:
> Sent: Friday, August 31, 2012 8:02 PM
> Subject: Is it, in fact, time for maven-shade-plugin 2.0?
>
> OK, now that I've clea
Hi folks!
I need a bit feedback about forcing mojo execution in incremental builds [1].
As already explained, the main problem in this area is that some plugins (e.g.
maven-compiler-plugin) already have some kind of incremental build logic, but
do this way too lazily (see 'Rational' in the link
In SVN you need to do this an all subfolders afaik.
Btw, while we are at it please all make sure that your svn:eol-style is set up
correctly [1]. That is often missing as well.
LieGrue,
strub
[1] http://www.apache.org/dev/svn-eol-style.txt
- Original Message -
> From: Anders Hamma
.git
.gitignores
as well.
LieGrue,
strub
- Original Message -
> From: Tony Chemit
> To: dev@maven.apache.org
> Cc:
> Sent: Friday, August 31, 2012 2:39 PM
> Subject: Re: svn:ignore
>
> On Fri, 31 Aug 2012 14:25:27 +0200
> Anders Hammar wrote:
>
>> Doing some reading in the deve
I've created
https://jira.codehaus.org/browse/MSHARED-239
to cover this.
LieGrue,
strub
- Original Message -
> From: Aleksandar Kurtakov
> To: Maven Developers List
> Cc:
> Sent: Friday, August 31, 2012 8:46 AM
> Subject: Re: Any maven-shared or maven-core release pending?
>
> -
+1
diff looks fine,
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Thursday, August 30, 2012 7:37 PM
> Subject: Re: [VOTE] Maven Skins parent 7 and Maven Fluido skin 1.3.0
>
> One binding vote is still missing.
>
> --
> Olivier
I thought the problem is obvious as I got a few acks when we discussed it here
on the list.
I've now updated the WiKi page to explain the problem
LieGrue,
strub
- Original Message -
> From: Jason van Zyl
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Se
s use "mvn CLEAN install" all
the time currently.
LieGrue,
strub
>
> From: Jason van Zyl
>To: Maven Developers List ; Mark Struberg
>
>Sent: Thursday, August 30, 2012 3:11 PM
>Subject: Re: Removing unused code from maven-shared-util
which got changed. I changed that only recently.
LieGrue,
strub
>
> From: Jason van Zyl
>To: Maven Developers List ; Mark Struberg
>
>Sent: Thursday, August 30, 2012 2:49 PM
>Subject: Re: Removing unused code from maven-shared-utils
>
>
> From: Jason van Zyl
>To: Maven Developers List ; Mark Struberg
>
>Sent: Thursday, August 30, 2012 2:44 PM
>Subject: Re: Removing unused code from maven-shared-utils
>
>
>
>
>On Aug 30, 2012, at 8:33 AM, Mark Struberg wrote:
>
>I&#x
101 - 200 of 582 matches
Mail list logo
