Amber, being an Apache project, should use the org.apache.amber namespace and adhere to the Apache way<http://incubator.apache.org/learn/theapacheway.html> .
There's no reason why this particular implementation should be the "standard" unless you want to go through the trouble of going through the JCP and making a JSR. Instead focus on making this implementation the best it can be, with the best support of the standard and with the most vibrant community. Regarding packaging - the simplest way going forward is to bundle all the interfaces and domain objects into amber-*-api packages and have corresponding amber-*-impl packages. On Tue, Jun 15, 2010 at 9:23 AM, Pid <[email protected]> wrote: > On 15/06/2010 16:43, Tommaso Teofili wrote: > > Hi all, > > > > 2010/6/15 Pid <[email protected] <mailto:[email protected]>> > > > > On 15/06/2010 10:28, Simone Tripodi wrote: > > > 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 :( > > > > The project proposal included a clear statement that the API spec > would > > be available to others wanting to create an alternative > implementation. > > There were no objections to this in principal. > > > > > > Pid, I read in the proposal that we're going to deal with "allowing > > re-use by other developers", and I am fully committed to it, not to > > I'm not sure I understand? > > The proposal is clear about the API spec being developed as a separate > component/package*. We'd then develop an implementation (and some > extras) against that API spec. > > > > develop an (alternative) API to contribute back to OAuth WG, and > > basically I couldn't see any reason for doing that. > > Just my opinion. > > Tommaso > > We'd only propose the API specification back to the OAuth WG (not the > implementation). In order to promote re-use we'd basically have to > propose it back to OAuth, no? (That's not to say that they'd welcome it > with open arms, they might of course completely reject it...) > > Otherwise, we're just building "Yet Another Java OAuth Implementation". > > > p > > > * Probably "org.apache.amber", maybe "net.oauth" later. > > > >
