incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 20:56:59 GMT

Jeff Genender wrote:
> Geir Magnusson Jr wrote:
>>Jeff Genender wrote:
>>>>Oh, cmon.  History?  Why is it so bad to check in things?
>>>But this again is no different than deploying a jar artifact.  The site
>>>is purely an output of source code...just like a jar is an output of
>>>java source.  I see no difference here.
>>Because when you check in :
>>1) others get to see what you did
> Does the source not allow this?  Can't someone do a "mvn site" and look
> at it?

No - not easily by glancing at the commit stream.  That's the point of 
having everyone subbed to the commit stream.

It would mean that for everyone to know what's changes were going out to 
the site, they'd have to

1) svn update
2) generate site
3) diff with previous copy held somewhere

seems a lot harder than looking at the commit stream.

>>2) there's an auditable history of what gets deployed to the site
> Again, the src has this, yes?

No - the output is different than the source, especially if you are 
changing nav or something that causes lots of pages to be changed.

>>3) anyone with access to the web server can deploy the site by just
>>doing a svn co, rather than having to get maven, the source, build,
>>deploy, etc...
> Wait...the people who deploy it are committers and already have mvn
> installed.  This simply builds the web follows what most other
> maven sites are doing, whats wrong with following the crowd?  This best
> practice, yes?

I don't think it's a "best practice".  it's a common practice.  So is 

>>Get real.  You do it via lazy consensus as people see the commits go by.
>> Just like source.
> Sorry...what's the difference?

You dropped what I was responding to.  You said :

"Sounds like a great plan for the site too...we should do all the above 
before releasing a site."

meaning that you were proposing to vote every site change.

>>Because we vote on the code that goes into the jars.  There is
>>oversight.  W/ Geronimo, we also test the jars w/ the TCK - lots of
>>hands, lots of eyes.
>>We are responsible for the website.  Anyone can site:deploy and no one
>>ever knows...
>>If we just check in the created site, and then deploy manually, we are
>>assured that all the committers get to see the change stream going by
>>You also have the added bonus of seeing *exactly* what is going to
>>change on the website when you do a svn commit, because all files that
>>have changed are listed.  How do you know if some other part of the site
>>that you weren't working on accidentally changed?  Don't you want to be
>>sure you know what's being deployed?
> Look..I really don't care if we check it in or not.  If you are that
> strongly in support of the need for output to be checked in, then fine.

I think it's worth considering on it's own merits.

>  My point is we should follow the maven best practices as do most other
> maven driven sites.    Its not really important enough for me to decide
> one way or the other.  But I will point out that doing it this way
> confuses where changes are made to the site as opposed to its generation
> at the source level.  This will cause a disjoint.



View raw message