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]