incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 21:43:53 GMT


Jeff Genender wrote:
> 
> Geir Magnusson Jr wrote:
> 
> 
>>> 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.
>>
>>Why?
>>
> 
> 
> Why?  Because I now have HTML that can be edited *as well as* the
> source.  If someone edits the HTML, and not the source, then the next
> time the site is generated, the HTML is over written.  This is a
> complete PITA.

Why would you edit the HTML?   That's like editing the jar.

edit the source material.  render the site.  check in the generated 
artifacts. deploy to website from svn.  simple.

You haven't had a problem with Geronimo's approach, have you?

> 
> IMHO, doing the maven thing is a better way...thats my opinion...no
> more...no less.  You won't change this.

Thanks for keeping an open mind.

Just as an exercise in helping me understand why your mind is so made 
up, at least tell me why.  You haven't given one technical reason other 
than "others do it".

I've explained the benefits of checking in the artifacts :

1) it ensures that you know exactly what changes are going "to production"

2) Others can oversee the same thing - what changes are going "to 
production"

3)It provides a log of exactly what went to production, when, and by 
whom, with history.


Why is it better to *not* check in the artifacts?

> 
> I personally have subscribed to the site generation methodology and I
> like it.  As for commits and seeing them, its very simple and a lot
> easier to read a commit based on APT (almost plain text) than it reading
> the raw HTML, so I cannot agree with you on those points.

Except you aren't publishing the APT.  Just like you don't exceute 
source, you execute binary - hence, you compile the source and test the 
binary.

You are arguing that no testing or QA is needed.  I'm saying that it is.

You still commit the APT anyway, so you can see that.  However, changing 
source material for a site can change more than one output artifact. 
How do you check them if you only read the source?

> 
> Lets do this according to the Apache way and put out a vote to commit
> the site or just the source.  It should end there.  If everyone wants
> the site committed, then so be it.

Calling for a vote mid conversation is not "the Apache way", nor is 
appealing to mob rule.

> 
> Is this ok?  Can we agree to disagree on the web site subject based on
> our personal preferences and let the majority rule?

I'd prefer to hear why it's better to publish blindly to production 
rather than commit the same materials and let others have a chance to 
review.  It doesn't change the tool you are using - it just adds some 
minor steps.

All I'm suggesting is that after generating the material, you do a svn 
commit, ssh to the machine, svn co.  Yes, it's two additional 
[scriptable] steps, but I think that we get a lot out of it.  I don't 
think I've seen seen an argument to what the downside is.

geir

> 
> Jeff
> 
> 
>>geir
> 
> 
> 

Mime
View raw message