You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2002/12/09 10:44:21 UTC
Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
All,
I've struggled with this before, linefeeds, javadocs and xslt performed on a WIN machine get crlf which according to the rules has to be changed to lf.
I personally don't think that generated html in /www/, which is there to allow controlled website updates not to version the docs themselves which are versioned in /src/, nedds to have this as strictly enforced as elsewhere, IMO it takes effort for no appreciable benefit.
Thoughts?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> > I'd argue that the RFC
> > stuff should be put in xdoc format and incorporated into the
standard
> > web site build process.
>
> I don't think so, unless you are likely to have enough free time to
> transcribe them what would the point be?
Uniform look and feel.
By putting them in xdoc format (and the transcription isn't necessarily
particularly hard) you get the title bar, side bar, etc. The RFCs look
like part of the site, and navigation to the rest of the James site is
easy. It's a far more professional look.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by Danny Angus <da...@apache.org>.
> I'd argue that the RFC
> stuff should be put in xdoc format and incorporated into the standard
> web site build process.
I don't think so, unless you are likely to have enough free time to transcribe them what would the point be?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by Danny Angus <da...@apache.org>.
http://jakarta.apache.org/site/jakarta-site2.html
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 09 December 2002 21:05
> To: 'James Developers List'
> Subject: RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
>
>
>
> Noel,
>
> > My point was simply that such content is there, and needs to be
> accounted.
> > And we should address our www building process when we look at
> > Maven/Forrest. But we also have to deal with whatever requirements we
> > have
> > from the ASF in terms of having a CVS entry for their controlled
> > management
> > of the web site.
>
> Ok. I don't quite get what your point is here. Of course we need to
> account for it. But it's not like that's terribly difficult. There
> isn't much of it, as I detailed in my previous email.
>
> As far as ASF/CVS requirements, I don't believe that there is any such
> animal. Right now our website update process is completely manual and
> totally instigated by James committers. That is, unless Danny, myself,
> or someone else goes into daedalus and manually updates the subdirectory
> via CVS update, the website remains unchanged. There is no automatic
> ASF process that updates it for us (and hence might require www in CVS).
>
> I've never read any documentation that indicated that it is either
> necessary or desirable in the eyes of the ASF that the website
> HTML/images be stored in CVS in an immediately deployable form. If
> anyone knows of such docs, please send a link to the list so we can
> discuss. If there is such a requirement, I'll be happy to argue against
> it with the ASF.
>
> > Perhaps it would be better to have a separate james-site module, and
> > publish
> > to it, so that the normal James module does not have any generated
> > content.
> > I don't know.
>
> Ugh. Same problem with updates, just deferred to a different module.
> We'd have to manually update changes to the Javadoc. That sort of thing
> has continuously led to discrepancies that lasted for months in terms of
> the Javadoc available via the website and the Javadoc produced from the
> source code.
>
> Let me reiterate. Dynamic build products being stored in source control
> is a terrible idea. I don't care what source control system, I don't
> care what module, this remains a bad idea. We just shouldn't do it.
>
> --Peter
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
> > As far as ASF/CVS requirements, I don't believe that there is any
such
> > animal.
>
> > I've never read any documentation that indicated that it is either
> > necessary or desirable in the eyes of the ASF that the website
> > HTML/images be stored in CVS in an immediately deployable form. If
> > anyone knows of such docs, please send a link to the list so we can
> > discuss.
>
> Here you go: http://www.apache.org/dev/committers.html#web
>
> I suspect that the correct place to discuss the issue with the ASF
would
> be
> in infrastructure@. From a recent discussion there, it appears that
there
> are certain topics, e.g., site security, that they do not want
discussed
> in
> a publicly archived list.
Ok. Will do.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
> Ok. I don't quite get what your point is here.
Do you realize that I'm not disagreeing with you? I simply pointed out, as
a precaution against oversight, that there are some items that need to be
moved.
> As far as ASF/CVS requirements, I don't believe that there is any such
> animal.
> I've never read any documentation that indicated that it is either
> necessary or desirable in the eyes of the ASF that the website
> HTML/images be stored in CVS in an immediately deployable form. If
> anyone knows of such docs, please send a link to the list so we can
> discuss.
Here you go: http://www.apache.org/dev/committers.html#web
I suspect that the correct place to discuss the issue with the ASF would be
in infrastructure@. From a recent discussion there, it appears that there
are certain topics, e.g., site security, that they do not want discussed in
a publicly archived list.
> Ugh. Same problem with updates, just deferred to a different module.
> We'd have to manually update changes to the Javadoc.
Not from what I had in mind, Peter. In my model, we automatically generate
james-site from sources in our repository. A cron task would update its
local tree from james, build james-site, and commit james-site as necessary.
None of us would ever need to manually update james-site. james-site would
be nothing more than the interface between the cron job and the web site.
To an extent, I don't care, since we can reconstruct the site from our
source CVS. I mention this approach simply because it appears to be used
elsewhere in the ASF, and it addresses what I perceive to be an
infrastructure concern.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
> My point was simply that such content is there, and needs to be
accounted.
> And we should address our www building process when we look at
> Maven/Forrest. But we also have to deal with whatever requirements we
> have
> from the ASF in terms of having a CVS entry for their controlled
> management
> of the web site.
Ok. I don't quite get what your point is here. Of course we need to
account for it. But it's not like that's terribly difficult. There
isn't much of it, as I detailed in my previous email.
As far as ASF/CVS requirements, I don't believe that there is any such
animal. Right now our website update process is completely manual and
totally instigated by James committers. That is, unless Danny, myself,
or someone else goes into daedalus and manually updates the subdirectory
via CVS update, the website remains unchanged. There is no automatic
ASF process that updates it for us (and hence might require www in CVS).
I've never read any documentation that indicated that it is either
necessary or desirable in the eyes of the ASF that the website
HTML/images be stored in CVS in an immediately deployable form. If
anyone knows of such docs, please send a link to the list so we can
discuss. If there is such a requirement, I'll be happy to argue against
it with the ASF.
> Perhaps it would be better to have a separate james-site module, and
> publish
> to it, so that the normal James module does not have any generated
> content.
> I don't know.
Ugh. Same problem with updates, just deferred to a different module.
We'd have to manually update changes to the Javadoc. That sort of thing
has continuously led to discrepancies that lasted for months in terms of
the Javadoc available via the website and the Javadoc produced from the
source code.
Let me reiterate. Dynamic build products being stored in source control
is a terrible idea. I don't care what source control system, I don't
care what module, this remains a bad idea. We just shouldn't do it.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'd argue that the RFC stuff should be put in xdoc format
> and incorporated into the standard web site build process.
My point was simply that such content is there, and needs to be accounted.
And we should address our www building process when we look at
Maven/Forrest. But we also have to deal with whatever requirements we have
from the ASF in terms of having a CVS entry for their controlled management
of the web site.
Perhaps it would be better to have a separate james-site module, and publish
to it, so that the normal James module does not have any generated content.
I don't know.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
> > running the build (with no source code changes)
> > should not introduce any diffs with the source
> > control tree.
>
> I appreciate your distinction between authored and generated material,
but
> I
> should point out that the www/ directory does have more in it than
just
> the
> generated files. We'd have to move the other material out of there,
too.
Of course. It shouldn't be in there anyway. I'd argue that the RFC
stuff should be put in xdoc format and incorporated into the standard
web site build process. That would leave a single image file as the
only non-generated file in the www directory. And yes, we'd have to
move that.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
> running the build (with no source code changes)
> should not introduce any diffs with the source
> control tree.
I appreciate your distinction between authored and generated material, but I
should point out that the www/ directory does have more in it than just the
generated files. We'd have to move the other material out of there, too.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> I personally don't think that generated html in /www/, which is there
to
> allow controlled website updates not to version the docs themselves
which
> are versioned in /src/, nedds to have this as strictly enforced as
> elsewhere, IMO it takes effort for no appreciable benefit.
>
> Thoughts?
I have to disagree.
First off, I'm going to comment that I very much hope the www directory
goes the way of the dodo early in the 3.0 cycle. The presence of this
directory violates one of the basic tenets of good build design.
Specifically, that running the build (with no source code changes)
should not introduce any diffs with the source control tree. In other
words, the build operation itself should be idempotent. To see that
this isn't true, do the following:
1) Check out a new Jakarta-james tree
2) Run 'build website'
3) Diff the tree - you'll see every javadoc file is changed. <shudder>
Add to this that specific changes in the src/java directory (additions,
deletions) have to be manually carried over to the www directory and it
is obvious that the current process is fragile and should be changed.
(Note, for example, that the "fetchpop" classes weren't added until
yesterday). We've discussed all this on the list before, so I'll let it
go at that.
That all said, if the www stuff (and most importantly the javadocs and
mailet API docs) are going to be in source control for the moment, it's
important to minimize the diffs so that one can discern actual issues
among all the noise. After I did my largest recent check-in on the
javadocs directory I was able to find several issues in the Javadocs
precisely because not every line contributed to the diff. So
standardization on LF served a very useful purpose, as well as being a
really easy change to make.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
Right now they switch depending upon who checks in the www. If Peter checks
in the www/, when I generate on my end, I get 11MB diff file. If I check
in, wham it toggles again.
It is simple to add a fixcrlf target to build.xml (line 340):
<fixcrlf srcdir="${www.dir}" includes="**/*.html" eol="lf"
tab="remove" tablength="4" />
Once we have the CVS fixed once, we should not have a repeat of this again.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Monday, December 09, 2002 4:44
To: James Developers List
Subject: Linefeeds in www (was RE: cvs commit: jakarta-james/www/)
All,
I've struggled with this before, linefeeds, javadocs and xslt performed on a
WIN machine get crlf which according to the rules has to be changed to lf.
I personally don't think that generated html in /www/, which is there to
allow controlled website updates not to version the docs themselves which
are versioned in /src/, nedds to have this as strictly enforced as
elsewhere, IMO it takes effort for no appreciable benefit.
Thoughts?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>