archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Archiva 1.1 Roadmap
Date Fri, 15 Feb 2008 07:45:40 GMT
Thanks for putting the roadmap [1] in place Deng - I made a couple of  
cleanups and did a quick run through JIRA as well.

I think we still need to cut back on the features for 1.1, since  
there's 62 issues in there... do we just timebox, or do we pick some  
features for 1.2 now?

Cheers,
Brett

[1] http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap

On 11/02/2008, at 5:07 PM, Maria Odea Ching wrote:

> 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/
>>
>>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


Mime
View raw message