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<ArtifactRepository> ?Or fix 2.2.x AND 2.2.RC branches to support the normalization process for better compatibility with previous versions of remote-resources plugin ?
2009/5/4 John Casey <[email protected]> > 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/MRRESOURCES-15 >> >> according to remote-resource plugin source in trunk the plugin uses the >> expected ProjectUtils.buildArtifactRepositories to build a valid >> List<ArtifactRepository> from a List<Repository>, and don't call >> the buildFromRepository with a un-normalised List<Repository>. >> >> BUT the latest stable 1.0.1 don't use this and >> calls mavenProjectBuilder.buildFromRepository with >> ${project.repositories}. >> >> Based on this, MRRESOURCES-15 seems not to be fixed in maven 2.2.x with a >> non-snapshot project. >> >> Should we fix the core or expect plugins to use buildArtifactRepositories >> builder method - and wait for a 1.0.2 release of remote-resources-plugin ? >> >> >> 2009/5/4 Benjamin Bentmann <[email protected]> >> >> 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 code >>> in >>> the 2.x branches is buggy. While in the original r616610 the return value >>> of >>> normalizeToArtifactRepositories() is used, it's not in r616830 and the >>> method has no side effects either. >>> >>> This naturally leads to the question, if the code in 2.x isn't effective >>> anyway and nothing requires it in practice, should we should get rid of >>> it? >>> >>> >>> Benjamin >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
