Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/57
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Am 2014-10-12 um 00:30 schrieb Stephen Connolly:
On Saturday, 11 October 2014, Michael Osipov micha...@apache.org wrote:
Am 2014-10-11 um 21:28 schrieb Robert Munteanu:
On Sat, Oct 11, 2014 at 10:23 PM, Michael Osipov micha...@apache.org
wrote:
Well said...
I guess it is all about the
On Sunday, 12 October 2014, Michael Osipov micha...@apache.org wrote:
Am 2014-10-12 um 00:30 schrieb Stephen Connolly:
On Saturday, 11 October 2014, Michael Osipov micha...@apache.org wrote:
Am 2014-10-11 um 21:28 schrieb Robert Munteanu:
On Sat, Oct 11, 2014 at 10:23 PM, Michael Osipov
I like the way Mojo makes common sense explicit without trademark drama:
http://mojo.codehaus.org/development/guidelines.html
- Use the plugin-maven-plugin convention for the artifactId of any developed
Maven plugin.
- Use the [Project] Maven Plugin convention to name your plugin e.g. Acme
On 2014-10-11, Kristian Rosenvold wrote:
Piñata encodes as NFC on my mac, which is correct. I am not sure if
the NFD issue is for older macs, but at least it looks good here.
Great. It may be older macs or older Java.
Stefan
+1
Op Wed, 08 Oct 2014 19:36:40 +0200 schreef Karl Heinz Marbaise
khmarba...@gmx.de:
Hi,
We solved 15 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11150version=19421
There are still a couple of issues left in JIRA:
On Sunday, October 12, 2014, Hervé BOUTEMY herve.bout...@free.fr wrote:
I like the way Mojo makes common sense explicit without trademark drama:
http://mojo.codehaus.org/development/guidelines.html
- Use the plugin-maven-plugin convention for the artifactId of any
developed
Maven plugin.
Hi,
The vote has passed with the following result:
+1 (binding): Hervé Boutemy, Karl Heinz Marbaise, Robert Scholte
+1 (non binding): none
I will promote the artifacts to the central repo.
Kind regards
Karl Heinz Marbaise
-
Hi,
Right now we change the Maven prerequisite to 2.2.1 and I noticed some new
issues which already want to move it forward to 3.0.4. I wonder why to
move to this version.
Most (API-)changes have been introduced with the 3.0 alpha and beta
releases. I don't think that the other 3.0.x
What EOL handling are we expected to use for Maven git repositories? I
don't recall this was discussed before, but this commit [1] stands out
from the rest. I usually follow github recommendation [2], so I wonder
if we can adopt the same for Maven work. Any thoughts?
[1]
Hi Robert,
from my point of view minimum to 3.0.5 ...nothing below...afterwards
3.1.1.and then 3.2.1...the latest releases from the appropriate
release lines 3.0.X, 3.1.X, 3.2.X,
I wouldn't go to 3.1.0 at the moment cause that could be
confusingfrom user point of view...than
The Apache Maven team is pleased to announce the release of the
Apache Maven WAR Plugin, version 2.5
The WAR Plugin is responsible for collecting all artifact dependencies, classes
and resources of the web application and packaging them into a web application
archive.
This is probably bigger then just git.
We discovered that right now the release distributions are actually OS
specific. If I would do a release, the EOLs are Windows based, where as
releases of most others are Unix based.
This was exposed by some checkstyle rules: checking out from subversion
Ah ! The answer is that we don't leave it to the user to handle line endings.
I have added .gitattributes files to all our git repos, which
basically dictate how line endings should be handled.
The thing is; it does not contain xml files. This is the one I have added:
*.java text diff=java
I agree release distributions should have consistent end-of-line
handling, but I think this is a separate problem/decision from how we
deal with end-of-lines in git. Release distros are produced once, so we
can pick single eol-format. Git repositories, on the other hand, are
used and modified by
I am no git expert, but I believe proper text-vs-binary classification
is only part of the solution. Git still needs to know what format to use
in the repository and what format to use for the checkout. At least this
was the case when I started using git, maybe modern versions are smarter
about
I think that I, amongst other people, are in danger of losing track of
the trademark forest for the trees.
I'm copying trademarks@, which is a closed list, but I don't think
that this discussion has to be restricted to private@. If anyone on
trademarks@ cares to correct me, please copy the Maven
That's the way this used to be; but they actually .solved. this
problem with the .gitattributes approach, so all we need to do is add
xml and properties files.
We just need to find out which of these should be added (from maven plugins):
Kristians-MacBook-Pro:maven-plugins kristian$ find . -type
On Sun, Oct 12, 2014 at 9:25 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi Robert,
from my point of view minimum to 3.0.5 ...nothing below...afterwards
3.1.1.and then 3.2.1...the latest releases from the appropriate release
lines 3.0.X, 3.1.X, 3.2.X,
I wouldn't go to 3.1.0 at
Am 2014-10-12 um 16:10 schrieb Benson Margulies:
On Sun, Oct 12, 2014 at 9:25 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi Robert,
from my point of view minimum to 3.0.5 ...nothing below...afterwards
3.1.1.and then 3.2.1...the latest releases from the appropriate release
lines
Hi,
based on the work i did i enhanced the dist-tool to produce some parts
of the report which i manually created...
https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html
The report is not complete missing some parts (nor the code hard coded
etc...) but this is a
Hi,
You mean with the new setup the build will fail because of a checkstyle issue?
I personally find really hard for a style problem. (i.e something
not related to a real technical problem).
On 11 October 2014 18:00, Hervé BOUTEMY herve.bout...@free.fr wrote:
Log:
- Fixed several Checkstyle
Personally I have a problem with a Maven 3.0.5 requirement. The reason is
that there are IDEs out there that is based on Maven 3.0.4. Also, IIRC
there was just a very minor (code wise) difference between Maven 3.0.5 and
3.0.4, so requiring 3.0.5 (instead of 3.0.4) wouldn't give us much.
Having
23 matches
Mail list logo
