incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <bdud...@apache.org>
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.

TTFN,

Bill Dudney
MyFaces - myfaces.apache.org
Wadi - incubator.apache.org/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 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