archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maria Odea Ching" <och...@apache.org>
Subject Re: Archiva 1.1 Roadmap
Date Mon, 11 Feb 2008 06:07:26 GMT
On Feb 7, 2008 7:08 PM, Brett Porter <brett@apache.org> wrote:

> I have some additions :)
>
> I also think we need to keep reviewing the types of problems people
> have and helping them diagnose them. It seems that figuring out repo
> whitelists and blacklists and the cause of proxy problems is still
> difficult - so maybe a UI configuration for the logging might be a
> good idea? Or a way to request it from a browser and get additional
> information (ie, 404 screen could capture all the logging even if it's
> not logged).


+1 :)


>
>
> Also, I'd like to finish the work of replacing the plexus runtime with
> a standalone jetty bundle that runs the war as is :)


I have a local copy of Archiva which includes the jetty-archetype you
started for this Brett, though I haven't been able to work on it lately.
I'll try to put some time to complete it and check it in as soon as I can.
Ill also file a jira to keep track of this.

Thanks,
Deng


>
>
> On 07/02/2008, at 12:16 AM, Brett Porter wrote:
>
> > These all sound good to me. Really enjoying the discussion :)
> >
> > Some comments and additions:
> >
> > On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote:
> >
> >> From the thread so far, these are the things to choose from for the
> >> 1.1roadmap:
> >>
> >> 1. Reduce memory consumption
> >> 2. Preemptive artifact synchronisation
> >> 3. Eliminate client side blocking when artifacts are being
> >> downloaded from
> >> remote repositories.
> >> 4. Ability to take repositories (both managed and remote) offline
> >> 5. Communication with remote repositories should be done
> >> asynchronously
> >> 6. Web UI for deploying artifacts
> >> 7. Plugin subsystem. We already have this for consumers but we
> >> really should
> >> have features like search, dependency graphing and browsing as
> >> plugins so we
> >> can turn bad behaving features and also give a way for users to
> >> create their
> >> own functionality.
> >> 8. Separation between managed repositories used for publishing and
> >> those
> >> used for caching artifacts from remote repositories. This
> >> separation would
> >> allow us to have:
> >>   * Provide indexing, browsing and search only for "publishing"
> >>   * RSS feeds for new artifacts in published repositories.
> >
> > I think this is something that is configurable, and set nicely by
> > default. I don't think we should completely separate proxy cache
> > managed repos from deployed repos, but having a default
> > configuration that does and recommending it is the way to go.
> >
> >>
> >> 9. Review synchronization of the configuration object
> >> 10. Improve the tests where databases are being set-up (use mock
> >> objects
> >> instead)
> >> 11. Statistical reports
> >> 12. Repository grouping
> >>
> >> Any more suggestions or comments for this? :)
> >
> > I'd just add "13. architectural simplification" - we talked about
> > some technology changes and while I don't think we need to rush into
> > any, it would be worth having them in mind if we can either
> > gradually move to them or if it becomes simpler to do than make a
> > change in the current set up. For instance, doing (10) might be
> > better at a time when we make changes to the database layer itself.
> >
> > Along these lines, architecturally I think we need to add: 14.
> > separate the subsystems better. In my view - the base system being
> > the tools (scanning, consumers, etc - with or without the database),
> > then the addition of the proxy/webdav on that (possibly without the
> > database), then the web application/visualisation on top of that
> > (this requires the databases and all other pieces of functionality).
> > We might later add web services as an option with or without the
> > webapp. These different deployment options would make it much more
> > flexible.
> >
> > Again I don't think this all needs to be done in one go - but
> > designing the target architecture and moving towards it would be a
> > good goal for 1.1 and beyond. Some of the above may actually be
> > plugins too, so we should consider the impact of that.
> >
> > Would be great to update the wiki with this list split into 1.1 and
> > beyond sections :)
> >
> >>
> >>
> >> Btw, what does everyone think of having the end of March as the
> >> target
> >> release date of 1.1?
> >
> > Great! We should probably aim to be feature complete a few weeks
> > before that then. This probably means only picking a few of the
> > above (there is a lot there!), and moving the rest to 1.2. Also need
> > to pick some important issues from the JIRA pool - as well as
> > cutting down the 60+ in there now :) We can keep working on critical
> > stuff in the 1.0.x line.
> >
> > Cheers,
> > Brett
> >
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message