RE: Proposal: Jakarta should protect community email addresses
Would it be possible to mangle/remove the e-mail addresses before publishing the postings? This would eventually fix the mirrors. However, unless the mailing list software can also be persuaded to hide the originators e-mail addresses (might be difficult?), it would not protect against others who archive the raw content. Might be worth trying a combination of approaches. -- The opinions expressed herein are my own, and are not necessarily endorsed by my employer ... -Original Message- From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] Sent: 27 June 2003 06:11 To: Jakarta General List; [EMAIL PROTECTED] Subject: Re: Proposal: Jakarta should protect community email addresses On Fri, 27 Jun 2003 00:48:33 -0400 (EDT) (Subject: Proposal: Jakarta should protect community email addresses) "Andrus Adamchik" <[EMAIL PROTECTED]> wrote: > [PROPOSAL] > > There maybe other exlanations for these things, but still it would be wise > to pull the archives out of the site. Of course there are people who would > want to search them for information (since browseable Jakarta archives are > well, should I say hard to use :-)), but those archives can be > transferred to gmane.org or something... > > Thoughts? Anyone else got hit by that (I remember someone posting > something similar long time ago). -0.5: Remain the archives on http://jakarta.apache.org/mail/ and do the robot.txt (or .htaccess) protect for the robot search engines. tar.gz archives are very useful for me. -- Tetsuya ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: Jakarta should protect community email addresses
> -Original Message- > From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] > Sent: 27 June 2003 12:20 > To: Jakarta General List > Subject: Re: Proposal: Jakarta should protect community email > addresses > > > > On Fri, 27 Jun 2003 11:29:23 +0100 > (Subject: RE: Proposal: Jakarta should protect community > email addresses) > "BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: > > > Would it be possible to mangle/remove the e-mail addresses > before publishing > > the postings? > > This would eventually fix the mirrors. > > Technically, it might be possible. However, mangling e-mail addresses > would turn out that the 'mangled' mbox archives are meaningless, IMO. > (we can not import the UNIX mbox style text with such mangled e-mail > addresses to the mail clients) > Suerly as long as the mangled address had a valid format, e-mail clients could still import them? == I believe that the top-level "domain" of .invalid has been reserved for just such a purpose - one can generate e-mail addresses that parse correctly, whilst guaranteeing that the address will never correspond to a valid mail recipient. Otherwise, valid mangled addresses can turn out to exist... -- The opinions expressed herein are my own, and are not necessarily endorsed by my employer ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Whither Gump?
Is Gump on holiday? There don't seem to be any nightly builds since September 9th. The jar directories seem to be up to date, but are not complete (e.g. JMeter is not present). [This is not a particular problem for me, but it would be useful if the nightly builds could be made available again.] -- The opinions expressed herein are my own, and are not necessarily endorsed by my employer ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deleting or archiving directories in CVS
We've done some re-arranging of the CVS directory structure in jakarta-jmeter, and some of the directories are now obsolete. I'd like to remove the directories that we will never use (e.g. javadoc output) and move the other unused ones to the Attic. It is easy to create directories in CVS, but it seems to be very difficult to remove directories. I've tried various combinations of rmdir, cvs remove, cvs commit, but the directories remain in CVS. Is there a way to (re)move the unwanted directories? -- Sebastian Bazley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deleting or archiving directories in CVS
> -Original Message- > From: Henning Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 14:59 > To: Jakarta General List > Cc: Apache Infrastructure > Subject: Re: Deleting or archiving directories in CVS > > > On Wed, 2003-10-22 at 14:57, BAZLEY, Sebastian wrote: > > > It is easy to create directories in CVS, but it seems to be > very difficult > > to remove directories. > > No it's not. It's impossible. :-) However, as empty > directories will not > show up when checked out (unless explicitly requested), this is not a > big problem. However, removing old directories from the CVS > server will > destroy the history of the files that once have been in this > directory. In the case of the javadoc directories (docs/api...), we are not interested in being able to recover any of the files. Most of the docs directory was likewise populated with files that were generated from xdocs. > > As this is only a problem with the CVS browser, do you really consider > removing the directories necessary? > Apart from the wasted space (perhaps not a big deal), the empty directories do seem to affect synchronisation. I'm using Eclipse 2.1.1, in case that is relevant here. Although there are no files in the directories in CVS, the same directories are needed in the local build environment - they are created and populated when building Javadoc and the manual. When synchronising, the whole docs tree is checked. The top-level dir (docs) is in .cvsignore, so that is not flagged as being out of synch, but all the subdirectories and files are compared, and the result is that all the contents are shown as being new files. This does not happen with a directory that is not in CVS (e.g. printable_docs) - so long as the directory is in the parent .cvsignore, the whole directory tree is ignored. I suppose we could rename the docs directory in the build file and whereever else it is used - but that is a kludge. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deleting or archiving directories in CVS
> -Original Message- > From: Ortwin Glück [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 16:32 > To: Jakarta General List > Subject: Re: Deleting or archiving directories in CVS > > > BAZLEY, Sebastian wrote: > > I'm using Eclipse 2.1.1, in case that is relevant here. > > The top-level dir (docs) is in .cvsignore, so that is not > flagged as being > > out of synch, but all the subdirectories and files are > compared, and the > > result is that all the contents are shown as being new files. > > This is a clear misbehaviour of Eclipse. > > You should try the workaround: > - exit Eclipse > - manually remove CVS information from all directories under docs/: > cd docs && rm -rf `find -type d -name CVS` > - startup Eclipse > - refresh > - exit Eclipse > - startup Eclipse > - synchronize I removed the entire docs tree, which is what the ant build script does on a full build. Eclipse synchronize ignores the docs directory when it is not present. Eclipse also ignores entire directory trees if the top level is in .cvsignore and the tree is not in CVS. So far, so good. But if I create and populate the docs directory, the synchronize process picks up everything under docs. The difference is that docs is in CVS; Eclipse does not ignore CVS in this case. Now I thought .cvsignore files only applied to the current directory, so that there is a case for saying that Eclipse should check CVS for sub-directories? I'm confused! S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forrest skin for Jakarta-XX project
> -Original Message- > From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 16:16 > To: Jakarta General List > Subject: Forrest skin for Jakarta-XX project > > > > Hi, > > > I am now thinking of the *unified* skin (of Apache Forrest) > for Jakarta SubProjects... > > Now, Jakarta-POI uses Apache Forrest for building the site. > http://jakarta.apache.org/poi/ > > I think Jakarta-Tapestry will make use of it. too. > > (What about Struts?) > > -- > > I prepared "Jakarta-Skin" which is similar to > "POI-skin" (Look and feel: http://jakarta.apache.org/poi/) > and I want to put it into jakarta-site2, so that other > projects can re-use. > > Any thoughts? JMeter needs to be able to build two versions of its documentation - one for the web-site, and the other for use when running JMeter. This does not have the left-hand navigation bar. JMeter uses some of the pages in its help system, which is displayed using Java. Would using Forrest cause problems with this? Or perhaps it would make things easier? At present, the XML is converted using Anakia, with separate VSL fiels for the site and printable versions - there are some XSL stylesheets, but I think these are rather out of date. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forrest skin for Jakarta-XX project
> -Original Message- > From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 18:47 > To: Jakarta General List > Subject: Re: Forrest skin for Jakarta-XX project > > > > On Wed, 22 Oct 2003 18:19:13 +0100 > "BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: > > > Would using Forrest cause problems with this? > > Or perhaps it would make things easier? > > Forrest can create PDF file. I think it suffice the users' needs. For some things, yes, but not for the interactive Help system. Help uses Java to display an HTML document, and the application navigates to the correct part of the appropriate file. We don't want to require the users to install Acrobat. Java is very finicky about what it will cope with ... > > > At present, the XML is converted using Anakia, with > separate VSL fiels for > > the site and printable versions - there are some XSL > stylesheets, but I > > think these are rather out of date. > > It's related to the fact that you did not login to minotaur > (www.apache.org) via ssh and have not done > $ umask 0002 > $ chmod -R g+w /x1/www/jakarta.apache.org/jmeter > $ cd /www/jakarta.apache.org/jmeter/ > $ cvs update > yet. > Sorry, I don't understand what you mean here. The XSL stylesheets are part of JMeter, and are used to transform the XML into HTML. Changes have been made to the VSL (Anakia) stylesheets, but not the XSL versions, so we cannot currently use XSL to generate either set of documentation, as far as I know. > -- > > Anyway, I can forrest version of JMeter website, within a few days > (Really easy). Not sure we want to regenerate the whole site from CVS at present. There have been a lot of updates to the user documentation, but the corresponding version of the software has not been released. It would be confusing if the online docs described a version that was not generally available. However, if you can publish a separate version that does not change the existing site, that would be useful. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forrest skin for Jakarta-XX project
> -Original Message- > From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 19:17 > To: Jakarta General List > Subject: Re: Forrest skin for Jakarta-XX project > > > > On Wed, 22 Oct 2003 19:02:52 +0100 > (Subject: RE: Forrest skin for Jakarta-XX project) > "BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: > > > > It's related to the fact that you did not login to minotaur > > > (www.apache.org) via ssh and have not done > > > $ umask 0002 > > > $ chmod -R g+w /x1/www/jakarta.apache.org/jmeter > > > $ cd /www/jakarta.apache.org/jmeter/ > > > $ cvs update > > > yet. > > > Sorry, I don't understand what you mean here. > > The XSL stylesheets are part of JMeter, and are used to > transform the XML > > into HTML. > > Changes have been made to the VSL (Anakia) stylesheets, but > not the XSL > > versions, so we cannot currently use XSL to generate either set of > > documentation, as far as I know. > > Sorry, me too at a loss :-) > > Maybe you can find "new" xsl file via > jakarta-site2/xdocs/stylesheets/site.xsl > > ... Just copy to jmeter module and cvs commit, I guess.. As far as I know, the JMeter stylesheets are unique to JMeter, so I doubt if that would work. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forrest skin for Jakarta-XX project
> -Original Message- > From: Tetsuya Kitahata [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 02:24 > To: Jakarta General List > Subject: Re: Forrest skin for Jakarta-XX project > > > On Wed, 22 Oct 2003 19:25:56 +0100 > "BAZLEY, Sebastian" <[EMAIL PROTECTED]> wrote: > > > > Maybe you can find "new" xsl file via > > > jakarta-site2/xdocs/stylesheets/site.xsl > > > > > > ... Just copy to jmeter module and cvs commit, I guess.. > > > > As far as I know, the JMeter stylesheets are unique to > JMeter, so I doubt if > > that would work. > > D'oh... Sorry. I had a little confused. > > Okeydokey. > > What I proposed here, was not "Please use Forrest, all the > Jakarta-XX-Team", but "Dear Jakarta-XX-Project, which > want to use Apache Forrest ...". OK, understood. We might still be interested if it can cope with our requirements: - separate docs for binary build (stylesheet probably won't do because of Java HTML display) - auto-generation of HTML anchors and contents list - ability to have contents list in two columns - automatic generation of links between pages based on previous and next markers in XML All of this is done by Anakia at the moment. I'll try and take a look at Forrest to see what it can offer. > > I've heard that Struts Team once discusses about the usage of Forrest, > so I said "What about Struts?" > > As for JMeter, I think now it is working well. > (Yes, I sent patches for the re-build of the site using Anakia, > the other day) Thanks. > Just I took a look at the current JMeter site and found that > there's still "Copyright 1999-2001" statement at the bottom > of each pages. So, I told you the procedure of updating > website how-to. The patches have been applied to CVS, but we have yet to update the web-site. This is partly lack of time, and partly that the documentation of JMeter has been updated and no longer corresponds with the released version. S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump build failures
There seem to be a lot of Gump build failures at present, particularly in some of the commonly used modules, so a lot of builds (including JMeter) are failing with "missing pre-requisite". Although the JMeter Gump project file lists various external dependencies, most of the jars that it needs for building are actually in its CVS, and these jars are alse included in binary releases. So can I change the JMeter Gump dependencies accordingly? Or would this cause problems for Gump and/or be against the "spirit" of Gump? -- sebb at apache dot org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[wiki] Jakarta JMeter wiki - request
We'd like move the JMeter Wiki to MoinMoin. It should probably start at http://wiki.apache.org/jakarta-jmeter, but http://wiki.apache.org/jmeter would do just as well. Commit messages should go to [EMAIL PROTECTED] initially. Anything else you need to know? S. (sebb AT A.O) -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: 28 February 2004 09:20 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [wiki] Jakarta wikis set up Dear Jakarta PMC, I have set up MoinMoin wikis for Jakarta at http://wiki.apache.org/jakarta http://wiki.apache.org/jakarta-lucene http://wiki.apache.org/jakarta-tomcat http://wiki.apache.org/jakarta-tapestry Please take a look at the README file in /www/wiki.apache.org on minotaur, http://wiki.apache.org/gump/HelpContents and http://moin.sf.net for more information about MoinMoin. I have also attempted to migrate all content from the UseMod wiki installation to the appropriate places in the new MoinMoin wiki installation. Since the migration script is not perfect, some pages may be missing and/or looking awkward. You will need to fix these manually. Specifically, page where copied over as follows: *Jakarta* -> /jakarta *Lucene*-> /jakarta-lucene *Tomcat*-> /jakarta/tomcat this means that a lot of pages for jakarta subprojects have not been migrated to a new final location on the MoinMoin installation yet, and are hence located (immutable) at http://wiki.apache.org/old/ We can set up more subwikis for the jakarta subprojects and migrate those pages, or we can copy those pages to the /jakarta subwiki. Just ask. Note that cvs-style commit messages for changes made to the wiki will be sent to the appropriate mailing lists as has been requested (the moderator for those mailing lists will likely need to make some changes to allow these to go through). Please contact us on the [EMAIL PROTECTED] mailing list if you have any questions (prefix the e-mail subject with '[wiki]'). best regards, - Leo Simons ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
