You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Olivier Lamy <ol...@apache.org> on 2011/08/03 17:50:03 UTC
Archiva refactoring
Hi Folks,
I'd like to continue working on the refactoring. Most of the part
(removing plexus stuff is mostly done).
Now the next step is probably to expose our apis (redback, archiva)
tru REST services.
IMHO with this we will be able to refactor ui more easily (and maybe
write different ui technologies)
I think about using cxf (ASF dogfood)
No objections ? (btw I will start first with redback)
Thanks
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Benson Margulies <bi...@gmail.com>.
I can help with cxf if you need it.
On Aug 3, 2011, at 11:50 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hi Folks,
> I'd like to continue working on the refactoring. Most of the part
> (removing plexus stuff is mostly done).
> Now the next step is probably to expose our apis (redback, archiva)
> tru REST services.
> IMHO with this we will be able to refactor ui more easily (and maybe
> write different ui technologies)
> I think about using cxf (ASF dogfood)
> No objections ? (btw I will start first with redback)
>
> Thanks
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
2011/8/22 Brett Porter <br...@apache.org>:
>
> On 20/08/2011, at 3:33 AM, Olivier Lamy wrote:
>
>>>
>>> Is this duplication of "remote" type code, or business logic? I would have thought the actual remote stuff would be a pretty thin layer, and that most would live in search or the repository API, or a "repository admin API" (which is probably a combination of the current configuration module + the code that is in the web app now)
>>
>> dupe are wrappers and some thin logic (bean/datas validation too).
>> Have a look at the addManagedRepo part in webapp and xmlrpc (and now
>> in rest part :-) )
>> BTW not critical or a big issue just a cleanup to do :-).
>> That's why I wanted to move some of those dups in a new module
>> (archiva-remote-layer ? Maye I'm not really good enough in marketing
>> to find the good name :-) )
>> Let me know
>
> A lot of this particular one is staging, which I aim to reduce (I'm part way through removing the additional managed repository configuration as it should be implicit).
>
> I do think most of this is the repository admin, so a repository admin API would make sense…
>
> ManagedRepositoryAdmin.createManagedRepository(…)
> ManagedRepositoryAdmin.deleteManagedRepository(…)
> RemoteRepositoryAdmin.create...
> … etc.
>
> That's instead of calling it a "remote layer" - because a lot of this has nothing to do with being remote (except that a user requested it… but a Java app embedding Archiva could request these too).
>
> The tricky bit is perhaps that security is isolated to the web modules at the moment, and these modules to cover security operations too - these could either stay in the current code (if it's a 1-liner), or be added to archiva-security I guess.
>
> Does that make sense?
Yup makes sense.
Will reduce the job by just doing/adding some wrappers and configuring
security things.
I will start creating the module.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Brett Porter <br...@apache.org>.
On 20/08/2011, at 3:33 AM, Olivier Lamy wrote:
>>
>> Is this duplication of "remote" type code, or business logic? I would have thought the actual remote stuff would be a pretty thin layer, and that most would live in search or the repository API, or a "repository admin API" (which is probably a combination of the current configuration module + the code that is in the web app now)
>
> dupe are wrappers and some thin logic (bean/datas validation too).
> Have a look at the addManagedRepo part in webapp and xmlrpc (and now
> in rest part :-) )
> BTW not critical or a big issue just a cleanup to do :-).
> That's why I wanted to move some of those dups in a new module
> (archiva-remote-layer ? Maye I'm not really good enough in marketing
> to find the good name :-) )
> Let me know
A lot of this particular one is staging, which I aim to reduce (I'm part way through removing the additional managed repository configuration as it should be implicit).
I do think most of this is the repository admin, so a repository admin API would make sense…
ManagedRepositoryAdmin.createManagedRepository(…)
ManagedRepositoryAdmin.deleteManagedRepository(…)
RemoteRepositoryAdmin.create...
… etc.
That's instead of calling it a "remote layer" - because a lot of this has nothing to do with being remote (except that a user requested it… but a Java app embedding Archiva could request these too).
The tricky bit is perhaps that security is isolated to the web modules at the moment, and these modules to cover security operations too - these could either stay in the current code (if it's a 1-liner), or be added to archiva-security I guess.
Does that make sense?
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
2011/8/19 Brett Porter <br...@apache.org>:
>
> On 19/08/2011, at 8:29 PM, Olivier Lamy wrote:
>
>> FYI note on progress :-)
>>
>> So I'm focused on REST support and OSGI stuff (some features added in
>> maven indexer for osgi metadatas indexing).
>> REST support move slowly as I have to take care of some code done in
>> webapp rather than in services and redback karma on services.
>>
>> And to be able to have a good set of unit test, I have to provide
>> first some admin services before rest search services.
>>
>> Note as there is a large code duplication in xmlrpc and current rest
>> stuff, I think about creating a common modules which will contains
>> base remote services code (a name like : common-remote-services or an
>> other if someone has a better idea :-) )
>
> Is this duplication of "remote" type code, or business logic? I would have thought the actual remote stuff would be a pretty thin layer, and that most would live in search or the repository API, or a "repository admin API" (which is probably a combination of the current configuration module + the code that is in the web app now)
dupe are wrappers and some thin logic (bean/datas validation too).
Have a look at the addManagedRepo part in webapp and xmlrpc (and now
in rest part :-) )
BTW not critical or a big issue just a cleanup to do :-).
That's why I wanted to move some of those dups in a new module
(archiva-remote-layer ? Maye I'm not really good enough in marketing
to find the good name :-) )
Let me know
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Brett Porter <br...@apache.org>.
On 19/08/2011, at 8:29 PM, Olivier Lamy wrote:
> FYI note on progress :-)
>
> So I'm focused on REST support and OSGI stuff (some features added in
> maven indexer for osgi metadatas indexing).
> REST support move slowly as I have to take care of some code done in
> webapp rather than in services and redback karma on services.
>
> And to be able to have a good set of unit test, I have to provide
> first some admin services before rest search services.
>
> Note as there is a large code duplication in xmlrpc and current rest
> stuff, I think about creating a common modules which will contains
> base remote services code (a name like : common-remote-services or an
> other if someone has a better idea :-) )
Is this duplication of "remote" type code, or business logic? I would have thought the actual remote stuff would be a pretty thin layer, and that most would live in search or the repository API, or a "repository admin API" (which is probably a combination of the current configuration module + the code that is in the web app now)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
FYI note on progress :-)
So I'm focused on REST support and OSGI stuff (some features added in
maven indexer for osgi metadatas indexing).
REST support move slowly as I have to take care of some code done in
webapp rather than in services and redback karma on services.
And to be able to have a good set of unit test, I have to provide
first some admin services before rest search services.
Note as there is a large code duplication in xmlrpc and current rest
stuff, I think about creating a common modules which will contains
base remote services code (a name like : common-remote-services or an
other if someone has a better idea :-) )
Regarding documentation of available rest services, I will probably
work with cxf folks to generate some pages tru a maven plugin (see [1]
)
All comments are welcome :-)
Thanks,
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
[1] https://issues.apache.org/jira/browse/CXF-3731
2011/8/12 Olivier Lamy <ol...@apache.org>:
> Hi,
> FYI regarding REST support I have started to work on that in redback
> trunk for authz/karma on rest requests.
>
> Some docs are available here : http://redback.codehaus.org/integration/rest.html
>
>
> 2011/8/5 Brett Porter <br...@apache.org>:
>> Thanks Olivier, I'll try and look at updating the page over the weekend.
>>
>> - Brett
>>
>> On 05/08/2011, at 2:56 AM, Olivier Lamy wrote:
>>
>>> Hello,
>>> I have started add content in
>>> https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap .
>>> Next step I will create related jira entries and probably related page
>>> for some items.
>>>
>>> Feel free to fix content in the page and/or add comments.
>>>
>>> 2011/8/4 Brett Porter <br...@apache.org>:
>>>>
>>>> On 04/08/2011, at 8:33 AM, Olivier Lamy wrote:
>>>>
>>>>> 2011/8/3 Brett Porter <br...@apache.org>:
>>>>>>
>>>>>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>>>>>
>>>>>>> Hi Folks,
>>>>>>> I'd like to continue working on the refactoring. Most of the part
>>>>>>> (removing plexus stuff is mostly done).
>>>>>>
>>>>>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>>>>>
>>>>> Nothing except more testing and releasing redback and companions.
>>>>
>>>> Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress.
>>>>
>>>>>
>>>>> what the bugs regarding metadata ?
>>>>
>>>> Things I broke with changes to the repository API :)
>>>>
>>>>>
>>>>>>> Now the next step is probably to expose our apis (redback, archiva)
>>>>>>> tru REST services.
>>>>>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>>>>>> write different ui technologies)
>>>>>>
>>>>>> Cool!
>>>>>>
>>>>>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>>>>>
>>>>> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
>>>>> stay. No real ideas about who consume those.
>>>>
>>>> I'm using them, so I can help make sure they still work at least for the next release.
>>>>
>>>>>>
>>>>>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
>>>>> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
>>>>> My idea is to expose services on both xml and json.
>>>>
>>>> Great - was going to suggest both those things.
>>>>
>>>>>>
>>>>>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
>>>>> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>>>>>
>>>>> An other idea I have is to provide a tomcat install rather than the
>>>>> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
>>>>> for testing) and/or something easy to install/run with a simple : java
>>>>> -jar archiva.war :-)
>>>>
>>>> Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine.
>>>>
>>>>>
>>>>>
>>>>> BTW my plan is to start with redback. (with providing sample ui with
>>>>> other techs).
>>>>>
>>>>> At the end we will have to choose the ui tech we will use.
>>>>> As I remember we talked about gwt or vaadin.
>>>>> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
>>>>
>>>> I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy.
>>>>
>>>>> And with this there is the question about this plugin mechanism
>>>>> (dynamic or not ?).
>>>>> If dynamic the only solution will be using osgi (but a more long term
>>>>> feature :-) ).
>>>>
>>>> This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up...
>>>>
>>>>>
>>>>> An other long term is to move to shiro to not have to maintain redback.
>>>>>
>>>>
>>>> Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier.
>>>>
>>>>> Sure a lot of ideas !. Now time to do at least a small percentage :-)
>>>>
>>>>
>>>> On 04/08/2011, at 8:52 AM, Olivier Lamy wrote:
>>>>
>>>>> I will sum up this here
>>>>> https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
>>>>>
>>>>> (after sleeping :-) )
>>>>
>>>> Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap
>>>>
>>>> Thanks!
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>> http://au.linkedin.com/in/brettporter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend : http://talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
FYI regarding REST support I have started to work on that in redback
trunk for authz/karma on rest requests.
Some docs are available here : http://redback.codehaus.org/integration/rest.html
2011/8/5 Brett Porter <br...@apache.org>:
> Thanks Olivier, I'll try and look at updating the page over the weekend.
>
> - Brett
>
> On 05/08/2011, at 2:56 AM, Olivier Lamy wrote:
>
>> Hello,
>> I have started add content in
>> https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap .
>> Next step I will create related jira entries and probably related page
>> for some items.
>>
>> Feel free to fix content in the page and/or add comments.
>>
>> 2011/8/4 Brett Porter <br...@apache.org>:
>>>
>>> On 04/08/2011, at 8:33 AM, Olivier Lamy wrote:
>>>
>>>> 2011/8/3 Brett Porter <br...@apache.org>:
>>>>>
>>>>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>> I'd like to continue working on the refactoring. Most of the part
>>>>>> (removing plexus stuff is mostly done).
>>>>>
>>>>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>>>>
>>>> Nothing except more testing and releasing redback and companions.
>>>
>>> Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress.
>>>
>>>>
>>>> what the bugs regarding metadata ?
>>>
>>> Things I broke with changes to the repository API :)
>>>
>>>>
>>>>>> Now the next step is probably to expose our apis (redback, archiva)
>>>>>> tru REST services.
>>>>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>>>>> write different ui technologies)
>>>>>
>>>>> Cool!
>>>>>
>>>>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>>>>
>>>> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
>>>> stay. No real ideas about who consume those.
>>>
>>> I'm using them, so I can help make sure they still work at least for the next release.
>>>
>>>>>
>>>>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
>>>> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
>>>> My idea is to expose services on both xml and json.
>>>
>>> Great - was going to suggest both those things.
>>>
>>>>>
>>>>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
>>>> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>>>>
>>>> An other idea I have is to provide a tomcat install rather than the
>>>> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
>>>> for testing) and/or something easy to install/run with a simple : java
>>>> -jar archiva.war :-)
>>>
>>> Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine.
>>>
>>>>
>>>>
>>>> BTW my plan is to start with redback. (with providing sample ui with
>>>> other techs).
>>>>
>>>> At the end we will have to choose the ui tech we will use.
>>>> As I remember we talked about gwt or vaadin.
>>>> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
>>>
>>> I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy.
>>>
>>>> And with this there is the question about this plugin mechanism
>>>> (dynamic or not ?).
>>>> If dynamic the only solution will be using osgi (but a more long term
>>>> feature :-) ).
>>>
>>> This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up...
>>>
>>>>
>>>> An other long term is to move to shiro to not have to maintain redback.
>>>>
>>>
>>> Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier.
>>>
>>>> Sure a lot of ideas !. Now time to do at least a small percentage :-)
>>>
>>>
>>> On 04/08/2011, at 8:52 AM, Olivier Lamy wrote:
>>>
>>>> I will sum up this here
>>>> https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
>>>>
>>>> (after sleeping :-) )
>>>
>>> Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap
>>>
>>> Thanks!
>>>
>>> - Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> http://au.linkedin.com/in/brettporter
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend : http://talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Brett Porter <br...@apache.org>.
Thanks Olivier, I'll try and look at updating the page over the weekend.
- Brett
On 05/08/2011, at 2:56 AM, Olivier Lamy wrote:
> Hello,
> I have started add content in
> https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap .
> Next step I will create related jira entries and probably related page
> for some items.
>
> Feel free to fix content in the page and/or add comments.
>
> 2011/8/4 Brett Porter <br...@apache.org>:
>>
>> On 04/08/2011, at 8:33 AM, Olivier Lamy wrote:
>>
>>> 2011/8/3 Brett Porter <br...@apache.org>:
>>>>
>>>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>>>
>>>>> Hi Folks,
>>>>> I'd like to continue working on the refactoring. Most of the part
>>>>> (removing plexus stuff is mostly done).
>>>>
>>>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>>>
>>> Nothing except more testing and releasing redback and companions.
>>
>> Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress.
>>
>>>
>>> what the bugs regarding metadata ?
>>
>> Things I broke with changes to the repository API :)
>>
>>>
>>>>> Now the next step is probably to expose our apis (redback, archiva)
>>>>> tru REST services.
>>>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>>>> write different ui technologies)
>>>>
>>>> Cool!
>>>>
>>>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>>>
>>> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
>>> stay. No real ideas about who consume those.
>>
>> I'm using them, so I can help make sure they still work at least for the next release.
>>
>>>>
>>>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
>>> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
>>> My idea is to expose services on both xml and json.
>>
>> Great - was going to suggest both those things.
>>
>>>>
>>>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
>>> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>>>
>>> An other idea I have is to provide a tomcat install rather than the
>>> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
>>> for testing) and/or something easy to install/run with a simple : java
>>> -jar archiva.war :-)
>>
>> Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine.
>>
>>>
>>>
>>> BTW my plan is to start with redback. (with providing sample ui with
>>> other techs).
>>>
>>> At the end we will have to choose the ui tech we will use.
>>> As I remember we talked about gwt or vaadin.
>>> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
>>
>> I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy.
>>
>>> And with this there is the question about this plugin mechanism
>>> (dynamic or not ?).
>>> If dynamic the only solution will be using osgi (but a more long term
>>> feature :-) ).
>>
>> This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up...
>>
>>>
>>> An other long term is to move to shiro to not have to maintain redback.
>>>
>>
>> Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier.
>>
>>> Sure a lot of ideas !. Now time to do at least a small percentage :-)
>>
>>
>> On 04/08/2011, at 8:52 AM, Olivier Lamy wrote:
>>
>>> I will sum up this here
>>> https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
>>>
>>> (after sleeping :-) )
>>
>> Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap
>>
>> Thanks!
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
I have started add content in
https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap .
Next step I will create related jira entries and probably related page
for some items.
Feel free to fix content in the page and/or add comments.
2011/8/4 Brett Porter <br...@apache.org>:
>
> On 04/08/2011, at 8:33 AM, Olivier Lamy wrote:
>
>> 2011/8/3 Brett Porter <br...@apache.org>:
>>>
>>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>>
>>>> Hi Folks,
>>>> I'd like to continue working on the refactoring. Most of the part
>>>> (removing plexus stuff is mostly done).
>>>
>>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>>
>> Nothing except more testing and releasing redback and companions.
>
> Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress.
>
>>
>> what the bugs regarding metadata ?
>
> Things I broke with changes to the repository API :)
>
>>
>>>> Now the next step is probably to expose our apis (redback, archiva)
>>>> tru REST services.
>>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>>> write different ui technologies)
>>>
>>> Cool!
>>>
>>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>>
>> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
>> stay. No real ideas about who consume those.
>
> I'm using them, so I can help make sure they still work at least for the next release.
>
>>>
>>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
>> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
>> My idea is to expose services on both xml and json.
>
> Great - was going to suggest both those things.
>
>>>
>>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
>> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>>
>> An other idea I have is to provide a tomcat install rather than the
>> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
>> for testing) and/or something easy to install/run with a simple : java
>> -jar archiva.war :-)
>
> Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine.
>
>>
>>
>> BTW my plan is to start with redback. (with providing sample ui with
>> other techs).
>>
>> At the end we will have to choose the ui tech we will use.
>> As I remember we talked about gwt or vaadin.
>> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
>
> I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy.
>
>> And with this there is the question about this plugin mechanism
>> (dynamic or not ?).
>> If dynamic the only solution will be using osgi (but a more long term
>> feature :-) ).
>
> This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up...
>
>>
>> An other long term is to move to shiro to not have to maintain redback.
>>
>
> Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier.
>
>> Sure a lot of ideas !. Now time to do at least a small percentage :-)
>
>
> On 04/08/2011, at 8:52 AM, Olivier Lamy wrote:
>
>> I will sum up this here
>> https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
>>
>> (after sleeping :-) )
>
> Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap
>
> Thanks!
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Brett Porter <br...@apache.org>.
On 04/08/2011, at 8:33 AM, Olivier Lamy wrote:
> 2011/8/3 Brett Porter <br...@apache.org>:
>>
>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>
>>> Hi Folks,
>>> I'd like to continue working on the refactoring. Most of the part
>>> (removing plexus stuff is mostly done).
>>
>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>
> Nothing except more testing and releasing redback and companions.
Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress.
>
> what the bugs regarding metadata ?
Things I broke with changes to the repository API :)
>
>>> Now the next step is probably to expose our apis (redback, archiva)
>>> tru REST services.
>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>> write different ui technologies)
>>
>> Cool!
>>
>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>
> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
> stay. No real ideas about who consume those.
I'm using them, so I can help make sure they still work at least for the next release.
>>
>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
> My idea is to expose services on both xml and json.
Great - was going to suggest both those things.
>>
>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>
> An other idea I have is to provide a tomcat install rather than the
> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
> for testing) and/or something easy to install/run with a simple : java
> -jar archiva.war :-)
Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine.
>
>
> BTW my plan is to start with redback. (with providing sample ui with
> other techs).
>
> At the end we will have to choose the ui tech we will use.
> As I remember we talked about gwt or vaadin.
> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy.
> And with this there is the question about this plugin mechanism
> (dynamic or not ?).
> If dynamic the only solution will be using osgi (but a more long term
> feature :-) ).
This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up...
>
> An other long term is to move to shiro to not have to maintain redback.
>
Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier.
> Sure a lot of ideas !. Now time to do at least a small percentage :-)
On 04/08/2011, at 8:52 AM, Olivier Lamy wrote:
> I will sum up this here
> https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
>
> (after sleeping :-) )
Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap
Thanks!
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
I will sum up this here
https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev
(after sleeping :-) )
2011/8/4 Olivier Lamy <ol...@apache.org>:
> 2011/8/3 Brett Porter <br...@apache.org>:
>>
>> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>>
>>> Hi Folks,
>>> I'd like to continue working on the refactoring. Most of the part
>>> (removing plexus stuff is mostly done).
>>
>> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>>
> Nothing except more testing and releasing redback and companions.
>
> what the bugs regarding metadata ?
>
>>> Now the next step is probably to expose our apis (redback, archiva)
>>> tru REST services.
>>> IMHO with this we will be able to refactor ui more easily (and maybe
>>> write different ui technologies)
>>
>> Cool!
>>
>> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
>
> Perso I'd like to remove xmlrpc ones :-). But if it's used they can
> stay. No real ideas about who consume those.
>
>>
>> You will find as you go that there is some struts actions with too much logic in them, and some where the code is duplicated in the xmlrpc that will need refactoring.
>>
>> I'd like to make sure this effort keeps trunk working, though :) Hopefully it has less impact.
> ouch :-)) Sure should more easy/transparent than the previous
> refactoring on plexus.
>>
>> For redback - what parts are you going to expose as REST? That might be a good place to be selective so we can consider chopping some parts out.
> Agree we have to create a list for that.
>>
>>> I think about using cxf (ASF dogwood)
>>
>> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
> Yup that's the goal to use standard jax-rs (and NOT spring annotations)
> My idea is to expose services on both xml and json.
>>
>> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
> Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
>
> An other idea I have is to provide a tomcat install rather than the
> jetty (asf dogfood again), an "embeded" archiva version (ie runnable
> for testing) and/or something easy to install/run with a simple : java
> -jar archiva.war :-)
>
>
> BTW my plan is to start with redback. (with providing sample ui with
> other techs).
>
> At the end we will have to choose the ui tech we will use.
> As I remember we talked about gwt or vaadin.
> IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
> And with this there is the question about this plugin mechanism
> (dynamic or not ?).
> If dynamic the only solution will be using osgi (but a more long term
> feature :-) ).
>
> An other long term is to move to shiro to not have to maintain redback.
>
> Sure a lot of ideas !. Now time to do at least a small percentage :-)
>
>>
>>> No objections ? (btw I will start first with red back)
>>
>> +1
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Olivier Lamy <ol...@apache.org>.
2011/8/3 Brett Porter <br...@apache.org>:
>
> On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
>
>> Hi Folks,
>> I'd like to continue working on the refactoring. Most of the part
>> (removing plexus stuff is mostly done).
>
> What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
>
Nothing except more testing and releasing redback and companions.
what the bugs regarding metadata ?
>> Now the next step is probably to expose our apis (redback, archiva)
>> tru REST services.
>> IMHO with this we will be able to refactor ui more easily (and maybe
>> write different ui technologies)
>
> Cool!
>
> Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
Perso I'd like to remove xmlrpc ones :-). But if it's used they can
stay. No real ideas about who consume those.
>
> You will find as you go that there is some struts actions with too much logic in them, and some where the code is duplicated in the xmlrpc that will need refactoring.
>
> I'd like to make sure this effort keeps trunk working, though :) Hopefully it has less impact.
ouch :-)) Sure should more easy/transparent than the previous
refactoring on plexus.
>
> For redback - what parts are you going to expose as REST? That might be a good place to be selective so we can consider chopping some parts out.
Agree we have to create a list for that.
>
>> I think about using cxf (ASF dogwood)
>
> I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
Yup that's the goal to use standard jax-rs (and NOT spring annotations)
My idea is to expose services on both xml and json.
>
> My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ).
An other idea I have is to provide a tomcat install rather than the
jetty (asf dogfood again), an "embeded" archiva version (ie runnable
for testing) and/or something easy to install/run with a simple : java
-jar archiva.war :-)
BTW my plan is to start with redback. (with providing sample ui with
other techs).
At the end we will have to choose the ui tech we will use.
As I remember we talked about gwt or vaadin.
IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin.
And with this there is the question about this plugin mechanism
(dynamic or not ?).
If dynamic the only solution will be using osgi (but a more long term
feature :-) ).
An other long term is to move to shiro to not have to maintain redback.
Sure a lot of ideas !. Now time to do at least a small percentage :-)
>
>> No objections ? (btw I will start first with red back)
>
> +1
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva refactoring
Posted by Brett Porter <br...@apache.org>.
On 04/08/2011, at 1:50 AM, Olivier Lamy wrote:
> Hi Folks,
> I'd like to continue working on the refactoring. Most of the part
> (removing plexus stuff is mostly done).
What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out?
> Now the next step is probably to expose our apis (redback, archiva)
> tru REST services.
> IMHO with this we will be able to refactor ui more easily (and maybe
> write different ui technologies)
Cool!
Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there?
You will find as you go that there is some struts actions with too much logic in them, and some where the code is duplicated in the xmlrpc that will need refactoring.
I'd like to make sure this effort keeps trunk working, though :) Hopefully it has less impact.
For redback - what parts are you going to expose as REST? That might be a good place to be selective so we can consider chopping some parts out.
> I think about using cxf (ASF dogwood)
I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch?
My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :)
> No objections ? (btw I will start first with red back)
+1
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter