Hi Lukas,
2009/5/4 Lukas Theussl ltheu...@apache.org:
Vincent,
I'm trying to understand some of the issues we have with entities in the
XmlParser. Is there a special reason why entities are emitted as rawText and
not text?
The text used by XhtmlBaseParser#handleEntity() could contain
Vincent,
I'm trying to understand some of the issues we have with entities in the
XmlParser. Is there a special reason why entities are emitted as rawText and not text?
I think they should be emitted as text:
First, custom entities can be used to simply define some replacement text inside
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 br...@apache.org
Also, I thought having the archetype catalog
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
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
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
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
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
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
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
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
ListArtifactRepository from a ListRepository, and don't
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
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)
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
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`
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
Changes like this are pretty disastrous:
-private MapString, ArtifactVersion managedVersionMap;
+private MapString, Artifact 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
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 MapString, ArtifactVersion managedVersionMap;
+private MapString, Artifact managedVersionMap;
Does it even compile?
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,
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
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
...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
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 ListArtifactRepository ?Or fix 2.2.x AND 2.2.RC branches
to support the normalization process for better compatibility with previous
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
Why would you have a symlink in your target folder to someplace important?
On Mon, May 4, 2009 at 5:25 PM, Bouiaw bou...@gmail.com wrote:
Hi,
Sorry to write again about clean plugin, but there is currently 2 VERY big
bugs in Maven clean with no workaround.
Just so it's clear, I'm -1 on this commit. I see things like:
-private MapString, ArtifactVersion managedVersionMap;
+private MapString, Artifact 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
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.
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
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.
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 sebastian.ann...@coremedia.com:
Hi Vincent,
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
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:
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
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
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
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
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
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
Right, I'll rollback this on 2.2.RC branch and foc on 2.2.1
2009/5/5 Brian Fox bri...@infinity.nu
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
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 jdca...@commonjava.org
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
40 matches
Mail list logo
