On 28/02/2007, at 10:36 PM, Joakim Erdfelt wrote:
- [ ] BaseFile
- [ ] is this a case of premature optimisation?
Not sure I understand.
The usage of 'relative path' is immensely important within Archiva.
This is "the one true file" object that will ultimately win.
I wasn't sure how often the relative path was being used, as to
whether calculating it each time was easier and more beneficial than
the price of storing it (esp given the recent memory problems).
- [ ] Consumer
- [ ] why init? why not just in the constructor? Seems
like
a half component...
- [ ] I found it to be a confusing inheritence structure
- [ ] Better to move all consumers to a -consumers
artifact
rather than split over commons and core?
It is spread out due to 2 reasons, api -vs- usage, and to limit tight
dependencies across modules.
The consumer API is going to be split out. ( see
http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva )
cool - the split is fine, the locations just seemed odd.
I am documenting the usage of it too.
Archiva has memory problems, remember?
I found that constructing a new consumer for each and every file is
*BAD* (tm).
Also, the consumers that are used are passed into the scanner by the
calling function.
This list is different depending on the event/action.
Converter, Data Refresh Task, and On Upload Event are 3 different
places
that utilize consumers.
Right - the usage just seems a bit awkward, esp. given the 'half
component' nature. I'd need to take another look, but perhaps passing
in the 'init' things to the individual methods would be better? Are
the components thread safe currently?
hmm, ok - maybe we're on the same page (having read later)
- [ ] ConsumerFactory
- [ ] unnecessary plexus use. 'name' is never used.
I'm being brow-beaten by trygvis and jvanzyl in #plexus about this.
I'm getting educated about proper plexus usage ATM.
:)
- [ ] GenericModelConsumer
- [ ] only used in mocks?
This isn't wired up properly yet. It's a place holder for effective
pom.
cool.
- [ ] since this probably shouldn't be a component, pass
in the
builder to processFile (or wrap the artifact
repository in a container that has the builder and
artifact repo - this is more practical since
eventually it will be part of the layout anyway)
I'm reworking the whole bidirectional layout mechanism into a single
component.
I think this is what you are hinting at?
I think so.
There are 3 areas of documentation that are being worked on.
1) Architectural Design in general.
2) Database Design.
3) Javadoc on public / reusable classes.
neato
Thanks!
- Brett
