Hi all, 2010/6/15 Simone Tripodi <[email protected]>
> 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 interfaces. > > > 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 jars. 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 :) > cool! Simone
