Forgot to specify the correct source-release.zip path and checksum in the
vote mail:
https://repository.apache.org/service/local/repositories/maven-1012/content/org/apache/maven/surefire/surefire/2.17/surefire-2.17-source-release.zipsha1:
3d4357520c14b72daaed6b79beca576b2dfd004f
2014-03-12 22:52
Hi,
long ago since we released the last Surefire version. It's about time we
change that ;-).
We solved 16 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=19536
There are still lots of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?rese
src/main/config is used as the default value for configuration files
in appassembler-maven-plugin @Mojo.
On Tue, Mar 11, 2014 at 9:57 PM, Karl Heinz Marbaise wrote:
> Hi,
>
>
> On 3/9/14 9:02 PM, Karl Heinz Marbaise wrote:
>>
>> So based on the discussion could we go with the following:
>>
>> /sr
It could be used for build-time configuration files, which are not part of
the artifact / shouldn't be available on the classpath. I've never used it.
I think it's too rare, so I agree that it can be removed.
Robert
Op Tue, 11 Mar 2014 21:57:43 +0100 schreef Karl Heinz Marbaise
:
Hi,
On
Am 2014-03-12 06:43, schrieb Dennis Lundberg:
I want this release to be Java 5 compatible.
PMD 5.1 requires Java 6, even though it is not mentioned in their release
notes.
Fair enough but unprofessional from the PMD guys.
Michael
--
Hi,
The vote has passed with the following result:
+1 (binding): Mark Struberg, Hervé Boutemy, Dennis Lundberg, Olivier Lamy
+1 (non binding): Karl Heinz Marbaise, Michael Osipov
I will promote the artifacts to the central repo.
On Sat, Mar 8, 2014 at 11:49 PM, Dennis Lundberg wrote:
> Hi,
>
>
Personally I don't have the need, but if we want to move projects to Git,
this is probably one of the easy ones.
Robert
Op Wed, 12 Mar 2014 03:03:21 +0100 schreef Hervé BOUTEMY
:
no problem for me on this one
if someone creates a new git repository, it would be nice to create a
Maven
Hi Simone,
for that reason I've added the Metadata, from which you can get the latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
:
Hi again Robert,
in one of my VersionPolicy implementations, I
Congratz!
Op Wed, 12 Mar 2014 08:07:31 +0100 schreef Hervé BOUTEMY
:
wooo hooo!
here it is, at last: Core ITs are now ok for jobs using symbolic links
https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/
Regards,
Hervé
Le lundi 10 mars 2014 07:27:36 Hervé BOUTEMY a écrit :
just fo
Hi Igor,
There will be an option to specify the specific release version to
handle such situations, but let's do one step at a time :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 2:05 PM, Igor Fedorenko wrote:
> Out of curiosity,
Out of curiosity, how do you plan to deal with multiple development
streams with different "latest version" depending on the stream? If, for
example, somebody decided to release maven 3.0.6, it'd need to be
compared to 3.0.5, not 3.2.1.
--
Regards,
Igor
On 2014-03-12, 8:30, Simone Tripodi wrote:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for loca
wooo hooo!
here it is, at last: Core ITs are now ok for jobs using symbolic links
https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/
Regards,
Hervé
Le lundi 10 mars 2014 07:27:36 Hervé BOUTEMY a écrit :
> just for information, before someone asks: I know I broke one Jenkins job
> when
13 matches
Mail list logo
