oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: Roadmap
Date Tue, 15 Jun 2010 11:20:45 GMT
Hi all,

2010/6/15 Simone Tripodi <simone.tripodi@gmail.com>

> Hi all guys,
> >
> > 1. API in "net.oauth." (to be contributed back to the OAuth WG)
> My opinion is -1 for the "net.oauth" package since seems to me a
> little out of scopes. Please don't take it personally, but AFAIK we're
> not allowed to use Apache Incubator as a forge where we could create a
> codebase to contribute to some else, maybe our Mentors could explain
> us better :(
> It would be different if OAuth.net already defined an API spec, like
> for example the JAX-RS spec that comes from a JSR.

Yes, we could provide a net.oauth package but probably we should coordinate
this with oauth group and after having received approval from mentors.

The subject of the mail with which we (Pid) presented the idea on the OAuth
IETF mailing list was "Standardisation of a Java API", so I think it could
fit in a non-org-apache package as long as we are dealing only with

> > 2. Core implementation
> does everybody shares the same vision of how modules should be
> separated? I'd ask and wait a general consensus before starting
> working, as people is used to in Apache...

I like subdividing in as many modules as possible. Maven makes it easy to
work with them, a Maven project willing to use Amber will just have to
depend on the module he needs (for example only the consumer module) and
Maven will carry all other dependencies automatically.

Even for non Maven projects, it is possible to create meta-modules that
simply carry all or not all of the other modules and deploy them as single

So, from an "Amber user" point of view, visibility on how modules are
organized is quite opaque, as long as you don't need to depend only on one
specific module, like for example only on the API interfaces, or only the
key crypt part cause, in which case it is a problem to extract out only the
part you need. That's why I love projects with small modules :)

> > 3. Example "instant OAuth server" (.war)
> Cool :)



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