I agree that this (lack of generics) can be a problem, but concur that it's not the most pressing thing, particularly with 3.x looming ahead. Fixing bugs in 2.x would serve the users far more and once 3.x stabilizes, then we can add generics if they aren't there yet.
On Sun, May 10, 2009 at 3:48 PM, nicolas de loof <nicolas.del...@gmail.com>wrote: > I just was not aware John was creating a RC when I committed into core. My > current issue with core is that from a plugin developer point of view it is > really hard to use as too many untyped List are used, and there is no > Javadoc to explain what is expected. buildFromRepository() is typically one > of those API method that is difficult to use but required when a plugin has > to use Artifact. > My goal is not to apply generics just for the beauty of using generics, but > to have a strong-typed API on MavenProject and other common classes. > > > > 2009/5/10 Jason van Zyl <jvan...@sonatype.com> > > > > > On 10-May-09, at 8:05 AM, nicolas de loof wrote: > > > > I've started my second attempt to generify the API, using call hierarchy > >> to > >> check how collections are used in code. > >> > > > > Nicolas this is not the way to learn the code and help. > > > > Pick a particular problem and learn a part of the code base. Littering > > changes all over the place to code you don't know is not a good idea. > > Changing everything to generics is not the most pressing need and you > seem > > to be causing more problems then necessary. It's fine that you want to > help > > but try and focus your efforts until you understand more of the code > base. > > You don't need to put generics everywhere to understand a particular set > of > > code. Also, changing code while John is trying to release the code is > also > > not very helpful. > > > > You don't need to trample over everything to exercise your commit privs > on > > the core. I would suggest you ask John about what specific needs have to > be > > addressed for the next release and pick on of the problems to work on > > instead of the approach you're taking. Then a specific issues will be > fixed > > and you do that a bunch of times and you'll gain far more understanding > of > > how the system works. > > > > > > I still don't know how to handle this buildFromRepository method : > >> Considering the current remote-resource-plugin releases will wail with a > >> ClassCastException I'd like to remove the unused normalize method and > >> define > >> a strong typed API - the SNAPSHOT code of remote-resource plugin is > ready > >> for this. > >> On the other side maybe it's preferable for buildFromRepository method > to > >> support this normalize process, to match the trunk. > >> > >> Nicolas > >> > >> 2009/5/4 John Casey <jdca...@commonjava.org> > >> > >> 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 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 <jdca...@commonjava.org> > >>>> > >>>> 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 <benjamin.bentm...@udo.edu> > >>>>>> > >>>>>> 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: dev-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>> > >>>>> > >>>>> > >>>>> > >>>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> > >>> > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > http://twitter.com/SonatypeNexus > > http://twitter.com/SonatypeM2E > > ---------------------------------------------------------- > > > > People develop abstractions by generalizing from concrete examples. > > Every attempt to determine the correct abstraction on paper without > > actually developing a running system is doomed to failure. No one > > is that smart. A framework is a resuable design, so you develop it by > > looking at the things it is supposed to be a design of. The more examples > > you look at, the more general your framework will be. > > > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
