Re: [hibernate-dev] website migration
On 19 mars 2010, at 03:57, Hardy Ferentschik wrote: >> - I'm personally not a big fan multiple ways of reaching the same page (ie >> top bar with nesting drop menus and the "quicklinks") > > I could drop the quick links for Search, Validator and Metamodelgen as well. > I just added them, because Core had a quick link section. Sure. The most important is to have it consistent across the hibernate pages. I was expressing my opinion and asked for feedback. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] website migration
On 19 mars 2010, at 06:24, Steve Ebersole wrote: > On 03/18/2010 05:11 PM, Emmanuel Bernard wrote: >> Hello, >> >> I've done a few changes: >> - I've homogenized the list of projects (dark background) for all >> subprojects + core. I felt it was confusing to get that changed >> - I've put the list of subprojects atop the getting started links to be >> consistent with the other subproject pages > I personally do not view core as a subproject. I have heard both views. > I'd prefer if we discuss changes like this prior to you coming in and > just changing them to what you think. Personally I'd prefer to look at > it as these are project pages and each sub-project has its own magnolia > "project". Then the community is handled in Clearspace. Feel free to > coordinate that with the jboss commmunity team and set it up. This change was not about Core being the top-level project or a subproject. It was about navigation consistency. > >> - the admin site is super slow too > I assume you mean the author site. Dunno, in what way? Each change takes an average of 15 to 20 seconds to be displayed. Same from the page activation button click to the pop-up being closed and the main page refreshed, it's about 30 seconds. >> - can we activate several pages at the same time, or is it a one page at a >> time activation? > You can activate a node and below. Cool, I haven't been able to find the feature, I will look again. > > >> - the supported in should probably be declined for each subproject (at >> least Validator and Search) > see above The thing is Hibernate Search and HV are supported in EAP but not in the other platforms Core is. >> - I'm personally not a big fan multiple ways of reaching the same page (ie >> top bar with nesting drop menus and the "quicklinks") >> - some grey menus don't seem clickable (like build) > If you don't set up the links in the nav for the node then they are not > enabled, correct. >> - the old links are pointing to a broken version of the site (like >> http://www.hibernate.org/410.html ). > Such as where? What is 410.html? If its important then we have url > remapping set up for certain old urls and can do the same here. http://www.hibernate.org/410.html is the first link that the search box returns when you search for "hibernate search". Here is the list on top of my head hibernate search home page | hibernate.org/410.html => http://hibernate.org/subprojects/search hibernate validator home page | hibernate.org/412.html => http://hibernate.org/subprojects/validator hibernate annotation and entitymanager home page | hibernate.org/397.html => http://hibernate.org/hibernate I've asked helpdesk/jboss.org to set them up. >> - the search engine is google but does not restrict to the website, so you >> end up on external pages (or the broken links of the old website) > No clue how that works OK I'll ask helpdesk/jboss.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] website migration
On 19 mars 2010, at 06:32, Steve Ebersole wrote: > Oops, one of my response got cut off... > >>> Todos? / remarks after seeing the site live: >>> - I feel like Core should be a subproject like the other ones, ie have >>> a generic welcome page but also a specialized page for core. Otherwise >>> it's a bit confusing as we mix the notions of Hibernate the portfolio >>> and Hibernate Core the ORM. >> IMO that was a mistake we made > > IMO that was a mistake we made a long time ago. Its not even > "portfolio". The issue is the difference in the notion of a community > and projects. We have one community and many projects that make up the > community. Like I said in the original email I think there should be: > 1) project pages which house the basic info for each project (where do i > get docs, download, etc). > 2) community site Yes but today's situation is like if JBoss AS was the top level project of all jboss.org projects and the jboss.org home page was pointing to AS docs, AS release infos etc and had subproject links to drools and co. In Hibernate there are two categories of projects. The ones that gravitate around the core ORM and require it or are useful in its context alone: - (core) - shards - metamodel generator The ones that can run without core or an ORM: - search - validator - (bean valiidation) And of course there is tools which for some reason is always uncategorizable :) Maybe we should differentiate them on the project pages ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] website migration
As I said in the other email and here below as well, my preference was that each project was its own project as far as magnolia was concerned. The issue there is the domain name to an extent. Think of it in terms of the author UI: / ... hibernate/ hibernate-search/ hibernate-validator/ hibernate-shards/ hibernate-metamodel-generator/ ... Or in terms of urls: hibernate.org/hibernate hibernate.org/hibernate-search ... The idea being that each is its own project and can define its own license(s), jsr(s), product support, downloads, docs, jira, etc. Then we just "bind" them visually via LnF. The Clearspace/Collab site is where we do community stuff. Anyway that was my opinion. I have recently been told by some ass that I cannot design a website though so take it for what its worth :) On 03/19/2010 04:12 AM, Emmanuel Bernard wrote: > > On 19 mars 2010, at 06:32, Steve Ebersole wrote: > >> Oops, one of my response got cut off... >> Todos? / remarks after seeing the site live: - I feel like Core should be a subproject like the other ones, ie have a generic welcome page but also a specialized page for core. Otherwise it's a bit confusing as we mix the notions of Hibernate the portfolio and Hibernate Core the ORM. >>> IMO that was a mistake we made >> >> IMO that was a mistake we made a long time ago. Its not even >> "portfolio". The issue is the difference in the notion of a community >> and projects. We have one community and many projects that make up the >> community. Like I said in the original email I think there should be: >> 1) project pages which house the basic info for each project (where do i >> get docs, download, etc). >> 2) community site > > Yes but today's situation is like if JBoss AS was the top level project of > all jboss.org projects and the jboss.org home page was pointing to AS docs, > AS release infos etc and had subproject links to drools and co. > > In Hibernate there are two categories of projects. > > The ones that gravitate around the core ORM and require it or are useful in > its context alone: > - (core) > - shards > - metamodel generator > > The ones that can run without core or an ORM: > - search > - validator > - (bean valiidation) > > And of course there is tools which for some reason is always uncategorizable > :) > > Maybe we should differentiate them on the project pages -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] website migration
Right, the key is to keep a unified UI and navigation (keep links back and forth the technically different projects sharing the hibernate name). I think what you are describing would work nicely at least for Search and Validator as we are modularizing them and Validator has Bean Validation attached to it. Of course it would be ideal to have independent magnolia projects but with URLs like hibernate/, hibernate/search/ etc but that's life :) On 19 mars 2010, at 14:09, Steve Ebersole wrote: > As I said in the other email and here below as well, my preference was that > each project was its own project as far as magnolia was concerned. The issue > there is the domain name to an extent. > > Think of it in terms of the author UI: > / > ... > hibernate/ > hibernate-search/ > hibernate-validator/ > hibernate-shards/ > hibernate-metamodel-generator/ > ... > > Or in terms of urls: > hibernate.org/hibernate > hibernate.org/hibernate-search > ... > > The idea being that each is its own project and can define its own > license(s), jsr(s), product support, downloads, docs, jira, etc. > > Then we just "bind" them visually via LnF. > > The Clearspace/Collab site is where we do community stuff. > > Anyway that was my opinion. I have recently been told by some ass that I > cannot design a website though so take it for what its worth :) > > On 03/19/2010 04:12 AM, Emmanuel Bernard wrote: >> >> On 19 mars 2010, at 06:32, Steve Ebersole wrote: >> >>> Oops, one of my response got cut off... >>> > Todos? / remarks after seeing the site live: > - I feel like Core should be a subproject like the other ones, ie have > a generic welcome page but also a specialized page for core. Otherwise > it's a bit confusing as we mix the notions of Hibernate the portfolio > and Hibernate Core the ORM. IMO that was a mistake we made >>> >>> IMO that was a mistake we made a long time ago. Its not even >>> "portfolio". The issue is the difference in the notion of a community >>> and projects. We have one community and many projects that make up the >>> community. Like I said in the original email I think there should be: >>> 1) project pages which house the basic info for each project (where do i >>> get docs, download, etc). >>> 2) community site >> >> Yes but today's situation is like if JBoss AS was the top level project of >> all jboss.org projects and the jboss.org home page was pointing to AS docs, >> AS release infos etc and had subproject links to drools and co. >> >> In Hibernate there are two categories of projects. >> >> The ones that gravitate around the core ORM and require it or are useful in >> its context alone: >> - (core) >> - shards >> - metamodel generator >> >> The ones that can run without core or an ORM: >> - search >> - validator >> - (bean valiidation) >> >> And of course there is tools which for some reason is always uncategorizable >> :) >> >> Maybe we should differentiate them on the project pages > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] website migration
>>> - the old links are pointing to a broken version of the site (like >>> http://www.hibernate.org/410.html ). >> Such as where? What is 410.html? If its important then we have url >> remapping set up for certain old urls and can do the same here. > > http://www.hibernate.org/410.html is the first link that the search box > returns when you search for "hibernate search". > > Here is the list on top of my head > hibernate search home page | hibernate.org/410.html => > http://hibernate.org/subprojects/search > hibernate validator home page | hibernate.org/412.html => > http://hibernate.org/subprojects/validator > hibernate annotation and entitymanager home page | hibernate.org/397.html => > http://hibernate.org/hibernate > > I've asked helpdesk/jboss.org to set them up. You need to give them the link. If it needs to point to a wiki page be sure to give them the permalink -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search 421
Hi Please find updated patch with the removal of the enum singleton. Thanks Amin On 17 Mar 2010, at 12:58, Sanne Grinovero wrote: > Hi Amin, > thanks for the update, see some thoughts: > > 2010/3/16 Amin Mohammed-Coleman : >> Hi folks, >> >> I've removed the enum singleton and created a class(BackendExceptionHandler) >> which has 2 methods: >> >> >> public Thread.UncaughtExceptionHandler >> getUncaughtExceptionHandler(SearchConfiguration configuration); >> >> public boolean logException(SearchConfiguration configuration) > > Care to explain how I should use them? Are we not going to have a > common interface? In that case does it make sense to have a method > named "logException", which would imply a logging implementation? > >> >> The issue that I'm looking at is getting the search configuration to the >> methods. In order to get the SearchConfiguration to the methods defined in >> BackendExceptionHandler, I have to thread SearchFactoryImplementor. >> >> Using this approach I will have to define a method to get the search >> configuration from the SearchFactoryImplementor. I'm guess this isn't the >> best approach as this requires a significant change. I don't know what >> peoples thoughts are on this. I'm looking to set the >> BackendExceptionHandler up when the SearchFactory is created and then use >> it. Is there any currently approach that does something similar? > > Ah there's a subtle problem with that, which is that we can't hold a > reference in Search to a Configuration at runtime: use it at > SearchFactory creation, extract all what you need, but then you have > to clear references or we're going to have a memory leak. [1] > The solution is, as we do with all components, to start them during > SearchFactory initialization and then expose a getter to initialized > service. > > [1] http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-314 > > Cheers and thanks for the complex work, > Sanne > >> >> >> Thanks for your patience with this one. >> >> Cheers >> Amin >> >> >> >> >> On 9 Mar 2010, at 13:00, Amin Mohammed-Coleman wrote: >> >>> Hi Sanne >>> >>> You are right and Im not happy with the enum class. I wanted to have a >>> single configuration that was available on the creation of the search >>> factory and re use when required. I'll take a look at changing that with a >>> better solution. >>> >>> Cheers >>> >>> Amin >>> >>> Sent from my iPhone >>> >>> On 9 Mar 2010, at 12:47, Sanne Grinovero wrote: >>> yes that is it; There has been some talking about other strategies as well on previous mails, like jms, but that lead to nowhere so yes I'm suggesting now to forget about other default implementations at the moment and proceed as you just said. 2010/3/9 Emmanuel Bernard : > I thought the goal was to have something pluggable with two default impls > (exception and log). If that's what you are describing I am ok, if not, > then I don't understand ;) > > On 9 mars 2010, at 12:08, Sanne Grinovero wrote: > >> Emmanuel are you ok with this if we either log or rethrow the >> exception back to application code? jms et al looks complex and I >> don't see the benefit. > > >> >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
