incubator-amber-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: Moving OAuth leeloo from bitbucket to Apache repositories
Date Thu, 18 Nov 2010 21:33:46 GMT
Hi guys,
just after Amber started we proposed the current project structure just to
provide transparent API and implementation both for OAuth 1 and 2; what I
think at the moment is that perhaps it may be reasonable to switch to the
structure you proposed since it goes in the direction of having an
implementation released early; I'd still maintain the signature and
specification API modules as they are now.
However in the future I'd love to have one implementation which is
transparently and consistently designed for both OAuth specifications.
So in the end I am considering it as a possible solution.
What do others think?
Cheers,
Tommaso

2010/11/16 Łukasz Moreń <lukasz.moren@gmail.com>

> Hi,
>
> Thank you Simone for links, they were very helpful.
>
> I would like to create jira issues with patches for OAuth 2.0 project.
> However I have few concerns about the Amber project structure:
>
> 1. There are client, server, etc. folders in the main directory of Amber
> svn
> trunk. Maybe we should think about the structure that separates oauth 1.0
> and 2.0 implementations.
> Our proposal is following:
>
> -trunk
>      -oauth-1.0
>            -client
>            -server
>            -...
>            pom.xml
>      -oauth-2.0
>            -client
>            -authorization-server
>            -resource-server
>            -common
>            -...
>            pom.xml
>      pom.xml
>
> Main folder would contain parent pom for all oauth modules in the Amber
> project. We think it is good to separate oauth 1.0 and oauth 2.0 modules as
> it will be hard to extract common part at least at the beginning.
>
> 2. IMHO would be good to create more components in jira for oauth 2.0
> module, maybe similarly to
> what we have in the leeloo: [1]  (oauth 2.0:client, authorization server
> and
> resource server). I don't have rights to add more components.
>
> [1] http://bitbucket.org/smartproject/oauth-2.0/wiki/Home
>
> Let us know what do you think.
>
> Thanks,
> Lukasz Moren
>
> On Mon, Nov 8, 2010 at 11:36 PM, Łukasz Moreń <lukasz.moren@gmail.com
> >wrote:
>
> > It's released under Apache License Version 2.0
> >
> > Cheers,
> > Lukasz
> >
> >
> > On Mon, Nov 8, 2010 at 11:28 PM, Henry Saputra <henry.saputra@gmail.com
> >wrote:
> >
> >> Hi Łukasz,
> >>
> >> I couldnt find the licensing information about leelo from the website.
> >>
> >> What kind of license leelo support for usage?
> >>
> >> Thanks,
> >>
> >> Henry
> >>
> >>
> >> On Mon, Nov 8, 2010 at 3:43 PM, Łukasz Moreń <lukasz.moren@gmail.com>
> >> wrote:
> >> > Hi all,
> >> >
> >> > Thank you for your preliminary approval, it sounds great! I think the
> >> OAuth
> >> > implementation will benefit from being included under Apache umbrella.
> >> >
> >> > I know at least few people that are using OAuth leeloo already and
> some
> >> that
> >> > plan to use it in the near future.
> >> > We would like to move our code to Apache repositories as soon as
> >> possible
> >> > and continue development there, before (hopefully) more people start
> >> using
> >> > it.
> >> > We are currently busy with other work as well but we will try our best
> >> to do
> >> > it smoothly (and pretty soon).
> >> >
> >> > Before we move OAuth leeloo to Amber, I have few concerns:
> >> >
> >> > 1) What is the procedure at ASF for moving code into an Apache
> >> repository? I
> >> > think we should get a committer access to AMBER?
> >> > 2) We hope to keep the library name (leeloo) and package names as
> people
> >> > blogged about it, mentioned in tweets, dzone, etc?
> >> >
> >> > I'll be looking forward to your reply. Please let me know if you have
> >> any
> >> > questions or would like to adivse us about the process (licensing
> terms,
> >> > etc.).
> >> >
> >> > Cheers,
> >> > Lukasz Moren
> >> >
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Henry
> >>
> >
> >
>

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