+1
A little note regarding the site: Seems like the contents of the
"requireReleaseDeps" and "requireReleaseVersion" rule pages have been
interchanged. This doesn't change my (non-binding) +1 for the alpha
release so you can restage or file a jira for 1.0 as you like.
Good work!
On Tue, Sep 9, 2
Checking
org.apache.maven.plugin.eclipse.it.EclipsePluginIT_testProject36.build.log:
[DEBUG] Processing resource dir:
D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\project-36\my-ejb\src\main\resources
[DEBUG] Resource dir:
D:\ide\maven\maven-eclipse-plugin\target\test-classes\pro
maven-eclipse-plugin\target\test-classes\projects\project-36\my-ejb\.classpath
Expected:
Actual:
It looks like the test resources are not added as part of
ejb.
Can someone else please run the ITs and confirm that this problem
exists for them?
I'm workin
John/Shane/Whoever,
Are you guys using maven-verifier 1.1-SNAPSHOT or 1.2-SNAPSHOT because
the POM says 1.1-SNAPSHOT which completely locks up and dies but when
I update to version 1.2-SNAPSHOT and change the POM it runs.
This is what's currently in SVN:
https://svn.apache.org/repos/asf/ma
On 9-Sep-08, at 14:03 , Oleg Gusakov wrote:
Benjamin Bentmann wrote:
Christian Edward Gruber wrote:
I suppose another option would be a very lightweight local repo
server so all activity against the local repo is "managed", but
this is probably overkill.
If I understand properly, not onl
Hi,
I've fixed MNG-3748, where illegal elements in the settings.xml were not
triggering build failure. Anyway, this release candidate includes a fix
for that issue:
http://people.apache.org/~jdcasey/stage/current-maven-RC/
Enjoy, and let me know if you have problems.
Thanks,
-john
---
Joh
There has also been some changes to the menus and navigation in the
site.xml file.
http://svn.apache.org/viewvc/maven/pom/trunk/maven/src/site/site.xml?r1=632423&r2=693260&diff_format=h
Brian E. Fox wrote:
> Take 2: I removed the enforcer version and the clirr checks. (see other
> vote thread fo
Yes I understand the reasoning behind it.
It's just it may cause unexpected failures in the CI systems, and unless
you aware of why these failures happen you might start to doubt the code
you are about to release. At least that's what I did back then.
Brian E. Fox wrote:
> It's dependent, if the
Brian E. Fox wrote:
>> Sorry, I missed that last bit.
>
>> Staging two releases simultaneously to the same staging repo will make
>> it difficult for you to move *only one* artifact to the central
>> repository using the Stage Plugin. I recommend using two different repo
>> directories for that, b
As I said before I agree that we should release more often. I was not
the one wanting to wait with the release, but someone (can't remember
who right now) wanted us to wait - so we waited.
John Casey wrote:
> I appreciate the fact that there's a strong release plan for the maven
> parent POM, but
OK, thanks for explaining Brian.
I'll take snippets of your descriptions and put into a JIRA for the
Clirr plugin. A skip parameter is on top of the wish list right?
Brian E. Fox wrote:
>> No, it's available in the quality-checks profile as well.
>
> I saw that but it didn't work. It tried to fi
+1
On Tue, Sep 9, 2008 at 3:35 PM, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
> +1
>
> Hervé
>
> Le mardi 09 septembre 2008, Mauro Talevi a écrit :
>> +1
>>
>> nicolas de loof wrote:
>> > +1
>> >
>> > 2008/9/9 Arnaud HERITIER <[EMAIL PROTECTED]>
>> >
>> >> +1
>> >>
>> >> Arnaud
>> >>
>> >> On Tue, S
+1
Hervé
Le mardi 09 septembre 2008, Mauro Talevi a écrit :
> +1
>
> nicolas de loof wrote:
> > +1
> >
> > 2008/9/9 Arnaud HERITIER <[EMAIL PROTECTED]>
> >
> >> +1
> >>
> >> Arnaud
> >>
> >> On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon <[EMAIL PROTECTED]>
> >>
> >> wrote:
> >>> +1
> >>>
> >>> --j
Benjamin Bentmann wrote:
Christian Edward Gruber wrote:
I suppose another option would be a very lightweight local repo
server so all activity against the local repo is "managed", but this
is probably overkill.
If I understand properly, not only overkill but also hassle: Imagine a
termina
Christian Edward Gruber wrote:
I suppose another option would be a very lightweight local repo server
so all activity against the local repo is "managed", but this is
probably overkill.
If I understand properly, not only overkill but also hassle: Imagine a
terminal environment where several
Christian, thank you for the links!
Christian Edward Gruber wrote:
Basically we need some sort of handling of local repositories such
that any number of processes can co-exist and read/write to the local
repo.
some related issues are:
http://jira.codehaus.org/browse/MNG-2802
http://jira.codeh
Basically we need some sort of handling of local repositories such
that any number of processes can co-exist and read/write to the local
repo.
some related issues are:
http://jira.codehaus.org/browse/MNG-2802
http://jira.codehaus.org/browse/MNG-3379
One proposal was:
http://docs.codehaus.org
I appreciate the fact that there's a strong release plan for the maven
parent POM, but why is one plugin release holding up the release of a
piece of metadata? It's not that this POM has any functionality that may
contain regressions, or that successive releases of components depending
on it co
Looks like this problem has two use cases - multiple builds interacting
with local repo:
1). writing new artifacts
2). downloading remote artifacts
In either case they race for metadata - to be addressed, in #2 they may
race for actual artifacts, which is addressable by Jetty transactional
cli
This represents new functionality, regardless of whether it makes sense.
All I'm interested in for the moment is restoring backward compatibility.
If we want to file a new issue for this specific restriction and start a
debate for the next release to incorporate, that's fine by me, but for
now
Oleg, the issue with with the local repo, not with the remote ones. Basically
there is no locking on the reads/writes to local so if you have multiple builds
that potentially touch the same metadata, you've got a problem. Mercury could
potentially deal with the race condition where 2 builds ask
How about if we just include this in v10 along with the enforcer and do
another release later this week?
-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2008 5:13 PM
To: Maven Developers List
Subject: Re: [vote] release maven-parent 9 TAKE 2
+1
nicolas de loof wrote:
+1
2008/9/9 Arnaud HERITIER <[EMAIL PROTECTED]>
+1
Arnaud
On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon <[EMAIL PROTECTED]>
wrote:
+1
--jason
On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote:
Time to release the enforcer with all its new rules.
The plugin i
+1
2008/9/9 Arnaud HERITIER <[EMAIL PROTECTED]>
> +1
>
> Arnaud
>
> On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon <[EMAIL PROTECTED]>
> wrote:
>
> > +1
> >
> > --jason
> >
> >
> >
> > On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote:
> >
> > Time to release the enforcer with all its new rules.
> >>
+1
Arnaud
On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> +1
>
> --jason
>
>
>
> On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote:
>
> Time to release the enforcer with all its new rules.
>>
>>
>>
>> The plugin is staged here:
>>
>> http://people.apache.org/~brianf/stage
On Tue, 09 Sep 2008 16:36:54 Paul Benedict wrote:
> John,
>
> Should MNG-3746 be revisited to not allow java.* properties to be
> overridden? I am concerned that while this is previous behavior,
me too
> perhaps it is really allowing people to shoot themselves in the foot.
> I consider that Maven
26 matches
Mail list logo
