[hibernate-dev] NoORM - New groupId and relocation artifacts
Hi, So, with Gunnar, we did the work to rename the groupId and relocate the artifacts of Validator. It would be nice if we could be consistent on the way we do it. So what we did: - we created a relocation/ directory/parent artifact containing all the relocation artifacts - we only enable the build of the relocation artifacts if the relocation profile is enabled (the release scripts are already updated to take this new profile into account) See these commits for the details: - https://github.com/hibernate/hibernate-validator/commit/744b4c525c527e510648da8fed6c7e0fce8dd95c - https://github.com/hibernate/hibernate-noorm-release-scripts/commit/0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 If you have any question, feel free to ask. HTH -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Commons project
Hi, So, as discussed at the F2F, I set up an hibernate-commons project. Currently, it's here https://github.com/gsmet/hibernate-commons, waiting for everyone to agree on the name, the license, the purpose and so on. We would like to make quick progress on it as it's blocking for the migration of Search and OGM to the new AsciiDoctor output (we are still using Docbook as the final output for these projects). It would be nice if we could move them to this output for Search 5.7 and OGM 5.1 which are planned for the coming weeks. Basically the idea behind this repo is to centralize things useful to all (or several) Hibernate projects: - an AsciiDoctor theme - testing utilities we would like to share for all the Hibernate projects - (still to be decided as not that obvious) utilities we would like to share for the NoORM projects Things that should be discussed: == The groupId I used hibernate-commons as it seemed like an obvious groupId. The fact is that we already have hibernate-commons-annotations here. Thoughts? == The license Most of our projects are LGPL licensed except for HV which is Apache 2 licensed. Which license should we choose? == The AsciiDoctor theme So the theme I put in is slightly different from the one from ORM: - the top banner is white instead of black. The black banner was a bit too aggressive to my taste; - I was very light on customizing the HTML output as I would really like us to not spend time on maintaining it. So it's basically the default output whereas ORM has customized the color of the titles of the links and several other things. I think the default output is really nice and we can keep it as is; - I customized the PDF output a bit more as there were problems with the default output. I think it's pretty good now. Here is the current output for Search: - HTML: http://docs.jboss.org/hibernate/beta/html_single/ - PDF: http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf -> note that if you want to use a specific theme for specific purposes, it would still be possible. It's a base you can configure with your own CSS and such. Thoughts? -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV/HSEARCH] Free form
Hi, Did the same this week-end, and adapted your work to match the bigger picture of what we discussed on Friday. Basically the "StructureTraverser" is now called "ValueProcessor", because it's not responsible for exposing the internals of a structure anymore, but only to process a structure according to previously defined metadata, passing the output to the "DocumentContext". I think it's the second option you suggested. It makes sense in my opinion, since metadata will be defined differently for different source types (POJO, JSON, ...). This design allows in particular what Sanne suggested: when bootstrapping, we can build some kind of "walker" (a composition of "ValueProcessors") from the metadata, and avoid metadata lookup at runtime. The snippet is there: https://gist.github.com/yrodiere/ 9ff8fe8a8c7f59c1a051b36db20fbd4d I'm sure it'll have to be refined to address additional constraints, but in its current state it seems to address all of our requirements. Yoann Rodière Hibernate NoORM Team On 27 January 2017 at 18:23, Emmanuel Bernard wrote: > I took the flight home to play with free form and specifically how we > would retrieve data from the free form structure. > By free-form I mean non POJO but they will have schema (not expressed > here). > > https://github.com/emmanuelbernard/hibernate-search/commit/ > 0bd3fbab137bdad81bfa5b9934063792a050f537 > > And in particular > https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/StructureTraverser.java > https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/pojo/impl/PojoStructureTraverser.java > > It probably does not compile, I could not make the build work. > > I figured it was important to dump this raw thinking because it will > influence and will be influenced by the redesign of the DocumentBuilder of > Hibernate Search. > > There are several options for traversing a free form structure > - expose the traversing API as a holder to navigate all properties per > structure and sub structure. This is what the prototype shows. Caching > needs to be accessed via a hashmap get or other lookup. Metadata and the > traversing structure will be navigated in parallel > - expose a structure that is specialized to a single property or container > unwrapping aspect. The structures will be spread across and embedded in the > Metadata > > > Another angle: > - create a traversable object per payload to carry it (sharing metadata > info per type) > - have a stateless traversable object that is provided the payload for > each access > > The former seems better as it does not create a traversable object per > object navigated. > The latter is better for payloads that need parsing or are better at > sequential access since state could be cached. > > We need to discuss that and know where DocumentBuilder is going to > properly design this API. > > Emmanuel > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
Everything you said seems to make sense to me, so +1. We can see later whether we agree on the other common projects we could add (checkstyle rules, test utils, ...), but I think there won't be many arguments *against* them as long as there is no transitive dependency to these projects for end users. It's mostly about how we work internally, after all. About the specifics: == The groupId To me it seems to make perfect sense to move hibernate-commons-annotations to the same repo, but I can understand it'll cause some trouble to developers. At the very least we could just rename org.hibernate:hibernate-commons-annotations to org.hibernate.commons:hibernate-commons-annotations, so that we'll be consistent with the other 6.x groupId renamings. As for moving code between repos, we can always see about that later: it won't impact end users. == The license On the license side, I think we can only license our common projects under Apache License 2, because one cannot include LGPL work within an ASL2 work. So using LGPL would prevent us from using the projects in HV... probably. Source: http://www.apache.org/legal/resolved.html#category-x > The LGPL is ineligible primarily due to the restrictions it places on larger works, violating the third license criterion. Yoann Rodière Hibernate NoORM Team On 30 January 2017 at 11:23, Guillaume Smet wrote: > Hi, > > So, as discussed at the F2F, I set up an hibernate-commons project. > > Currently, it's here https://github.com/gsmet/hibernate-commons, waiting > for everyone to agree on the name, the license, the purpose and so on. > > We would like to make quick progress on it as it's blocking for the > migration of Search and OGM to the new AsciiDoctor output (we are still > using Docbook as the final output for these projects). It would be nice if > we could move them to this output for Search 5.7 and OGM 5.1 which are > planned for the coming weeks. > > Basically the idea behind this repo is to centralize things useful to all > (or several) Hibernate projects: > - an AsciiDoctor theme > - testing utilities we would like to share for all the Hibernate projects > - (still to be decided as not that obvious) utilities we would like to > share for the NoORM projects > > Things that should be discussed: > > == The groupId > > I used hibernate-commons as it seemed like an obvious groupId. The fact is > that we already have hibernate-commons-annotations here. > > Thoughts? > > == The license > > Most of our projects are LGPL licensed except for HV which is Apache 2 > licensed. Which license should we choose? > > == The AsciiDoctor theme > > So the theme I put in is slightly different from the one from ORM: > - the top banner is white instead of black. The black banner was a bit too > aggressive to my taste; > - I was very light on customizing the HTML output as I would really like us > to not spend time on maintaining it. So it's basically the default output > whereas ORM has customized the color of the titles of the links and several > other things. I think the default output is really nice and we can keep it > as is; > - I customized the PDF output a bit more as there were problems with the > default output. I think it's pretty good now. > > Here is the current output for Search: > - HTML: http://docs.jboss.org/hibernate/beta/html_single/ > - PDF: > http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf > > -> note that if you want to use a specific theme for specific purposes, it > would still be possible. It's a base you can configure with your own CSS > and such. > > Thoughts? > > -- > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
# groupId +1 for the name "hibernate-commons". I wouldn't want to move the hibernate-commons-annotations project though. This project is stable, not evolving much yet several branches will need to be maintained for very long time still. Moving repositories would make maintenance trickier for no other reason than satisfying some weird form of OCD.. incidentally, I totally relate with the urge to move it but I think we'll have to deal with that ;) # License It's not technically true that an ASL2 project can not depend on LGPL work; I suspect you might get confused with requirements of the Apache Foundation on projects hosted on the foundation: "Apache Products" those requirements are stricter than their license, and Hibernate Validator just uses the ASL2 license but is not an Apache Product. I'm not against using ASL2 for this project, especially since such confusion is common that could help avoiding debates.. but since it contains branding elements (I assume that e.g. the asciidoc style contains logos?) we might actually need to check with legal which licenses are fine with some help from Red Hat legal. # Style +1 I also like the white top banner better. I hope the ORM team will prefer it too, so that we can 1) keep consistency 2) share these. Thanks! Sanne On 30 January 2017 at 11:03, Yoann Rodiere wrote: > Everything you said seems to make sense to me, so +1. > We can see later whether we agree on the other common projects we could add > (checkstyle rules, test utils, ...), but I think there won't be many > arguments *against* them as long as there is no transitive dependency to > these projects for end users. It's mostly about how we work internally, > after all. > > About the specifics: > > == The groupId > > To me it seems to make perfect sense to move hibernate-commons-annotations > to the same repo, but I can understand it'll cause some trouble to > developers. At the very least we could just rename > org.hibernate:hibernate-commons-annotations to > org.hibernate.commons:hibernate-commons-annotations, so that we'll be > consistent with the other 6.x groupId renamings. As for moving code between > repos, we can always see about that later: it won't impact end users. > > == The license > > On the license side, I think we can only license our common projects under > Apache License 2, because one cannot include LGPL work within an ASL2 work. > So using LGPL would prevent us from using the projects in HV... probably. > Source: http://www.apache.org/legal/resolved.html#category-x >> The LGPL is ineligible primarily due to the restrictions it places on > larger works, violating the third license criterion. > > > Yoann Rodière > Hibernate NoORM Team > > On 30 January 2017 at 11:23, Guillaume Smet > wrote: > >> Hi, >> >> So, as discussed at the F2F, I set up an hibernate-commons project. >> >> Currently, it's here https://github.com/gsmet/hibernate-commons, waiting >> for everyone to agree on the name, the license, the purpose and so on. >> >> We would like to make quick progress on it as it's blocking for the >> migration of Search and OGM to the new AsciiDoctor output (we are still >> using Docbook as the final output for these projects). It would be nice if >> we could move them to this output for Search 5.7 and OGM 5.1 which are >> planned for the coming weeks. >> >> Basically the idea behind this repo is to centralize things useful to all >> (or several) Hibernate projects: >> - an AsciiDoctor theme >> - testing utilities we would like to share for all the Hibernate projects >> - (still to be decided as not that obvious) utilities we would like to >> share for the NoORM projects >> >> Things that should be discussed: >> >> == The groupId >> >> I used hibernate-commons as it seemed like an obvious groupId. The fact is >> that we already have hibernate-commons-annotations here. >> >> Thoughts? >> >> == The license >> >> Most of our projects are LGPL licensed except for HV which is Apache 2 >> licensed. Which license should we choose? >> >> == The AsciiDoctor theme >> >> So the theme I put in is slightly different from the one from ORM: >> - the top banner is white instead of black. The black banner was a bit too >> aggressive to my taste; >> - I was very light on customizing the HTML output as I would really like us >> to not spend time on maintaining it. So it's basically the default output >> whereas ORM has customized the color of the titles of the links and several >> other things. I think the default output is really nice and we can keep it >> as is; >> - I customized the PDF output a bit more as there were problems with the >> default output. I think it's pretty good now. >> >> Here is the current output for Search: >> - HTML: http://docs.jboss.org/hibernate/beta/html_single/ >> - PDF: >> http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf >> >> -> note that if you want to use a specific theme for specific purposes, it >> would still be possible. It's a base you can co
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
Nothing major, but still this got me wondering: - why the parent pom "hibernate-validator-relocation" ? - why the profile switch? do you plan to omit these artifacts for - say - nightly builds and local testing of other projects depending on it? - what's the benefit you're hoping to achieve by being consistent with this approach? Thanks, Sanne On 30 January 2017 at 09:55, Guillaume Smet wrote: > Hi, > > So, with Gunnar, we did the work to rename the groupId and relocate the > artifacts of Validator. > > It would be nice if we could be consistent on the way we do it. > > So what we did: > - we created a relocation/ directory/parent artifact containing all the > relocation artifacts > - we only enable the build of the relocation artifacts if the relocation > profile is enabled (the release scripts are already updated to take this > new profile into account) > > See these commits for the details: > - > https://github.com/hibernate/hibernate-validator/commit/744b4c525c527e510648da8fed6c7e0fce8dd95c > - > https://github.com/hibernate/hibernate-noorm-release-scripts/commit/0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 > > If you have any question, feel free to ask. > > HTH > > -- > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
One benefit we always get by being consistent is that it's easier for a newcomer to switch from project to project... If it doesn't require more work, we may as well be consistent. Anyway, thanks Guillaume, I added this piece of information to the HSearch ticket: https://hibernate.atlassian.net/browse/HSEARCH-2557 Yoann Rodière Hibernate NoORM Team On 30 January 2017 at 13:01, Sanne Grinovero wrote: > Nothing major, but still this got me wondering: > - why the parent pom "hibernate-validator-relocation" ? > - why the profile switch? do you plan to omit these artifacts for - > say - nightly builds and local testing of other projects depending on > it? > - what's the benefit you're hoping to achieve by being consistent > with this approach? > > Thanks, > Sanne > > > On 30 January 2017 at 09:55, Guillaume Smet > wrote: > > Hi, > > > > So, with Gunnar, we did the work to rename the groupId and relocate the > > artifacts of Validator. > > > > It would be nice if we could be consistent on the way we do it. > > > > So what we did: > > - we created a relocation/ directory/parent artifact containing all the > > relocation artifacts > > - we only enable the build of the relocation artifacts if the relocation > > profile is enabled (the release scripts are already updated to take this > > new profile into account) > > > > See these commits for the details: > > - > > https://github.com/hibernate/hibernate-validator/commit/ > 744b4c525c527e510648da8fed6c7e0fce8dd95c > > - > > https://github.com/hibernate/hibernate-noorm-release-scripts/commit/ > 0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 > > > > If you have any question, feel free to ask. > > > > HTH > > > > -- > > Guillaume > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero wrote: > Nothing major, but still this got me wondering: > - why the parent pom "hibernate-validator-relocation" ? > To avoid having too many useless directories in the parent directory. > - why the profile switch? do you plan to omit these artifacts for - > say - nightly builds and local testing of other projects depending on > it? > Because it's less noisy when we do a normal build. It's already noisy enough. > - what's the benefit you're hoping to achieve by being consistent > with this approach? > Well, is being consistent not a big enough benefit? -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
On Mon, Jan 30, 2017 at 12:44 PM, Sanne Grinovero wrote: > # groupId > +1 for the name "hibernate-commons". > > I wouldn't want to move the hibernate-commons-annotations project > though. This project is stable, not evolving much yet several branches > will need to be maintained for very long time still. > Moving repositories would make maintenance trickier for no other > reason than satisfying some weird form of OCD.. incidentally, I > totally relate with the urge to move it but I think we'll have to deal > with that ;) > Note that the current version of hibernate-commons-annotations is org.hibernate.common (without the s at the end, not org.hibernate as Yoann stated it). Moving hibernate-commons-annotations is not such a good idea IMHO: - it's licensed under the LGPL so it would force us to use this license (or relicense it or having different licenses for the submodules but they are all bad ideas) - we would release a new version of this module each time we want to upgrade the theme and I don't think it would be readable for consumers of this preexisting artifact. The latter point is what worries me about centralizing all the utils in the same repo with the same lifecycle. > # License > It's not technically true that an ASL2 project can not depend on LGPL > work; I suspect you might get confused with requirements of the Apache > Foundation on projects hosted on the foundation: "Apache Products" > those requirements are stricter than their license, and Hibernate > Validator just uses the ASL2 license but is not an Apache Product. > I'm not against using ASL2 for this project, especially since such > confusion is common that could help avoiding debates.. but since it > contains branding elements (I assume that e.g. the asciidoc style > contains logos?) we might actually need to check with legal which > licenses are fine with some help from Red Hat legal. > Yes, the AsciiDoctor theme contains the Hibernate logo. But so does the HV repository. I don't think it's an issue. > # Style > +1 I also like the white top banner better. I hope the ORM team will > prefer it too, so that we can 1) keep consistency 2) share these. > You see that you like consistency ;). -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
On 30 January 2017 at 12:49, Guillaume Smet wrote: > On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero > wrote: >> >> Nothing major, but still this got me wondering: >> - why the parent pom "hibernate-validator-relocation" ? > > > To avoid having too many useless directories in the parent directory. > >> >> - why the profile switch? do you plan to omit these artifacts for - >> say - nightly builds and local testing of other projects depending on >> it? > > > Because it's less noisy when we do a normal build. It's already noisy > enough. > >> >> - what's the benefit you're hoping to achieve by being consistent >> with this approach? > > > Well, is being consistent not a big enough benefit? Different projects have different needs. Consistency is nice, and certainly makes it easier to find oneself comfortably "at home" when jumping from one project to another, but it also is inconvenient to do things "for consistency" when one has different requirements. So when it comes to trivial changes, IMO practicality trumps need for consistency. But ok, +1 for consistency then. My question was merely to explore if I had missed something non-trivial. Thanks, Sanne > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero wrote: > Different projects have different needs. Consistency is nice, and > certainly makes it easier to find oneself comfortably "at home" when > jumping from one project to another, but it also is inconvenient to do > things "for consistency" when one has different requirements. > I don't think we would have different requirements regarding the relocation artifacts. But if you see any issue with the approach we chose for HV, interesting in hearing them so that we can have the same approach for the different NoORM project. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Update Jenkins plugins
I didn't have time to do it. I'll postponed the updates to next week: the 9th of February Thanks, Davide On Tue, Jan 17, 2017 at 4:56 PM, Davide D'Alto wrote: > Hi, > there are some plugins to upgrade on Jenkins and it seems they have > some non trivial changes. > > I'll do that on Thursday and hopefully it won't cause too many issues. > > Thanks, > Davideb ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
On 30 January 2017 at 13:58, Guillaume Smet wrote: > Note that the current version of hibernate-commons-annotations is > org.hibernate.common (without the s at the end, not org.hibernate as Yoann > stated it). > You're right. Wouldn't the simplest solution be to use the same groupId (without a "s") in our new repo? > Moving hibernate-commons-annotations is not such a good idea IMHO: > - it's licensed under the LGPL so it would force us to use this license (or > relicense it or having different licenses for the submodules but they are > all bad ideas) > It sure seems complicated. But relicensing from LGPL to ASL2 may not be such a big deal, since LGPL seems stricter than ASL2. Couldn't we simply dual-license the whole repository under ASL2/LGPL? That way, previous users wouldn't need to be aware of the change, and new users could choose to comply with whichever suits them best. Or does it require to release two packages for each submodule (one for each license)? Anyway... there are other reasons for not wanting to move the code to another repo, so maybe we could just focus on having consistent group IDs and let the code live in different places and have different maven parents. > - we would release a new version of this module each time we want to > upgrade the theme and I don't think it would be readable for consumers of > this preexisting artifact. > > The latter point is what worries me about centralizing all the utils in the > same repo with the same lifecycle. > We already got through this discussion, but let's sum it up: - With a common versioning, consuming projects will only have to take care to use the latest version available and use it for every common project they depend on. - With a common versioning, consuming projects will retain the ability to punctually use an older version for some subproject. Sure, on the day we decide to break something, we'll have to bump the minor or major for every "common" project, and it will give the false impression that every such project has breaking changes. But we don't wan't to do that often, and we'll probably won't have so many common projects anyway. Having separate lifecycles/repos is probably cleaner, but it has its own downsides: - Consuming poms will be less readable and less easily updated (one version per consumed common project). - Releasing the common projects will be more work. - Maintenance will be a bit harder (having multiple scattered repos to work on). - We'll run the risk of some common projects not being updated, in particular the version of their dependencies. Which could be avoided, or at least be less likely, if we centralize the dependency management in the parent pom of the common projects. We can leave hibernate-common-annotations where it is, since it's pre-existing and already critical in several of our projects, so its maintenance is pretty much guaranteed. But that kind of splitting seems dangerous for the new common projects, because it makes it harder to maintain them, and there will be no full-time maintainers. So we'd better not split these common projects any further, and give these projects a chance to get regular maintenance... Yoann Rodière Hibernate NoORM Team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere wrote: > > On 30 January 2017 at 13:58, Guillaume Smet > wrote: > >> Note that the current version of hibernate-commons-annotations is >> org.hibernate.common (without the s at the end, not org.hibernate as Yoann >> stated it). >> > You're right. Wouldn't the simplest solution be to use the same groupId > (without a "s") in our new repo? > I'm not so sure it's a good idea to share the groupId while it being a completely different project. I'm starting to think that maybe the good groupId for these common internal projects could be org.hibernate.*internal*. We plan them to be purely internal artifacts and we might as well state it. What do you all think about it? > Moving hibernate-commons-annotations is not such a good idea IMHO: >> - it's licensed under the LGPL so it would force us to use this license >> (or >> relicense it or having different licenses for the submodules but they are >> all bad ideas) >> > > It sure seems complicated. But relicensing from LGPL to ASL2 may not be > such a big deal, since LGPL seems stricter than ASL2. > Couldn't we simply dual-license the whole repository under ASL2/LGPL? That > way, previous users wouldn't need to be aware of the change, and new users > could choose to comply with whichever suits them best. > Yeah, dual licensing might be the better solution. But I think it would be OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject. > - we would release a new version of this module each time we want to >> upgrade the theme and I don't think it would be readable for consumers of >> this preexisting artifact. >> >> The latter point is what worries me about centralizing all the utils in >> the >> same repo with the same lifecycle. >> > > We already got through this discussion, but let's sum it up: > Not exactly. I was specifically talking about hibernate-commons-annotations as it's a different beast: it's already released and people might use it in their projects. Thus I don't think it's a good idea to think of it as a purely internal project. IMHO, it makes a difference. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
Well let's investigate what this consistency means across projects first. As Sanne mentions, if it makes it building ORM more difficult then I'd be -1 it too. But I promise to take a peek when I get back from PTO in a few days. Or maybe Andrea can in the next few days as he already has worked on the changes to release relocation artifacts for ORM; I just do not know when he is coming back from PTO. Either way we will have looked at it for ORM by the end of week. On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet wrote: On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero wrote: > Different projects have different needs. Consistency is nice, and > certainly makes it easier to find oneself comfortably "at home" when > jumping from one project to another, but it also is inconvenient to do > things "for consistency" when one has different requirements. > I don't think we would have different requirements regarding the relocation artifacts. But if you see any issue with the approach we chose for HV, interesting in hearing them so that we can have the same approach for the different NoORM project. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
Disclaimer : I have not yet looked at the Asciidoc style. Again I promise to look at it when I come back from PTO. That said I want to make certain that the developed style matches the new ORM documentation style. The design team at Red Hat spent a lot of time helping us develop that. Specifically I mean the banners and general color scheme. On Mon, Jan 30, 2017 at 9:43 AM Guillaume Smet wrote: > On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere > wrote: > > > > > On 30 January 2017 at 13:58, Guillaume Smet > > wrote: > > > >> Note that the current version of hibernate-commons-annotations is > >> org.hibernate.common (without the s at the end, not org.hibernate as > Yoann > >> stated it). > >> > > You're right. Wouldn't the simplest solution be to use the same groupId > > (without a "s") in our new repo? > > > > I'm not so sure it's a good idea to share the groupId while it being a > completely different project. > > I'm starting to think that maybe the good groupId for these common internal > projects could be org.hibernate.*internal*. We plan them to be purely > internal artifacts and we might as well state it. > > What do you all think about it? > > > > Moving hibernate-commons-annotations is not such a good idea IMHO: > >> - it's licensed under the LGPL so it would force us to use this license > >> (or > >> relicense it or having different licenses for the submodules but they > are > >> all bad ideas) > >> > > > > It sure seems complicated. But relicensing from LGPL to ASL2 may not be > > such a big deal, since LGPL seems stricter than ASL2. > > Couldn't we simply dual-license the whole repository under ASL2/LGPL? > That > > way, previous users wouldn't need to be aware of the change, and new > users > > could choose to comply with whichever suits them best. > > > > Yeah, dual licensing might be the better solution. But I think it would be > OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject. > > > > - we would release a new version of this module each time we want to > >> upgrade the theme and I don't think it would be readable for consumers > of > >> this preexisting artifact. > >> > >> The latter point is what worries me about centralizing all the utils in > >> the > >> same repo with the same lifecycle. > >> > > > > We already got through this discussion, but let's sum it up: > > > > Not exactly. I was specifically talking about hibernate-commons-annotations > as it's a different beast: it's already released and people might use it in > their projects. Thus I don't think it's a good idea to think of it as a > purely internal project. > > IMHO, it makes a difference. > > -- > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
Hi Steve, Thus the NoORM prefix in the subject :). I just wanted us to be consistent across the NoORM projects. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
Umm, we could also be consistent across all of the projects since they are all Hibernate projects. On Mon, Jan 30, 2017 at 10:34 AM Guillaume Smet wrote: > Hi Steve, > > Thus the NoORM prefix in the subject :). > > I just wanted us to be consistent across the NoORM projects. > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)
Relatedly, I have been thinking whether we want to rename the ORM artifacts
as well since this is the best time if we wanted to do that.
So we know we will change the groupId to `org.hibernate.orm`.
I was thinking we might want to also either:
1. rename `hibernate-core` as `hibernate-orm`
2. rename all the artifacts following the pattern `hibernate-orm-${1}`,
e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc.
On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole wrote:
> Well let's investigate what this consistency means across projects first.
> As Sanne mentions, if it makes it building ORM more difficult then I'd be
> -1 it too. But I promise to take a peek when I get back from PTO in a few
> days. Or maybe Andrea can in the next few days as he already has worked on
> the changes to release relocation artifacts for ORM; I just do not know
> when he is coming back from PTO. Either way we will have looked at it for
> ORM by the end of week.
>
> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet
> wrote:
>
> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero
> wrote:
>
> > Different projects have different needs. Consistency is nice, and
> > certainly makes it easier to find oneself comfortably "at home" when
> > jumping from one project to another, but it also is inconvenient to do
> > things "for consistency" when one has different requirements.
> >
>
> I don't think we would have different requirements regarding the relocation
> artifacts.
>
> But if you see any issue with the approach we chose for HV, interesting in
> hearing them so that we can have the same approach for the different NoORM
> project.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] When is Dialect.requiresCastingOfParametersInSelectClause applied?
After a hiatus of 6 months, I have gone back to my PR for improving/replacing the Firebird dialect. I am running into a number of test failures which I am working through to see if they are relevant or not. One of the test failures I am looking at is org.hibernate.jpa.test.criteria.basic.ConcatTest.testSelectCaseWithConcat Firebird is rather picky about parameters occurring in the select-clause, and they will almost always need to be cast to the necessary type (and lengths). This tests seems to generate the following query: select case when concattest0_.id is not null then (?||?) else 'Empty' end as col_0_0_, trim(both ' ' from (?||?)) as col_1_0_ from TEST_ENTITY concattest0_ I have implemented Dialect#requiresCastingOfParametersInSelectClause() to return true, but unfortunately for this specific test it has no effect. The absolute minimum SQL necessary for this to work (with some caveats) is: select case when 1 = 1 then (?||?) else 'Empty' end as col_0_0_, trim(both ' ' from (cast(? as varchar(256))|| cast(? as varchar(256 as col_1_0_ from TEST_ENTITY concattest0_ And preferably the (?||?) in the case should have an explicit cast for each parameter as well, as otherwise each parameter is limited to 5 characters each (setting longer values will lead to a truncation exception). Is this something that is fixable, and if so how? Or is this one of those things where you just have to say 'aw, too bad, let it go' (or, maybe: do it later if it is really necessary)? With this specific failure out of the way: what is the general rule of thumb of handling test failures in hibernate_core for a lesser-known dialect? I currently have 257 test failures (and 512 ignored) with Firebird and my new dialect. I might add that some failures seem to be generic (eg DriverManagerRegistrationTest, StandardRefCursorSupportTest, NoCdiAvailableTest, XmlAccessTest, FetchProfileTest, IndexTest and some others). -- Mark Rotteveel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Search 5.6.0.Final and 5.7.0.CR1 released
Hello, We just released Hibernate Search 5.6.0.Final, the first stable release featuring experimental support for Elasticsearch (2.x). We also started the candidate release phase for Hibernate Search 5.7 by releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not older, see the blog post). This is the last step before 5.7 is released, so be sure to check it out so you can share your thoughts with us before the release! For more information, please see our blog: http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/ Cheers, Yoann Rodière Hibernate NoORM Team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [hibernate-announce] Hibernate Search 5.6.0.Final and 5.7.0.CR1 released
Great! Fantastic work everyone! On 30 January 2017 at 18:07, Yoann Rodiere wrote: > Hello, > > We just released Hibernate Search 5.6.0.Final, the first stable release > featuring experimental support for Elasticsearch (2.x). > > We also started the candidate release phase for Hibernate Search 5.7 by > releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not > older, see the blog post). > This is the last step before 5.7 is released, so be sure to check it out so > you can share your thoughts with us before the release! > > For more information, please see our blog: > > http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/ > > Cheers, > > Yoann Rodière > Hibernate NoORM Team > ___ > hibernate-announce mailing list > hibernate-annou...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-announce ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best time if we wanted to do that.
>
> So we know we will change the groupId to `org.hibernate.orm`.
>
> I was thinking we might want to also either:
>
>1. rename `hibernate-core` as `hibernate-orm`
>2. rename all the artifacts following the pattern `hibernate-orm-${1}`,
>e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc.
>
>
> On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole
> wrote:
>
> > Well let's investigate what this consistency means across projects first.
> > As Sanne mentions, if it makes it building ORM more difficult then I'd be
> > -1 it too. But I promise to take a peek when I get back from PTO in a
> few
> > days. Or maybe Andrea can in the next few days as he already has worked
> on
> > the changes to release relocation artifacts for ORM; I just do not know
> > when he is coming back from PTO. Either way we will have looked at it
> for
> > ORM by the end of week.
> >
> > On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet >
> > wrote:
> >
> > On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero
> > wrote:
> >
> > > Different projects have different needs. Consistency is nice, and
> > > certainly makes it easier to find oneself comfortably "at home" when
> > > jumping from one project to another, but it also is inconvenient to do
> > > things "for consistency" when one has different requirements.
> > >
> >
> > I don't think we would have different requirements regarding the
> relocation
> > artifacts.
> >
> > But if you see any issue with the approach we chose for HV, interesting
> in
> > hearing them so that we can have the same approach for the different
> NoORM
> > project.
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)
Not have a strong opinion on the renaming.
On 30 Jan 2017 19:05, "andrea boriero" wrote:
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best time if we wanted to do that.
>
> So we know we will change the groupId to `org.hibernate.orm`.
>
> I was thinking we might want to also either:
>
>1. rename `hibernate-core` as `hibernate-orm`
>2. rename all the artifacts following the pattern `hibernate-orm-${1}`,
>e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc.
>
>
> On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole
> wrote:
>
> > Well let's investigate what this consistency means across projects first.
> > As Sanne mentions, if it makes it building ORM more difficult then I'd be
> > -1 it too. But I promise to take a peek when I get back from PTO in a
> few
> > days. Or maybe Andrea can in the next few days as he already has worked
> on
> > the changes to release relocation artifacts for ORM; I just do not know
> > when he is coming back from PTO. Either way we will have looked at it
> for
> > ORM by the end of week.
> >
> > On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet >
> > wrote:
> >
> > On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero
> > wrote:
> >
> > > Different projects have different needs. Consistency is nice, and
> > > certainly makes it easier to find oneself comfortably "at home" when
> > > jumping from one project to another, but it also is inconvenient to do
> > > things "for consistency" when one has different requirements.
> > >
> >
> > I don't think we would have different requirements regarding the
> relocation
> > artifacts.
> >
> > But if you see any issue with the approach we chose for HV, interesting
> in
> > hearing them so that we can have the same approach for the different
> NoORM
> > project.
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] NoORM - New groupId and relocation artifacts
On Mon, Jan 30, 2017 at 5:37 PM, Steve Ebersole wrote: > Umm, we could also be consistent across all of the projects since they are > all Hibernate projects. > Sure. But as the build system is different, there might be different requirements/prerequisites. So, for the NoORM projects, I'd like us to be consistent as the projects have a lot of things in common. For the ORM project, it's your call. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Commons project
On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole wrote: > Disclaimer : I have not yet looked at the Asciidoc style. Again I promise > to look at it when I come back from PTO. That said I want to make certain > that the developed style matches the new ORM documentation style. The > design team at Red Hat spent a lot of time helping us develop that. > Specifically I mean the banners and general color scheme > So that you don't waste your time looking for the differences: they are not similar. There were a lot of things disturbing me in the current ORM theme (the black banner too aggressive, the lots of fonts loaded, the old icons for warning/note, some overriding that I don't find strictly necessary and don't think are worth maintaining...). The one I put there is simpler and doesn't override that many things (apart from adding the logo with the banner). That being said, it's possible to use part of what I pushed and have specific parts for what you want to keep. It was designed that way. Typically, I think you might be interested by the PDF theme anyway. If others think the ORM theme should be the one we enforce, I'll push it but I won't maintain the theme if it breaks in the future (and I'm really not convinced by the output). All in all, not a subject to work on while you're on PTO :). -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId
Sounds good to me. +1
Am 30.01.2017 um 17:31 schrieb Steve Ebersole:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best time if we wanted to do that.
>
> So we know we will change the groupId to `org.hibernate.orm`.
>
> I was thinking we might want to also either:
>
> 1. rename `hibernate-core` as `hibernate-orm`
> 2. rename all the artifacts following the pattern `hibernate-orm-${1}`,
> e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc.
>
>
> On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole wrote:
>
>> Well let's investigate what this consistency means across projects first.
>> As Sanne mentions, if it makes it building ORM more difficult then I'd be
>> -1 it too. But I promise to take a peek when I get back from PTO in a few
>> days. Or maybe Andrea can in the next few days as he already has worked on
>> the changes to release relocation artifacts for ORM; I just do not know
>> when he is coming back from PTO. Either way we will have looked at it for
>> ORM by the end of week.
>>
>> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet
>> wrote:
>>
>> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero
>> wrote:
>>
>>> Different projects have different needs. Consistency is nice, and
>>> certainly makes it easier to find oneself comfortably "at home" when
>>> jumping from one project to another, but it also is inconvenient to do
>>> things "for consistency" when one has different requirements.
>>>
>> I don't think we would have different requirements regarding the relocation
>> artifacts.
>>
>> But if you see any issue with the approach we chose for HV, interesting in
>> hearing them so that we can have the same approach for the different NoORM
>> project.
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
