2010/6/15 Simone Tripodi <[email protected]> > +1 for the maven site, simple to use and easy to customize. I'm not a > web designer but I'm able to create maven skins, looking forward to > find a nice template if everybody agrees. >
+1 for the Maven site (and skinning) :) > All the best, > Simo > > http://people.apache.org/~simonetripodi/ > > > > On Tue, Jun 15, 2010 at 9:50 AM, Simone Gianni <[email protected]> wrote: > > Hi Tommaso, > > regarding docs there are three "areas" : > > - javadocs, and they will be in the code, together with proper > package.html > > files with a lot of explanations :D > > - tutorials, howtos, a long manual, whatever else > > - project site, with few words of presentation, news etc.. > > > > Regarding the second documentation area, I think that it would be better > to > > have it in cwiki or a similar cooperation platform. The advantages are : > > - we don't have to reinvent (or even choose) a documentation format > > - it's open to users to help writing it > > > > Regarding the site, I'd go with Maven site. > > > > WDYT? > I agree for going the wiki way, I think that some written sample code will be helpful for attracting new users/developers and let them use Amber in a small cycle. But, hey, let's have some stable codebase to be used first :-) Cheers, Tommaso > > > > Simone > > > > 2010/6/15 Tommaso Teofili <[email protected]> > > > >> Hi all, > >> > >> 2010/6/14 Simone Tripodi <[email protected]> > >> > >> > Hi Simo, > >> > thanks!!! > >> > > >> > My 2 cents how I envisioned Amber modules: > >> > > >> > - signature-api: contains all consumer/provider common stuff about the > >> > signature algorithms to sign/verify oauth signatures (already working > >> > at 85% I just need to fix the RSA support, I could stay focused on > >> > that); > >> > - consumer: oauth api specification with extensions entry points (like > >> > Oauth Signpost[1]); > >> > - provider: oauth api specification with extensions entry points > >> > (default in-memory data structure can be replaced by custom > >> > implementations); > >> > - discovery: consumer/provider common stuff to interact with oauth > >> > discovery protocol; previouses 2 modules shall not depend by this > >> > module at all; > >> > - extensions: 3rd parts integrations, like: > >> > - consumer api & known http clients integration; > >> > - provider & spring-security integration; > >> > - consumer & provider google-guice (I'm addicted to it :P) > >> > - applications: > >> > - provider web application with control panel (manage consumer > >> > keys, revoke consumers authorizations, configure entry points, ...); > >> > - consumer web application with control panel (manage consumer > >> > keys, revoke users authorizations, ...); > >> > > >> > How does it look like? I hope you'll like it! > >> > All the best!!! > >> > Simo > >> > > >> > >> I like that and sounds a good starting point to me. > >> I'd like to see also a separate module for examples and tutorials to > >> explain > >> users/devs how Amber could be useful to them :) > >> By the way, maybe we should discuss (later?) options about how we > provide > >> documentation (Maven site, xdocs or static html). > >> Cheers, > >> Tommaso > >> > >> > >> > >> > >> > > >> > [1] http://code.google.com/p/oauth-signpost/ > >> > > >> > http://people.apache.org/~simonetripodi/< > http://people.apache.org/%7Esimonetripodi/> > >> > > >> > > >> > > >> > On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <[email protected]> > >> > wrote: > >> > > Hi Simone, > >> > > don't worry, it happens to be busy :) > >> > > > >> > > Could we start by simply writing a "list" of "things" (modules, > >> > extensions) > >> > > that we'd like to see in Amber? > >> > > > >> > > Then we can move this to wiki, sort them in a "roadmap", decide what > >> goes > >> > in > >> > > "core" and what in optional modules etc... but still, could everyone > >> > write > >> > > what he would expect to find when checking out Amber? > >> > > > >> > > Simone > >> > > > >> > > >> > > >
