Brett Porter wrote:
Well, since you asked :)
On 17/10/2007, at 2:10 PM, Joakim Erdfelt wrote:
ArchivaArtifactConsumer is an abstract-dealing-with-artifacts consumer.
RepositoryContentConsumer is for files.
A file that isn't an artifact can be *.xml, *.sha1, *.md5,
maven-metadata.xml, bad content, poorly named content, etc.
Would it be better to state the phase/scan instead?
RepositoryContentConsumer becomes -> RepositoryScanConsumer
ArchivaArtifactConsumer becomes -> DatabaseScanConsumer
These seem better, though there is still some question over even these
names. I suggest following through on Wendy's questions before jumping
ahead with anything.
And I would rather make this change now (yes Brett, I see you there)
and not have to deal with backwards compatibility issues post 1.0 "in
the wild". This time (right now) is the best time to make this
change. After the 1.0 release is just going to add misery and pain
to this process. Now is the sweet spot. We could make the change
post 1.0 but it wouldn't be a change, it would just be another
band-aide. Make the change now. Did you know that making the
change now would take less than an hour, including testing. I think
that Now is a good time. Now is the winter of our discontent. Right
now, hey, its your tomorrow. Right now, C'mon (Brett), its
everything. Right now, catch a magic moment, do it, right here and
now. It means everything. Its right now, oh, tell me what are you
waiting for, turn this thing around. :-)
I know you're somewhat kidding here, but I'm not quite sure how much,
so I'll say it anyway :)
I am not kidding, make this change now.
I'll do it. It's no big deal.
I do not agree that 1.0 is some miracle milestone of inflexibility.
For two reasons:
a) whatever in the wild milestone you are referring to should have
been at the point of beta-1, as I said in the last mail
b) it's bad thinking that things can't change after 1.0
That sounds reasonable, and a statement not based on fear of change, but ...
Frankly, I would prefer that development was done in the same fashion
whether it's 0.0.1-alpha-0, 1.0, 1.0.1, 1.1, 2.0 or Archiva 2008.
Simple, minimal public API exposure that allows maintaining
compatibility and the ability to refactor implementation details
within a module.
This statement contradicts your previous one.
What we now want to change now is a public API.
I do not want to fall into the same trap that maven fell into when it
comes to "maintaining compatibility", we have far too much in maven that
exists solely for "maintaining compatibility" that is complete and utter
cruft.
We are in that situation because of 2 major factors.
1) A hurry up and get a release out mindset.
2) A fear of changing the new APIs before a final (non-beta, non-RC,
release)
Now is the perfect time to correct this.
Lets do it now.
Lets put it up for a vote now.
Let's just define what the acceptable extension points for Archiva 1.0
are (probably consumers, so maybe you've found the one example where
it might be difficult!), document them, and commit to maintaining them
and move forward in that way.
- Brett
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
