Noel J. Bergman wrote:
Done: Added it as the first link of "Related Projects". I don't like this too much but it is better than nothing, and we should find a consistent way to publish all of the projects (mime4j, postage, jsieve..)

Agreed on all counts.  Neither one of us likes the current situation, but agree 
that doing this is better than not.

Sunny day and I'm sick, so I took some time to look at maven2 generation and css.

I created a css for maven2 generated site, that is different from James current style but I think it is something in the middle between Maven2 style and current James style.

Currently I'm happy with the result:
http://people.apache.org/~bago/james/looktest/
http://people.apache.org/~bago/james/looktest/jspf/

For that test I'm generating both James server and James jspf via maven2, and imo this is the way to go.

About the look I'm happy with it and I think this is consistent and looks better than both default maven and our current site.

About the structure this currently improves only the multisite navigation (via horizontabl bar for projects) but this is the issue where maven2 can be of help and that deserve more work.

About the look (skin) jSPF site is generated throught maven2. Maven2 has various level of customizability for its site generation tool.

What we could try to do is to create a maven2 skin that somewhat remember the current apache website and then use it for the main
website and for james projects.

We've got to do something.  We want a main site, plus project specific content, 
and release specific content within project specific content.  We also want to 
change what Maven is generating.  Almost all of its default reports should be 
turned off.  Of the Project Documentation set perhaps keep:

I agree.
I think we can create a maven2 project for our main site using only the content that is not project specific. As I already tried the James site generation using maven2 this should not be a big problem. Maven should be able to automatically find the multiple projects and keep consistency in layouts between them. I have to study a bit more about this and as always I don't know if and when I'll find the time, but this seems the right way.

  Dependencies, Issue Tracking, Mailing Lists, License

The Source Repository report is OK to show the URL, but all of the content 
should be directed to http://www.apache.org/dev/#svn.  We don't want to 
maintain general SVN instructions.

Maven2 automatically generate this page:
http://people.apache.org/~bago/james/looktest/jspf/source-repository.html

Imho from a user perspective this page is better than http://www.apache.org/dev/#svn

Both way we don't have to mantain it, because maven2 generate it automatically.

The only Project Report we should keep is the JavaDocs, and that needs to be per-release 
level.  The "Who we are"/Project Team is JAMES, not component specific.

I agree on the per-release level, but I think that project reports are helpful and if we can generate them automatically and with few effort we should publish them:

As an example I find very useful the "XRef" as an additional reference when I use libraries: most time Javadocs are not enough but I don't want to download source distribution just to check a method source.

Most of the other reports are more oriented to us: surfire (test reports), tag list, pmd, clover, etc..

I think it is useful to keep them but I don't care as much as for xref.

All of this last reports would be a must if we'll ever plan to publish updated references for projects "trunks".

And I most definitely do not want a "Built by Maven" logo on the page.

I'm -0 about this: if we use maven we should give credits to them.
Btw it can be easily hidden via css.

I'd be willing to see what such an overall site would look like, but want to 
see it before we decide to keep it.

I think the final goal will be much more similar to:
http://directory.apache.org/
They have ApacheDS, MINA and Naming as project categories, we would have Server, jSPF, Postage, Mime4J, jSieve, and so on.

I think that directory m2 "sources" will be helpful when trying to achieve the same goal.

Regardless of whether we use the same or different tools to build the site 
parts, we can merge them via svn (e.g., james/ would come from site/, 
james/server would come from server/, jspf/ would come from jspf/, etc.).  I'd 
prefer a common look, regardless of which approach we take.

Please let me know what do you think of my test look.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to