Issue Subscription
Filter: Design & Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
Yeah, this looks fine.
BTW, I'm officially done using git-svn. While I like Git as a tool in
itself, the workflow of git-svn is dangerous IMO. All of the code fixes
you put in place after I did the RC last week were already in my local
git repo, I just forgot to call `git svn dcommit`.
Unbel
+1
Jason van Zyl wrote:
Hi,
Igor has been submitting patches for over a year now and in the last 12
weeks he's been submitting some very substantive changes to 3.x.
Igor has done things like create a performance framework for Maven 3.x
to make sure it doesn't regress, has created some APIs
+1
Brett Porter wrote:
Hi,
Mark has been contributing regularly to Maven SCM for quite some time
(in particular the git support recently, and I think has been wanting to
help with improving the API and release mechanism for git), as well as
being more broadly active.
I think he'd be a grea
On Thu, Jul 30, 2009 at 9:51 AM, Ralph Goers wrote:
>
> On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
>
>> We also have to be careful of the problems introduced in 2.1.0 because
>> of transforming the pom...gpg can't sign etc.
>
> Are those itemized anywhere? Eventually these problems need to be so
+1
Hervé
Le jeudi 30 juillet 2009, Brett Porter a écrit :
> Hi,
>
> Mark has been contributing regularly to Maven SCM for quite some time
> (in particular the git support recently, and I think has been wanting
> to help with improving the API and release mechanism for git), as well
> as being mor
During the month of August many more ITs are going to be written and
the POM and resolution specifications will be cleaned up. Until that's
done nothing radical is going to change on trunk. With all the work
that's happening it's still all refactoring, preparation for the
future and restora
On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
Are those itemized anywhere? Eventually these problems need to be
solved.
Ralph
2009/7/29 Ralph Goers :
Well, darn. I fina
+1
Arnaud
On Thu, Jul 30, 2009 at 2:50 PM, Jason van Zyl wrote:
> +1
>
>
> On 30-Jul-09, at 4:34 AM, Brett Porter wrote:
>
> Hi,
>>
>> Mark has been contributing regularly to Maven SCM for quite some time (in
>> particular the git support recently, and I think has been wanting to help
>> with i
+1
On 30-Jul-09, at 4:34 AM, Brett Porter wrote:
Hi,
Mark has been contributing regularly to Maven SCM for quite some
time (in particular the git support recently, and I think has been
wanting to help with improving the API and release mechanism for
git), as well as being more broadly ac
+1
Rahul
On Thu, Jul 30, 2009 at 5:04 PM, Brett Porter wrote:
> Hi,
>
> Mark has been contributing regularly to Maven SCM for quite some time (in
> particular the git support recently, and I think has been wanting to help
> with improving the API and release mechanism for git), as well as being m
There is actually an issue for that:
http://jira.codehaus.org/browse/DOXIASITETOOLS-15
-Lukas
Lukas Theussl wrote:
The icons come from the used skin, eg [1]. We had the problem in the pdf
plugin [2] which we solved by copying all resources of a given skin, but
I don't know if that's the b
+1
--
Olivier
2009/7/30 Brett Porter :
> Hi,
>
> Mark has been contributing regularly to Maven SCM for quite some time (in
> particular the git support recently, and I think has been wanting to help
> with improving the API and release mechanism for git), as well as being more
> broadly active.
>
+1
2009/7/30 Brett Porter :
> Hi,
>
> Mark has been contributing regularly to Maven SCM for quite some time (in
> particular the git support recently, and I think has been wanting to help
> with improving the API and release mechanism for git), as well as being more
> broadly active.
>
> I thin
>
>
> ${project.groupId}
> other-artifactId
> ${project.version}
>
>
> would become:
>
>
> other-artifactId
>
Besides saving a few keystrokes I don't see how that helps much? It's
definitely less obvious. Looking at that, I now have to go search the
parent hierarchy to determine if the ver
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
2009/7/29 Ralph Goers :
> Well, darn. I finally read the proposal. From what I can tell this is
> largely what I implemented in
> https://svn.apache.org/repos/asf/maven/componen
+1
-Lukas
Brett Porter wrote:
Hi,
Mark has been contributing regularly to Maven SCM for quite some time
(in particular the git support recently, and I think has been wanting to
help with improving the API and release mechanism for git), as well as
being more broadly active.
I think he'd
Brett Porter wrote:
I think he'd be a great addition to the team.
+1
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Hi,
Mark has been contributing regularly to Maven SCM for quite some time
(in particular the git support recently, and I think has been wanting
to help with improving the API and release mechanism for git), as well
as being more broadly active.
I think he'd be a great addition to the team
Geoffrey De Smet wrote:
IMHO the FAQ should follow the recommended guidelines
Well, the recommendation is to not skip tests ;-)
so shouldn't it use skipTests instead of maven.test.skip?
I updated the FAQ to mention both properties, it's up to the user to
choose what fits his/her intention
The javadoc you specified clearly state though, that skipTests is
recommended because maven.test.skip doesn't compile the testcases :)
IMHO the FAQ should follow the recommended guidelines, so shouldn't it
use skipTests instead of maven.test.skip?
With kind regards,
Geoffrey De Smet
Olivier
Hi
On Jul 30, 2009, at 10:23 AM, Ringo De Smet wrote:
Mark,
2009/7/30 Donszelmann Mark :
the NAR plugin uses its own lifecycle as documented here:
http://java.freehep.org/freehep-nar-plugin/lifecycle.html
Small correction: you have a custom lifecycle *mapping*, but you are
still binding t
Mark,
2009/7/30 Donszelmann Mark :
>
> the NAR plugin uses its own lifecycle as documented here:
>
> http://java.freehep.org/freehep-nar-plugin/lifecycle.html
Small correction: you have a custom lifecycle *mapping*, but you are
still binding to the default lifecycle. I'm talking about linking the
23 matches
Mail list logo
