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
