Re: Publishing api docs for Subversion
On Fri, Dec 4, 2009 at 4:23 AM, Hyrum K. Wright hyrum_wri...@mail.utexas.edu wrote: On Dec 3, 2009, at 2:14 PM, Paul Querna wrote: On Thu, Dec 3, 2009 at 9:31 AM, Doug Cutting cutt...@apache.org wrote: Paul Querna wrote: httpd and apr have published doxygen of their trunks periodically, they aren't based on any release. Were these published these on the official public website or in the dev/ section? I was under the impression that released documentation should be treated similarly to released code. The convention I've used is that stuff that's in trunk, stuff that's intended to be included in releases, is only published after release. Other pages on the website that are not included in releases, e.g., the project's home page, are clearly published without a release vote. http://httpd.apache.org/docs/trunk/ Which is linked from the sidebar everywhere, and on the docs page: http://httpd.apache.org/docs/ Back the original question: What's the best/typical way of generating and providing these documents? Subversion is using svnwcsub to publish subvesion.apache.org, but I don't think it's reasonable to check in a copy of the API documentation. To add to it and if i was not clear in my original email, when I say update docs on nightly basis, I mean updating the files every night. It does not mean generating new set of doc files every night. Overall we'll maintain just one copy that is updated every night. I wish there should be a place other that site/ area in repository, if people.apache.org is not apt. -- Regards, Bhuvaneswaran A www.livecipher.com GPG: 0x7A13E5B0 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
Hi, On Fri, Dec 4, 2009 at 4:18 AM, Bhuvaneswaran A bhuvaneswa...@gmail.com wrote: On Fri, Dec 4, 2009 at 4:23 AM, Hyrum K. Wright hyrum_wri...@mail.utexas.edu wrote: Back the original question: What's the best/typical way of generating and providing these documents? Subversion is using svnwcsub to publish subvesion.apache.org, but I don't think it's reasonable to check in a copy of the API documentation. To add to it and if i was not clear in my original email, when I say update docs on nightly basis, I mean updating the files every night. It does not mean generating new set of doc files every night. Some Apache projects are now using Hudson builds to generate their web sites from sources stored in svn. The generated site is periodically rsynced to the correct place people.apache.org. This setup is still a bit experimental but should cover your needs pretty well. The infra@ and site-dev@ archives are not public so I unfortunately can't point you to the relevant threads there, but see for example http://markmail.org/message/6m5jwauk77krla5k for a related description of how the Apache Tika web site is currently handled. Please join the site-dev@ mailing list for more details and ideas on how to improve the setup. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Fri, Dec 4, 2009 at 2:12 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Some Apache projects are now using Hudson builds to generate their web sites from sources stored in svn. The generated site is periodically rsynced to the correct place people.apache.org. This setup is still a bit experimental but should cover your needs pretty well. Thanks for sharing your views, Jukka. Thinking deeper into this task, the Hudson has a inbuilt feature to publish html content if placed in userContent folder. The javadoc publishing capability is already present in Hudson. Taking advantage of both these Hudson features, I'm thinking a) configure the job(s) to generate doxygen and javadoc documentation. b) create a link to this document to userContent. With this setup, the documentation can be made available here: doxygen: http://hudson.zones.apache.org/hudson/userContent/subversion/doxygen/index.html javadoc: http://hudson.zones.apache.org/hudson/userContent/subversion/javadoc/index.html We may configure this job to run on daily basis. AFAIK, in the past we did not publish doxygen/javadoc for stable releases in Subversion project. If we had to so, we may place them in svn under site/ directory corresponding to that release. The documentation for trunk aka. on going changes can be made available in the above url which we may link it from our home page, if need be. To publish document in this fashion, all we need to do is create Hudson job(s) appropriately. I'll propose this plan to our project team and do the setup accordingly. Thank you! -- Regards, Bhuvaneswaran A www.livecipher.com GPG: 0x7A13E5B0 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
How to put droids into the snapshot rep
Hi all, https://issues.apache.org/jira/browse/DROIDS-65 I am looking into adding droids to the public apache maven rep. I did some research but could not really find a extend how to. Can somebody point me in the right direction? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U. (SADESI) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to put droids into the snapshot rep
If you use maven in your project: http://maven.apache.org/developers/release/apache-release.html Don't know for ant builds, maybe this will help? http://maven.apache.org/guides/mini/guide-central-repository-upload.html Is ivy able to upload releases? If it can you can upload them to the apache nexus staging repository, see the maven-related documentation for that. Cheers, Francis On Fri, Dec 4, 2009 at 1:34 PM, Thorsten Scherler thorsten.scherler@juntadeandalucia.es wrote: Hi all, https://issues.apache.org/jira/browse/DROIDS-65 I am looking into adding droids to the public apache maven rep. I did some research but could not really find a extend how to. Can somebody point me in the right direction? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U. (SADESI) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
Paul Querna wrote: http://httpd.apache.org/docs/trunk/ Which is linked from the sidebar everywhere, and on the docs page: http://httpd.apache.org/docs/ That trunk documentation is at least labelled dev. I'd argue it should only be linked to from http://httpd.apache.org/dev/ and that it should reside there. That would be consistent with: http://www.apache.org/dev/release.html#what Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Documentation that's released is released under the Apache license and is not in general strongly distinguished from code that's released: we require a CLA on file for documentation contributions, we require each documentation source file to contain the license, etc. Publishing trunk documentation to the non-developer portion of a web site is encouragement for non-developers to use trunk, which is something we should avoid. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Fri, Dec 4, 2009 at 5:29 PM, Doug Cutting cutt...@apache.org wrote: Paul Querna wrote: http://httpd.apache.org/docs/trunk/ Which is linked from the sidebar everywhere, and on the docs page: http://httpd.apache.org/docs/ That trunk documentation is at least labelled dev. I'd argue it should only be linked to from http://httpd.apache.org/dev/ and that it should reside there. That would be consistent with: http://www.apache.org/dev/release.html#what Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Documentation that's released is released under the Apache license and is not in general strongly distinguished from code that's released: we require a CLA on file for documentation contributions, we require each documentation source file to contain the license, etc. Publishing trunk documentation to the non-developer portion of a web site is encouragement for non-developers to use trunk, which is something we should avoid. It might be good a good idea to not confuse users trying to find docs that relate to a release from that of of the current trunk, but its doing incubating projects a disservice to try and make out that release policy cover the docs they publish on their web site. This is something for the project to decide for themselves and we should keep our noses out and avoid trying to find new ways to beat them up with policy. Niall Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
Niall Pemberton wrote: It might be good a good idea to not confuse users trying to find docs that relate to a release from that of of the current trunk, but its doing incubating projects a disservice to try and make out that release policy cover the docs they publish on their web site. Don't our release policies cover all the stuff that's in releases and derivations thereof? What's the rationale to separate documentation from everything else that's in a release? This is something for the project to decide for themselves and we should keep our noses out and avoid trying to find new ways to beat them up with policy. I'm actually trying to keep the policy straightforward and consistent: ASF content that's subject to release votes should only be published to non-developers after it's been released. Posting trunk documentation seems very similar to posting a nightly build. Both are permitted, but not only via developer-specific pages, not in a way that can be construed as an official distribution. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Fri, Dec 4, 2009 at 9:09 PM, Doug Cutting cutt...@apache.org wrote: Niall Pemberton wrote: It might be good a good idea to not confuse users trying to find docs that relate to a release from that of of the current trunk, but its doing incubating projects a disservice to try and make out that release policy cover the docs they publish on their web site. Don't our release policies cover all the stuff that's in releases and derivations thereof? What's the rationale to separate documentation from everything else that's in a release? Yes but this is not talking about releases - its about publishing documentation on the web site. Thats not what everyone understands by the term *release* here. We don't vote every time someone wants to republish the website. Its not inviting people to take something away and do what they want with it. What we publish on the ASF websites doesn't have to conform to the licensing policy that releases do. Its there for people to read. Now if you packaged up those docs, voted on them to distribute and invited people to download them and what they're licensed under then it would be a release. But this isn't that, its providing documentation on the website and AIUI that isn't governed by what we have for a release policy. Niall This is something for the project to decide for themselves and we should keep our noses out and avoid trying to find new ways to beat them up with policy. I'm actually trying to keep the policy straightforward and consistent: ASF content that's subject to release votes should only be published to non-developers after it's been released. Posting trunk documentation seems very similar to posting a nightly build. Both are permitted, but not only via developer-specific pages, not in a way that can be construed as an official distribution. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
Niall Pemberton wrote: What we publish on the ASF websites doesn't have to conform to the licensing policy that releases do. I'm not talking about the website in general. I'm talking specifically about publishing content primarily intended for inclusion in releases. Would we permit someone to mirror other files from trunk on the website? What's special about documentation? It comes from contributors, we require an ICLA or some other indication of intent to submit under the Apache license, its changes are subject to vetos, etc. It's otherwise treated just like code. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Fri, Dec 4, 2009 at 11:45 PM, Doug Cutting cutt...@apache.org wrote: Niall Pemberton wrote: What we publish on the ASF websites doesn't have to conform to the licensing policy that releases do. I would prefer what I say isn't distorted by selective editing. I'm not talking about the website in general. I'm talking specifically about publishing content primarily intended for inclusion in releases. Would Publication release are two different things - thats the point. we permit someone to mirror other files from trunk on the website? What's Yes and I bet every project provides a link to browse subversion which itself is just another web site. special about documentation? It comes from contributors, we require an ICLA Everything is contributed by someone, including the web site contents. Niall or some other indication of intent to submit under the Apache license, its changes are subject to vetos, etc. It's otherwise treated just like code. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
Niall Pemberton wrote: I would prefer what I say isn't distorted by selective editing. Sorry, that was not my intent. I'm not talking about the website in general. I'm talking specifically about publishing content primarily intended for inclusion in releases. Would Publication release are two different things - thats the point. I don't see that yet. Can you tell me more about the difference? I use publish, distribute and release more or less synonymously when referring to project content. Subversion contains only working drafts. we permit someone to mirror other files from trunk on the website? What's Yes and I bet every project provides a link to browse subversion which itself is just another web site. Yes, but such links are meant to be confined to developer-oriented pages. We specifically do not encourage anyone but developers to use code in subversion. We provide extra diligence for releases, and that only makes sense if we don't otherwise distribute their content to the general public. Subversion is a service for our developers. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Wed, Dec 2, 2009 at 18:48, Bhuvaneswaran A bhu...@apache.org wrote: Here's a query related to publishing api docs for Subversion project periodically. We tend to update the api docs generated using doxygen and java doc on a nightly basis. We are evaluating a workaround to publish it periodically. Based on investigation I did so far, most of projects namely apr, hadoop, jakarta seem to place the apidocs in site/ area, not updated periodically though. As our use case is to update periodically, we wouldn't want to commit the auto generated docs in asf repository often. Considering these aspects, here's what we are planning to do: Setup a Hudson job in hudson.zones.apache.org farm that would generate the documentation using doxygen and javadoc. This can be setup to run periodically, may be once a day or once a week. Then, push the documentation files to people.apache.org into one of our accounts using SCP plugin that is already available in Hudson. We may use a passphrase/keyfile for authentication. Please shed some light if this is not the right approach, and/or if you could suggest a better/alternate approach, that would be helpful. -- Regards, Bhuvaneswaran A www.livecipher.com GPG: 0x7A13E5B0 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
