Sory for the source formatting changes, I'm using the maven-codestyle.xml so
expected it to not disturb the source.
2009/5/5 John Casey
> I'm vetoing (-1) this change and the one in 771294. Looking through this
> commit, it seems apparent to me that unless you've verified all the
> collection ch
Right, I'll rollback this on 2.2.RC branch and foc on 2.2.1
2009/5/5 Brian Fox
> I'm -1 on this change as well. Lets back these out and try it again
> correctly. This was my concern that large changes just before a release are
> almost always a bad thing. Just because we decide to flip the sourc
This is just a warning that the Maven team has just discovered an interaction
problem between Maven 2.1 and the maven-gpg-plugin that CAN result in the
signatures for the installed/deployed poms being invalid. Signatures for the
other artifacts (jars, wars, etc..) are unaffected and not all p
Yeah, that's what made me think about combining them.
Brett Porter wrote:
On 05/05/2009, at 10:16 AM, Brian Fox wrote:
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
True. Is there a way for the indexer to generate it during the firs
On 05/05/2009, at 10:16 AM, Brian Fox wrote:
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
True. Is there a way for the indexer to generate it during the first
crawl? Putting it into the index and pulling it back out again seems
On 05/05/2009, at 11:01 AM, Brian Fox wrote:
To make this happen relatively quickly, I'll take finish my patch by
adding tests, and then stage a release of the assembly plugin 2.2-
beta-3.1 by applying only this patch to the existing beta-3 tag so
we can cut a release without a bunch of han
There have been a few threads spawned on various ASF lists lately about
the release process at the ASF and Maven projects and other Apache
projects that use Maven being compliant.
A documentation patch for the release page at
http://www.apache.org/dev/release.html is pending, but it's close en
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
Brett Porter wrote:
Don't we already have the archetype:crawl mojo?
On 05/05/2009, at 3:52 AM, Brian Fox wrote:
Maybe that code could be rolled into the indexer since it's the
source of t
Hi again,
After finding and cleaning up some code that seems to be tainted during
some of our efforts at generifying the codebase, we've respun a new
release candidate.
If you have time, please give it a whirl:
https://repository.apache.org/content/repositories/maven-staging-010/org/apache/m
Don't we already have the archetype:crawl mojo?
On 05/05/2009, at 3:52 AM, Brian Fox wrote:
Maybe that code could be rolled into the indexer since it's the
source of the data.
Tamás Cservenák wrote:
We could create a CLI tool out of Nexus Archetype Plugin in similar
manner
as Nexus Indexe
Hi,
I spoke with Robert Scholte (qdox team) today. He plans to make a new
release soon.
I prefer to wait for this release before starting the release process.
For the curious, it is for the new fix goal.
Cheers,
Vincent
2009/5/4, Sebastian Annies :
> Hi Vincent, Benjamin and Jason,
>
> It see
BTW, we're happy to accept patches! If you have code that fixes this,
please let me know. I'll review and apply where appropriate.
Bouiaw wrote:
Hi,
Sorry to write again about clean plugin, but there is currently 2 VERY big
bugs in Maven clean with no workaround.
http://jira.codehaus.org/brow
I'm vetoing (-1) this change and the one in 771294. Looking through this
commit, it seems apparent to me that unless you've verified all the
collection changes using something like Eclipse's Call Hierarchy tool
after letting Eclipse change all sorts of source code, we can't depend
on the result
I'm -1 on this change as well. Lets back these out and try it again
correctly. This was my concern that large changes just before a release are
almost always a bad thing. Just because we decide to flip the source flag
over to 1.5 doesn't mean we have to convert every piece of code to 1.5 yet.
There
Just so it's clear, I'm -1 on this commit. I see things like:
-private Map managedVersionMap;
+private Map managedVersionMap;
And that means it wasn't done properly and thus I have no faith in the rest
of the commit. Please revert this.
On Mon, May 4, 2009 at 8:54 AM, wrote:
> Author: n
Why would you have a symlink in your target folder to someplace important?
On Mon, May 4, 2009 at 5:25 PM, Bouiaw wrote:
> Hi,
>
> Sorry to write again about clean plugin, but there is currently 2 VERY big
> bugs in Maven clean with no workaround.
>
> http://jira.codehaus.org/browse/MCLEAN-32 :
We should fix it in 2.2.x. Unless there is an actual bug, we shouldn't
make ANY code changes in the RC branch.
nicolas de loof wrote:
Not sure to understand you well. Do you mean release 2.2.0 as is, remove
this normalize code in 2.2.x branch and set buildFromRepository method
signature set to
Not sure to understand you well. Do you mean release 2.2.0 as is, remove
this normalize code in 2.2.x branch and set buildFromRepository method
signature set to List ?Or fix 2.2.x AND 2.2.RC branches
to support the normalization process for better compatibility with previous
versions of remote-reso
...and the new version with the changes builds fine, with ITs passing.
This may seem like a good thing, but the fact that the build/ITs work in
both cases is pretty disturbing, IMO. It means that we can't necessarily
depend on these criteria to determine whether the syntax conversion is
workin
Maybe that code could be rolled into the indexer since it's the source
of the data.
Tamás Cservenák wrote:
We could create a CLI tool out of Nexus Archetype Plugin in similar manner
as Nexus Indexer CLI exists (or even make those two CLIs
one?) Naturally, the Archetype CLI would required Ne
We could create a CLI tool out of Nexus Archetype Plugin in similar manner
as Nexus Indexer CLI exists (or even make those two CLIs
one?) Naturally, the Archetype CLI would required Nexus Indexer CLI (to be
able to use Nexus Index to generate the catalog).
Of course, if there is some other avai
Hi Vincent, Benjamin and Jason,
It seems that all 2.6 issues are fixed and no SNAPSHOT dependency left.
I'd really like to use the javadoc aggregatation + jar feature. How
about calling a vote on releasing 2.6? Can one of you do it (You will
get my non-binding vote for sure)?
Best Regards,
Seba
the version before this commit did actually build and run the ITs. I
really have no idea how, TBH.
Brian Fox wrote:
Changes like this are pretty disastrous:
-private Map managedVersionMap;
+private Map managedVersionMap;
Does it even compile?
John Casey wrote:
Can you please take a lo
Changes like this are pretty disastrous:
-private Map managedVersionMap;
+private Map managedVersionMap;
Does it even compile?
John Casey wrote:
Can you please take a look at any other code you might have
automatically "fixed" using Eclipse's tooling without then reviewing
yourself, so
Can you please take a look at any other code you might have
automatically "fixed" using Eclipse's tooling without then reviewing
yourself, so we can avoid the obvious problems that could be caused by
this sort of thing creeping in? For anyone looking at this code
interactions and converting it
Personally, I think we should fix it. We're just now doing 2.2.0-RC1, so
there's no reason we can't make a new release of the resources plugin
before 2.2.1 to get this fixed.
nicolas de loof wrote:
The commit seems to be related to Seems to be related to
http://jira.codehaus.org/browse/MRRESOU
Yes, IF the xwiki build works without that code in place. I guess I'll
fire up that build today to see.
Benjamin Bentmann wrote:
nicolas de loof wrote:
r616830 | jdcasey | 2008-01-30 19:24:41 +0100 (mer., 30 janv. 2008)
Yes
Benjamin Bentmann wrote:
nicolas de loof wrote:
r616830 | jdcasey | 2008-01-30 19:24:41 +0100 (mer., 30 janv. 2008) |
1 line
porting revId 616610 of trunk back to 2.0.x branch
The commits mentioned suggest that y
The commit seems to be related to Seems to be related to
http://jira.codehaus.org/browse/MRRESOURCES-15
according to remote-resource plugin source in trunk the plugin uses the
expected ProjectUtils.buildArtifactRepositories to build a valid
List from a List, and don't call
the buildFromRepository
Fuuny to see you created this method :)
616830jdcasey private List normalizeToArtifactRepositories( List
remoteArtifactRepositories,
r616830 | jdcasey | 2008-01-30 19:24:41 +0100 (mer., 30 janv. 2008) | 1 line
portin
nicolas de loof wrote:
r616830 | jdcasey | 2008-01-30 19:24:41 +0100 (mer., 30 janv. 2008) | 1 line
porting revId 616610 of trunk back to 2.0.x branch
The commits mentioned suggest that your analysis was right and the co
I put that in in response to a NPE bug that was filed, IIRC. I don't
think it's dead code, but only expressed in very particular situations.
It's possible that the plugin/whatever that was expressing it has a new
version out that no longer causes this problem, too.
Maybe try a `svn annotate` t
Hey,
I'm facing weird problems with the maven-release-plugin and friends.
I use maven-release-plugin-2.0-beta-9 and get the same results with either
maven 2.1.0 or 2.2.0-RC1.
I tried with two subversion clients with the same results too : 1.4.6 and
1.6.1.
I'm issuing the following instruction
On 4-May-09, at 7:50 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
We could also just go simple and spit out an XML document with all
the plugins in the default lifcycle with versions and
configurations. [...] I'm sure you can see the lack of symmetry in
having to synthesize executio
Hi guys,
Trying to update the 2.2.x branch to use generics java5 syntax in
collections for better type safety I fall into this :
DefaultMavenProjectBuilder.normalizeToArtifactRepositories() method converts
a List that can contain either Repository or ArtifactRepository to a list of
ArtifactReposit
Jason van Zyl wrote:
We could also just go simple and spit out an XML document with all the
plugins in the default lifcycle with versions and configurations.
[...] I'm sure you can see the lack of symmetry in
having to synthesize execution elements for the model builder to
consume. They shoul
Hi John,
no regressions found with Mac OSX 1.5.0_16.
Cheers
John Casey wrote:
Hi everyone,
It's that time again. For the 2.2.0 release of Maven, we're trying to
keep the number of issues fairly limited to regressions, issues with
quite a few votes that are low-hanging fruit, and some sort o
Due to obviously correct advice, the vote is canceled.
I'll try to promote a new build as soon as i can.
Brian, how can we have the catalog auto-generated for central on sync or
weekly ?
Regards,
Raphaël
2009/5/4 Brett Porter
> Also, I thought having the archetype catalog online was a pre-re
38 matches
Mail list logo
