I just added a .gitattributes file to the repo, which fixes the problem
permanently.
All our git repos now have that file. Come to think of it, maybe we should
do another round of migrations ?
Kristian
23. nov. 2013 07:23 skrev Hervé BOUTEMY herve.bout...@free.fr følgende:
uh!
with svn,
I don't understand the change
there is no Jira issue associated
and it breaks ITs both on Apache's Jenkins instance and on my local machine
can you explain and check, please?
Regards,
Hervé
Le lundi 21 octobre 2013 18:30:19 jdca...@apache.org a écrit :
Updated Branches:
refs/heads/master
Hi,
I'd like to release shade plugin next week (only 1 new feature)
Let me know if any issues.
Cheers,
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe,
Am 2013-11-23 07:23, schrieb Hervé BOUTEMY:
uh!
with svn, we have svn-eol-style.txt [1] to deal automatically with such
newline issues
with git, nothing is written yet [2], but I suppose we need such an equivalent
config since .apt files are not well known
That one was quite annoying. Took
Your local settings dont matter now that I added .gitattributes
K
nice new feature
a few remarks:
- IMHO, such a feature deserve a 3.2 Maven version instead of 3.1.2
- explanations in the commit comment are a good start for a documentation page
in the component, no?
- for the TODOs in MojoExecutionListener interface, I think both methods
should be added,
On 11/23/2013, 10:57, Hervé BOUTEMY wrote:
nice new feature
a few remarks:
- IMHO, such a feature deserve a 3.2 Maven version instead of 3.1.2
I don't feel particularly strong about this. On one hand, this does not
introduce any user-visible change in behaviour, so from user point of
view
I think the change assumes that /bin/sh is bash-compatible. On OSX 10.9
I have to change mvn script to explicitly require #!/bin/bash, otherwise
maven invocation fails.
--
Regards,
Igor
On 11/23/2013, 5:46, Hervé BOUTEMY wrote:
I don't understand the change
there is no Jira issue associated
I think
X=v
export X
Instead of
export X=v
is more portable. But in any cases, if this is supposed to be an official API
it needs to be better tracked and documented (and I somewhat think those
features make maven POMs less portable).
Am 23.11.2013 um 17:47 schrieb Igor
I updated https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration with
.gitattributes instructions, and made a global cleanup
Seems like plugin-tools is ready for migration, or even did it without having
the page updated
Now, I did not have any feedback about SCM report problems with
Am 2013-11-23 19:02, schrieb Hervé BOUTEMY:
I updated https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration with
.gitattributes instructions, and made a global cleanup
Seems like plugin-tools is ready for migration, or even did it without having
the page updated
Now, I did not have
On Saturday, 23 November 2013, Michael-O 1983-01...@gmx.net wrote:
Am 2013-11-23 19:02, schrieb Hervé BOUTEMY:
I updated https://cwiki.apache.org/confluence/display/MAVEN/Git+Migrationwith
.gitattributes instructions, and made a global cleanup
Seems like plugin-tools is ready for migration,
Am 2013-11-23 20:18, schrieb Stephen Connolly:
On Saturday, 23 November 2013, Michael-O 1983-01...@gmx.net wrote:
Am 2013-11-23 19:02, schrieb Hervé BOUTEMY:
I updated https://cwiki.apache.org/confluence/display/MAVEN/Git+Migrationwith
.gitattributes instructions, and made a global cleanup
On Saturday, 23 November 2013, Michael-O 1983-01...@gmx.net wrote:
Am 2013-11-23 20:18, schrieb Stephen Connolly:
On Saturday, 23 November 2013, Michael-O 1983-01...@gmx.net wrote:
Am 2013-11-23 19:02, schrieb Hervé BOUTEMY:
I updated
Before I forget, here are some of my thoughts on moving towards Model
Version 5.0.0
The pom that we build with need not be the pom that gets deployed...
thus the pom that is built with need not be the same format as the pom
that gets deployed.
Only with packagingpom/packaging do we
A couple of months ago I started with a patch for Modello[1][2] which
should make it quite easy to generate a single Reader and Writer with
support for different versions, with respect to all the existing checks.
This is one of the requirements which must be fixed before we can start
I like the idea of deploying multiple POM files. It is very in line with
deploying multiple hash codes.
Another solution is to deploy one POM that contains both the 4 and 5
signature. You can do this using XSD namespaces. The namespace of the root
element can be whatever POM version you want, and
On Nov 23, 2013, at 5:44 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Before I forget, here are some of my thoughts on moving towards Model
Version 5.0.0
The pom that we build with need not be the pom that gets deployed...
thus the pom that is built with need not be
On 11/23/2013, 23:08, Jason van Zyl wrote:
On Nov 23, 2013, at 5:44 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Before I forget, here are some of my thoughts on moving towards
Model Version 5.0.0
The pom that we build with need not be the pom that gets
deployed... thus the
By separating consumption and production metadata formats, we'll be
able to evolve production format more aggressively. For example, it
would be nice to have Tycho-specific configuration markup inside build
section. This is not currently possible because all poms must be
compatible with the
Hello,
I'd like to release maven-verifier 1.5 and switch core ITs to the new
version some time next week. This is to pick up generics changes and
IDE integration hooks I just introduced. Any objections?
--
Regards,
Igor
-
To
21 matches
Mail list logo
