I've uploaded the 4.0.1.Final documentatation to http://docs.jboss.org/hibernate/core/4.0/. Maybe this was already discussed but, should the switch from "core" to "orm" affect the URL for the 4.0 documentation (i.e., http://docs.jboss.org/hibernate/orm/4.0/)?

Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ points to 3.6.9.Final docs. Should it point to http://docs.jboss.org/hibernate/core/4.0/ (or http://docs.jboss.org/hibernate/orm/4.0/)?

I ended up using the documentation downloaded from the SourceForge distribution because I got errors when I tried to build the Javadoc from the 4.0.1 tag using "gradle javadoc": /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: cannot find symbol symbol : variable DotName location: interface org.hibernate.metamodel.source.annotations.HibernateDotNames DotName ACCESS_TYPE = DotName.createSimple( AccessType.class.getName() ); What command should be used to build Javadoc?

I also noticed that the Javadoc includes test classes. It would be nice to exclude those.

I really liked how convenient it was to be able to just copy the contents of the documentation directory from the distribution into the staging directory for rsync-ing. The only change I had to make after copying was to change hem/en to hem/en-US. I haven't looked into this, but I imagine that would be an easy thing to fix.

On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: > Answers inline > > On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: > >> I've uploaded the 4.0.1.Final documentatation to >> http://docs.jboss.org/hibernate/core/4.0/. >> >> Maybe this was already discussed but, should the switch from "core" >> to "orm" affect the URL for the 4.0 documentation (i.e., >> http://docs.jboss.org/hibernate/orm/4.0/)? > > I think it makes sense to switch the urls. However, in this case I > suggest we also put a redirect in place for > http://docs.jboss.org/hibernate/core/4.0/ to > http://docs.jboss.org/hibernate/orm/4.0/ > Just renaming the directories is probably not a good idea due to > bookmarks and people used to go to the 'core' url. If we change to > orm we need to update the pointers from > http://www.hibernate.org/docs I agree, we should do a redirect. I had not planned on changing the physical dir until 4.1 as that is when the new docs would be getting used. 6 in one... if you feel the itch, go for it. >> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ >> points to 3.6.9.Final docs. Should it point to >> http://docs.jboss.org/hibernate/core/4.0/ (or >> http://docs.jboss.org/hibernate/orm/4.0/)? > > Stable should definitely point to 4.0. That's independent of whether > we rename the urls + 1 >> I ended up using the documentation downloaded from the SourceForge >> distribution because I got errors when I tried to build the Javadoc >> from the 4.0.1 tag using "gradle javadoc": >> >> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: >> cannot find symbol >> symbol : variable DotName >> location: interface >> org.hibernate.metamodel.source.annotations.HibernateDotNames >> DotName ACCESS_TYPE = DotName.createSimple( >> AccessType.class.getName() ); >> >> What command should be used to build Javadoc? > > 'gradle javadoc' is the default javadoc task which you get when you > use the Java plugin. It build the javadocs for the current module. In > our case we don't use this task, because > we want aggregated docs. To get the aggregated docs you need to run > the 'aggregateJavadocs' from the release module. > > './gradlew aggregateJavadocs' Just a minor point. If you run it from the release module, it has to be `../gradlew aggregateJavadocs` Alternatively from root you could run `./gradlew :release:aggregateJavadocs` > FYI, the javadoc task needs all dependencies on the classpath when > executing. Looking at the error it seems jandex is not on the > classpath. This might be related to HHH-6921, but that's just a guess. > As said, the default javadocs tasks are not configured, because we > are only interested in the aggregated docs. I think Strong only changed that to move jandex to the provided configuration. I was able to run these fine when I did the build. >> I also noticed that the Javadoc includes test classes. It would be >> nice to exclude those. > > right, even the aggregated docs seem to include test classes. I would > create a jira and we reconfigure the task for the next release Hmm, I spent a lot of time getting those right. https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... If they are back, something after fucked those changes up. >> I really liked how convenient it was to be able to just copy the >> contents of the documentation directory from the distribution into >> the staging directory for rsync-ing. The only change I had to make >> after copying was to change hem/en to hem/en-US. I haven't looked >> into this, but I imagine that would be an easy thing to fix. We should update that in the source tree. But to be honest, hem docs should really just go away as a separate thing. Their content should be merged into the main docs. > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Can anyone with better git-fu than me tell me where those changes went? On Thu 12 Jan 2012 08:44:19 PM CST, Steve Ebersole wrote: > Actually wrt aggregateJavadocs, some how all those edits to > release.gradle are gone on master :( > > > On Thu 12 Jan 2012 03:48:46 PM CST, Steve Ebersole wrote: >> >> On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: >>> Answers inline >>> >>> On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: >>> >>>> I've uploaded the 4.0.1.Final documentatation to >>>> http://docs.jboss.org/hibernate/core/4.0/. >>>> >>>> Maybe this was already discussed but, should the switch from "core" >>>> to "orm" affect the URL for the 4.0 documentation (i.e., >>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>> >>> I think it makes sense to switch the urls. However, in this case I >>> suggest we also put a redirect in place for >>> http://docs.jboss.org/hibernate/core/4.0/ to >>> http://docs.jboss.org/hibernate/orm/4.0/ >>> Just renaming the directories is probably not a good idea due to >>> bookmarks and people used to go to the 'core' url. If we change to >>> orm we need to update the pointers from >>> http://www.hibernate.org/docs >> >> I agree, we should do a redirect. I had not planned on changing the >> physical dir until 4.1 as that is when the new docs would be getting >> used. 6 in one... if you feel the itch, go for it. >> >> >>>> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ >>>> points to 3.6.9.Final docs. Should it point to >>>> http://docs.jboss.org/hibernate/core/4.0/ (or >>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>> >>> Stable should definitely point to 4.0. That's independent of whether >>> we rename the urls >> + 1 >> >> >>>> I ended up using the documentation downloaded from the SourceForge >>>> distribution because I got errors when I tried to build the Javadoc >>>> from the 4.0.1 tag using "gradle javadoc": >>>> >>>> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: >>>> cannot find symbol >>>> symbol : variable DotName >>>> location: interface >>>> org.hibernate.metamodel.source.annotations.HibernateDotNames >>>> DotName ACCESS_TYPE = DotName.createSimple( >>>> AccessType.class.getName() ); >>>> >>>> What command should be used to build Javadoc? >>> >>> 'gradle javadoc' is the default javadoc task which you get when you >>> use the Java plugin. It build the javadocs for the current module. >>> In our case we don't use this task, because >>> we want aggregated docs. To get the aggregated docs you need to run >>> the 'aggregateJavadocs' from the release module. >>> >>> './gradlew aggregateJavadocs' >> >> Just a minor point. If you run it from the release module, it has to >> be `../gradlew aggregateJavadocs` >> >> Alternatively from root you could run `./gradlew >> :release:aggregateJavadocs` >> >> >>> FYI, the javadoc task needs all dependencies on the classpath when >>> executing. Looking at the error it seems jandex is not on the >>> classpath. This might be related to HHH-6921, but that's just a guess. >>> As said, the default javadocs tasks are not configured, because we >>> are only interested in the aggregated docs. >> >> I think Strong only changed that to move jandex to the provided >> configuration. I was able to run these fine when I did the build. >> >> >>>> I also noticed that the Javadoc includes test classes. It would be >>>> nice to exclude those. >>> >>> right, even the aggregated docs seem to include test classes. I >>> would create a jira and we reconfigure the task for the next release >> >> Hmm, I spent a lot of time getting those right. >> https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... >> >> >> If they are back, something after fucked those changes up. >> >> >>>> I really liked how convenient it was to be able to just copy the >>>> contents of the documentation directory from the distribution into >>>> the staging directory for rsync-ing. The only change I had to make >>>> after copying was to change hem/en to hem/en-US. I haven't looked >>>> into this, but I imagine that would be an easy thing to fix. >> >> We should update that in the source tree. But to be honest, hem docs >> should really just go away as a separate thing. Their content should >> be merged into the main docs. >> >> >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >

I took a quick look at and didn't see a likely branch. You might look in the output from "git reflog" (in your local personal Hibernate fork folder) for "HHH-6906 - Clean up javadoc warnings". I think that will contain the changes, even if your fork no longer has the branch that referenced it. The "git reflog" output will look something like: d0ce6e6 HEAD@{0}: rebase -i (finish): returning to refs/heads/cluster9 d0ce6e6 HEAD@{1}: rebase -i (pick): AS7-3229 add defaultReadObject/WriteObject calls 10c2786 HEAD@{2}: rebase -i (pick): AS7-3279 upgrade to Hibernate 4.0.1.Final ea02cae HEAD@{3}: rebase -i (pick): trace logging for xpc serialization 1fb5d2a HEAD@{4}: rebase -i (squash): xpc serialization test case 5bc81e8 HEAD@{5}: rebase -i (squash): updating HEAD 07c215a HEAD@{6}: checkout: moving from cluster9 to 07c215a aab8f78 HEAD@{7}: checkout: moving from AS7-3279 to cluster9 Lets say that someone, my HEAD@{2} change was lost from master. I could "git merge 10c2786" to pull it back into my fork and then cherry pick it from master. I haven't actually tried this myself, I just read about it. Hope this helps. Scott On 01/12/2012 11:03 PM, Scott Marlow wrote: > Are the doc commits visible on your personal Hibernate fork still? I > know that "gitk" will visualize the master branch or whatever branch. > Maybe you can see the doc commits on the master and a merge that took > them out (or not ;). > > We should be able to "git cherry-pick commit-id" the commits from your > fork, back to master (if they are still on your branch). > > On 01/12/2012 09:58 PM, Steve Ebersole wrote: >> Can anyone with better git-fu than me tell me where those changes went? >> >> >> On Thu 12 Jan 2012 08:44:19 PM CST, Steve Ebersole wrote: >>> Actually wrt aggregateJavadocs, some how all those edits to >>> release.gradle are gone on master :( >>> >>> >>> On Thu 12 Jan 2012 03:48:46 PM CST, Steve Ebersole wrote: >>>> >>>> On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: >>>>> Answers inline >>>>> >>>>> On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: >>>>> >>>>>> I've uploaded the 4.0.1.Final documentatation to >>>>>> http://docs.jboss.org/hibernate/core/4.0/. >>>>>> >>>>>> Maybe this was already discussed but, should the switch from "core" >>>>>> to "orm" affect the URL for the 4.0 documentation (i.e., >>>>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>>>> >>>>> I think it makes sense to switch the urls. However, in this case I >>>>> suggest we also put a redirect in place for >>>>> http://docs.jboss.org/hibernate/core/4.0/ to >>>>> http://docs.jboss.org/hibernate/orm/4.0/ >>>>> Just renaming the directories is probably not a good idea due to >>>>> bookmarks and people used to go to the 'core' url. If we change to >>>>> orm we need to update the pointers from >>>>> http://www.hibernate.org/docs >>>> >>>> I agree, we should do a redirect. I had not planned on changing the >>>> physical dir until 4.1 as that is when the new docs would be getting >>>> used. 6 in one... if you feel the itch, go for it. >>>> >>>> >>>>>> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ >>>>>> points to 3.6.9.Final docs. Should it point to >>>>>> http://docs.jboss.org/hibernate/core/4.0/ (or >>>>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>>>> >>>>> Stable should definitely point to 4.0. That's independent of whether >>>>> we rename the urls >>>> + 1 >>>> >>>> >>>>>> I ended up using the documentation downloaded from the SourceForge >>>>>> distribution because I got errors when I tried to build the Javadoc >>>>>> from the 4.0.1 tag using "gradle javadoc": >>>>>> >>>>>> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: >>>>>> >>>>>> cannot find symbol >>>>>> symbol : variable DotName >>>>>> location: interface >>>>>> org.hibernate.metamodel.source.annotations.HibernateDotNames >>>>>> DotName ACCESS_TYPE = DotName.createSimple( >>>>>> AccessType.class.getName() ); >>>>>> >>>>>> What command should be used to build Javadoc? >>>>> >>>>> 'gradle javadoc' is the default javadoc task which you get when you >>>>> use the Java plugin. It build the javadocs for the current module. >>>>> In our case we don't use this task, because >>>>> we want aggregated docs. To get the aggregated docs you need to run >>>>> the 'aggregateJavadocs' from the release module. >>>>> >>>>> './gradlew aggregateJavadocs' >>>> >>>> Just a minor point. If you run it from the release module, it has to >>>> be `../gradlew aggregateJavadocs` >>>> >>>> Alternatively from root you could run `./gradlew >>>> :release:aggregateJavadocs` >>>> >>>> >>>>> FYI, the javadoc task needs all dependencies on the classpath when >>>>> executing. Looking at the error it seems jandex is not on the >>>>> classpath. This might be related to HHH-6921, but that's just a >>>>> guess. >>>>> As said, the default javadocs tasks are not configured, because we >>>>> are only interested in the aggregated docs. >>>> >>>> I think Strong only changed that to move jandex to the provided >>>> configuration. I was able to run these fine when I did the build. >>>> >>>> >>>>>> I also noticed that the Javadoc includes test classes. It would be >>>>>> nice to exclude those. >>>>> >>>>> right, even the aggregated docs seem to include test classes. I >>>>> would create a jira and we reconfigure the task for the next release >>>> >>>> Hmm, I spent a lot of time getting those right. >>>> https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... >>>> >>>> >>>> >>>> If they are back, something after fucked those changes up. >>>> >>>> >>>>>> I really liked how convenient it was to be able to just copy the >>>>>> contents of the documentation directory from the distribution into >>>>>> the staging directory for rsync-ing. The only change I had to make >>>>>> after copying was to change hem/en to hem/en-US. I haven't looked >>>>>> into this, but I imagine that would be an easy thing to fix. >>>> >>>> We should update that in the source tree. But to be honest, hem docs >>>> should really just go away as a separate thing. Their content should >>>> be merged into the main docs. >>>> >>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Well however it happened at least some commits are missing. It happened between 4.0 and 4.0.1. So like Sanne said it is best if everyone checks any work they committed to make sure it is still there. The only way this happens is if someone did a forced push. We have talked about this before. In fact the last time was when I did a force and over-wrote some commits. So whoever pushed upstream with a force, please DO NOT! There is unfortunately no way for us to disable that on GitHub hosted repos. The next step that I really do not want to have to take is to start removing push rights. On 01/12/2012 08:58 PM, Steve Ebersole wrote: > Can anyone with better git-fu than me tell me where those changes went? > > On Thu 12 Jan 2012 08:44:19 PM CST, Steve Ebersole wrote: >> Actually wrt aggregateJavadocs, some how all those edits to >> release.gradle are gone on master :( >> >> >> On Thu 12 Jan 2012 03:48:46 PM CST, Steve Ebersole wrote: >>> >>> On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: >>>> Answers inline >>>> >>>> On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: >>>> >>>>> I've uploaded the 4.0.1.Final documentatation to >>>>> http://docs.jboss.org/hibernate/core/4.0/. >>>>> >>>>> Maybe this was already discussed but, should the switch from "core" >>>>> to "orm" affect the URL for the 4.0 documentation (i.e., >>>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>>> >>>> I think it makes sense to switch the urls. However, in this case I >>>> suggest we also put a redirect in place for >>>> http://docs.jboss.org/hibernate/core/4.0/ to >>>> http://docs.jboss.org/hibernate/orm/4.0/ >>>> Just renaming the directories is probably not a good idea due to >>>> bookmarks and people used to go to the 'core' url. If we change to >>>> orm we need to update the pointers from >>>> http://www.hibernate.org/docs >>> >>> I agree, we should do a redirect. I had not planned on changing the >>> physical dir until 4.1 as that is when the new docs would be getting >>> used. 6 in one... if you feel the itch, go for it. >>> >>> >>>>> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ >>>>> points to 3.6.9.Final docs. Should it point to >>>>> http://docs.jboss.org/hibernate/core/4.0/ (or >>>>> http://docs.jboss.org/hibernate/orm/4.0/)? >>>> >>>> Stable should definitely point to 4.0. That's independent of whether >>>> we rename the urls >>> + 1 >>> >>> >>>>> I ended up using the documentation downloaded from the SourceForge >>>>> distribution because I got errors when I tried to build the Javadoc >>>>> from the 4.0.1 tag using "gradle javadoc": >>>>> >>>>> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: >>>>> >>>>> cannot find symbol >>>>> symbol : variable DotName >>>>> location: interface >>>>> org.hibernate.metamodel.source.annotations.HibernateDotNames >>>>> DotName ACCESS_TYPE = DotName.createSimple( >>>>> AccessType.class.getName() ); >>>>> >>>>> What command should be used to build Javadoc? >>>> >>>> 'gradle javadoc' is the default javadoc task which you get when you >>>> use the Java plugin. It build the javadocs for the current module. >>>> In our case we don't use this task, because >>>> we want aggregated docs. To get the aggregated docs you need to run >>>> the 'aggregateJavadocs' from the release module. >>>> >>>> './gradlew aggregateJavadocs' >>> >>> Just a minor point. If you run it from the release module, it has to >>> be `../gradlew aggregateJavadocs` >>> >>> Alternatively from root you could run `./gradlew >>> :release:aggregateJavadocs` >>> >>> >>>> FYI, the javadoc task needs all dependencies on the classpath when >>>> executing. Looking at the error it seems jandex is not on the >>>> classpath. This might be related to HHH-6921, but that's just a >>>> guess. >>>> As said, the default javadocs tasks are not configured, because we >>>> are only interested in the aggregated docs. >>> >>> I think Strong only changed that to move jandex to the provided >>> configuration. I was able to run these fine when I did the build. >>> >>> >>>>> I also noticed that the Javadoc includes test classes. It would be >>>>> nice to exclude those. >>>> >>>> right, even the aggregated docs seem to include test classes. I >>>> would create a jira and we reconfigure the task for the next release >>> >>> Hmm, I spent a lot of time getting those right. >>> https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... >>> >>> >>> >>> If they are back, something after fucked those changes up. >>> >>> >>>>> I really liked how convenient it was to be able to just copy the >>>>> contents of the documentation directory from the distribution into >>>>> the staging directory for rsync-ing. The only change I had to make >>>>> after copying was to change hem/en to hem/en-US. I haven't looked >>>>> into this, but I imagine that would be an easy thing to fix. >>> >>> We should update that in the source tree. But to be honest, hem docs >>> should really just go away as a separate thing. Their content should >>> be merged into the main docs. >>> >>> >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >

On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: > Answers inline > > On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: > >> I've uploaded the 4.0.1.Final documentatation to http://docs.jboss.org/hibernate/core/4.0/. >> >> Maybe this was already discussed but, should the switch from "core" to "orm" affect the URL for the 4.0 documentation (i.e., http://docs.jboss.org/hibernate/orm/4.0/)? > > I think it makes sense to switch the urls. However, in this case I suggest we also put a redirect in place for http://docs.jboss.org/hibernate/core/4.0/ to http://docs.jboss.org/hibernate/orm/4.0/ > Just renaming the directories is probably not a good idea due to bookmarks and people used to go to the 'core' url. If we change to orm we need to update the pointers from > http://www.hibernate.org/docs I agree, we should do a redirect. I had not planned on changing the physical dir until 4.1 as that is when the new docs would be getting used. 6 in one... if you feel the itch, go for it.

>> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ points to 3.6.9.Final docs. Should it point to http://docs.jboss.org/hibernate/core/4.0/ (or http://docs.jboss.org/hibernate/orm/4.0/)? > > Stable should definitely point to 4.0. That's independent of whether we rename the urls + 1

>> I really liked how convenient it was to be able to just copy the contents of the documentation directory from the distribution into the staging directory for rsync-ing. The only change I had to make after copying was to change hem/en to hem/en-US. I haven't looked into this, but I imagine that would be an easy thing to fix. We should update that in the source tree. But to be honest, hem docs should really just go away as a separate thing. Their content should be merged into the main docs.

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Hardy Ferentschik" <hardy(a)hibernate.org&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Friday, January 13, 2012 5:07:42 AM Subject: Re: [hibernate-dev] Minor issues/questions about Hibernate Core/ORM documentation On 01/13/2012 01:58 AM, Hardy Ferentschik wrote: >> >> I agree, we should do a redirect. I had not planned on changing >> the physical dir until 4.1 as that is when the new docs would be >> getting used. 6 in one... if you feel the itch, go for it. > > Changing the directory name is easy. For the redirects we will need > "service desk" to give us a hand (afaik). If we use redirects specifically, yeah. The other option is to use symlinks. > Speaking of re-directs, I thought I change the stable link, but > realized that we might need some more redirects. > Currently the main URL looks like this: > > http://docs.jboss.org/hibernate/stable/core/reference/en-US/html_single/ > > In 4.0 the main docs are in 'manual' so the URL would be > > http://docs.jboss.org/hibernate/stable/core/manual/en-US/html_single/ > > Do we want to stick with 'manual'? If so we might want to consider > another redirect. Or we just > rename manual to reference. Was the directory rename intentional? Well we currently have 4 docs uploaded. That needs to get whittled down to 2. 'manual' specifically points to doc that will be going away. I think for "stable", we are only ever really going to be able to guarantee up to that point in the path in terms of book-marking. Anything else "below" that is too dependent on the specific versions. In fact we maybe want(ed) "current" instead of "stable" The other thing I noticed is core/orm. This rename is creeping up in a lot of places ;) -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

>> I also noticed that the Javadoc includes test classes. It would be nice to exclude those. > > right, even the aggregated docs seem to include test classes. I would create a jira and we reconfigure the task for the next release Hmm, I spent a lot of time getting those right. https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... If they are back, something after fucked those changes up.

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Hardy Ferentschik" <hardy(a)hibernate.org&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Thursday, January 12, 2012 1:48:46 PM Subject: Re: [hibernate-dev] Minor issues/questions about Hibernate Core/ORM documentation On Thu 12 Jan 2012 03:19:29 AM CST, Hardy Ferentschik wrote: > Answers inline > > On Jan 12, 2012, at 9:50 AM, Gail Badner wrote: > >> I've uploaded the 4.0.1.Final documentatation to >> http://docs.jboss.org/hibernate/core/4.0/. >> >> Maybe this was already discussed but, should the switch from >> "core" to "orm" affect the URL for the 4.0 documentation (i.e., >> http://docs.jboss.org/hibernate/orm/4.0/)? > > I think it makes sense to switch the urls. However, in this case I > suggest we also put a redirect in place for > http://docs.jboss.org/hibernate/core/4.0/ to > http://docs.jboss.org/hibernate/orm/4.0/ > Just renaming the directories is probably not a good idea due to > bookmarks and people used to go to the 'core' url. If we change to > orm we need to update the pointers from > http://www.hibernate.org/docs I agree, we should do a redirect. I had not planned on changing the physical dir until 4.1 as that is when the new docs would be getting used. 6 in one... if you feel the itch, go for it. >> Also, I noticed that http://docs.jboss.org/hibernate/stable/core/ >> points to 3.6.9.Final docs. Should it point to >> http://docs.jboss.org/hibernate/core/4.0/ (or >> http://docs.jboss.org/hibernate/orm/4.0/)? > > Stable should definitely point to 4.0. That's independent of > whether we rename the urls + 1 >> I ended up using the documentation downloaded from the SourceForge >> distribution because I got errors when I tried to build the >> Javadoc from the 4.0.1 tag using "gradle javadoc": >> >> /NotBackedUp/gbadner/git/hibernate-core-master/hibernate-core/src/main/java/org/hibernate/metamodel/source/annotations/HibernateDotNames.java:109: >> cannot find symbol >> symbol : variable DotName >> location: interface >> org.hibernate.metamodel.source.annotations.HibernateDotNames >> DotName ACCESS_TYPE = DotName.createSimple( >> AccessType.class.getName() ); >> >> What command should be used to build Javadoc? > > 'gradle javadoc' is the default javadoc task which you get when you > use the Java plugin. It build the javadocs for the current module. > In our case we don't use this task, because > we want aggregated docs. To get the aggregated docs you need to run > the 'aggregateJavadocs' from the release module. > > './gradlew aggregateJavadocs' Just a minor point. If you run it from the release module, it has to be `../gradlew aggregateJavadocs` Alternatively from root you could run `./gradlew :release:aggregateJavadocs` > FYI, the javadoc task needs all dependencies on the classpath when > executing. Looking at the error it seems jandex is not on the > classpath. This might be related to HHH-6921, but that's just a > guess. > As said, the default javadocs tasks are not configured, because we > are only interested in the aggregated docs. I think Strong only changed that to move jandex to the provided configuration. I was able to run these fine when I did the build. >> I also noticed that the Javadoc includes test classes. It would be >> nice to exclude those. > > right, even the aggregated docs seem to include test classes. I > would create a jira and we reconfigure the task for the next > release Hmm, I spent a lot of time getting those right. https://fisheye2.atlassian.com/changelog/Hibernate-Core?cs=39d47c4b39f231... If they are back, something after fucked those changes up. >> I really liked how convenient it was to be able to just copy the >> contents of the documentation directory from the distribution >> into the staging directory for rsync-ing. The only change I had >> to make after copying was to change hem/en to hem/en-US. I >> haven't looked into this, but I imagine that would be an easy >> thing to fix. We should update that in the source tree. But to be honest, hem docs should really just go away as a separate thing. Their content should be merged into the main docs. > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev