incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <>
Subject Re: web site resources?
Date Tue, 03 Jan 2006 21:59:04 GMT
Hi Geir,

Should we be putting JavaDoc into SVN? To me that is what this  
discussion boils down too. I don't like the idea of putting the  
results of a 'compile' into the repository.

In the same way that a jar file should not be checked in neither  
should a set of generated HTML files IMO.


Bill Dudney
MyFaces -
Wadi -

On Jan 3, 2006, at 2:43 PM, Geir Magnusson Jr wrote:

> 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
>> 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

View raw message