archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: Thoughts on Archiva changes
Date Thu, 01 Mar 2007 03:44:16 GMT
On 2/28/07, Joakim Erdfelt <joakim@erdfelt.com> wrote:
> Brett Porter wrote:
> > Hi,
> >
> > I put these together the other day - any thoughts?
> >
> > Topic
> > - [ ] Recent changes
> >     - [ ] archiva-common
> >         - [ ] PathUtil
> >             - [ ] doesn't this already exist in plexus-utils/commons-io?
> Oddly enough, no.
> And I plan on removing that utility anyway.  It's use is diminishing in
> favor of BaseFile.
> >         - [ ] 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.

While trying to build the project the other day and running to some
failing tests on this class on Windows, I was actually thinking the
same thing

I think I understand what Joakim is saying though, there's a need for
a canonical artifact representation. However, I think the problem with
the BaseFile is that it extends from File, which seems to negate the
portability. For example, all of the current tests fail on the Windows
platform because the behavior of File on Windows is to automatically
inject drive letters for "absolute" paths. See MRM-292 [1] for more on
that.

I would suggest avoiding the File class altogether and define a
Resource class or Artifact class that works with a canonical
definition of repository paths. That definition would essentially be
the resource path definition of HTTP.

To facilitate working with the underlying or even remote resources,
utility methods like "toURI", "toURL" and "toFile" could be defined.

-Nathan

[1] http://jira.codehaus.org/browse/MRM-292

> >         - [ ] 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 )
>
> 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.
> >         - [ ] 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.
> >         - [ ] GenericArtifactConsumer
> >             - [ ] should use plexus requirements to get the builders as
> >                   a map
> Just learned about plexus Map requirement mapping.  I could make the
> change, but (see next) ...
> >             - [ ] 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?
> >         - [ ] ManagedArtifactTypes
> >             - [ ] this should be able to be achieved with the
> >                   existing metadata from the ArtifactTypeHandler in
> >                   maven-artifact, rather than duplicating the types of
> >                   attachments (with the addition of the javadoc and
> >                   sources attachments which could be managed in Archiva)
> Agreed.  I'll look into it.
> >     - [ ] archiva-core
> >         - [ ] RepositoryTask
> >             - [ ] put policies into plexus-taskqueue?
> >         - [ ] DataRefreshExecutor
> >             - [ ] consumers should be a list requirement directly from
> >                   plexus, no need for wrapper class
> The wrapper class is there to limit the amount of copy/paste <component>
> garbage between
> archiva-core and archiva-webapp's application.xml
> >     - [ ] archiva-reports-standard
> >         - [ ] better to use string representation for key than
> >               [Artifact|Metadata]ResultsKey?
> >         - [ ] ReportingDatabase should be an interface, proper
> >               components
> >         - [ ] why is getting the number of failures, etc resource
> >               intensive? Because not all loaded at once?
> >         - [ ] ArtifactResultsDatabase has strange component declaration
> >               vs inheritence.
> >         - [ ] ARD is JDO specific. (this may have been fixed in
> > archiva-database, haven't looked yet)
> >         - [ ] split into database, database-jdo and reports-standard,
> >               reports-other, etc.
> >         - [ ] is there an interface trigger for re-generating the
> >               reports in case the data gets out of sync?
> This whole module is undergoing a gutting.
> The work being done in archiva-database invalidates huge portions of
> this module.
> >     - [ ] General
> >         - [ ] Some design notes needed / existing ones updated, and
> > more javadoc particularly
> >               for the reusable classes
> 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.
> > - [ ] Old Stuff
> >     - [ ] archiva-converter
> >         - [ ] FileTransaction seems duplicated with various
> > transaction events (though both are used)
> >         - [ ] legacy converter is in separate package, but default
> > repository converter is not.
> >         - [ ] check for code duplication between legacy and default
> > converters
> 90% of this code has been recently moved to maven-artifact-converter and
> maven-transaction.
> https://svn.apache.org/repos/asf/maven/shared/trunk/maven-artifact-converter/
> https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction/
>
> That module will be gutted shortly.
>
>
>
>

Mime
View raw message