4:37 p.m.
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet(a)gmail.com>
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
5:36 p.m.
New subject: 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 <guillaume.smet(a)gmail.com>
wrote:
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere
<yrodiere(a)redhat.com>
wrote:
>
> On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet(a)gmail.com>
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:57 p.m.
New subject: Hibernate Commons project
On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole <steve(a)hibernate.org> 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
11:34 a.m.
New subject: Hibernate Commons project
Hi,
Some thoughts:
== Group Id ==
Should be something like "org.hibernate.common" as per our discussions
from last week.
== Repo organization ==
I would prefer to have the AsciiDoc style, shared testing utilities
and other utilities in separate repos, not a shared one. To me, a repo
represents a coherent unit of "things" with its own lifecycle. Updates
to the style should not mandate an update of the version of the
testing and other utilities, so they should be in their own repo. This
should also make it easier in terms of licenses (no need for
relicensing).
== Unified Appearance ==
Now that's one field where we really should strive for consistency:
the different projects of the Hibernate umbrella should have one
shared doc style for the sake of unified and professional experience.
That's much more important than aligning on build profile names and
the like.
I don't have a strong opinion on which style it should be; the only
thing I really dislike about the current ORM one is that there is no
TOC on the side as we have it for HV. That makes it very impractical
to navigate.
--Gunnar
2017-01-30 20:57 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com>:
On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole
<steve(a)hibernate.org> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:27 p.m.
New subject: Hibernate Commons project
On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
== Repo organization ==
I would prefer to have the AsciiDoc style, shared testing utilities
and other utilities in separate repos, not a shared one. To me, a repo
represents a coherent unit of "things" with its own lifecycle. Updates
to the style should not mandate an update of the version of the
testing and other utilities, so they should be in their own repo. This
should also make it easier in terms of licenses (no need for
relicensing).
Yeah, that was my first intention but I got outnumbered and to be honest I
don't really care as long as they are purely internal projects. I'll let
Yoann and Sanne explain their point of view as they will do that better
than me (IIRC, it was mostly about the maintenance cost but I'm not sure it
makes a difference if the lifecycles are completely different).
Anyway, it does not solve the license issue. As per our discussion last
week, if we have some general utilities to share between the NoORM projects
for instance, we would probably like to copy the sources of the utilities
to avoid conflicting dependencies when depending on 2 of the projects
(probably using
https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-d...).
In this case, I think we would need to dual license (ASL 2 + LGPL) the
utilities as the sources will be distributed with the rest of the projects.
So, if I try to sum it up:
== GroupId ==
2 proposals:
- org.hibernate.common (the same as hibernate-commons-annotations)
- org.hibernate.internal
(let's drop my initial org.hibernate.commons proposal, it's too confusing
with org.hibernate.common)
== The license ==
The license: probably better to dual license everything under the ASL2 and
the LGPL - especially if we start to share utilities.
Will check with Emmanuel when he's back.
== The AsciiDoctor theme ==
We mostly agree that it's probably better to converge on a similar layout.
Steve seems to be strongly attached to the Hibernate theme.
I personally don't like it and think it would be more painful to maintain
in the long term as it overrides more things. Sanne was also more convinced
by the white banner.
If I sum up the differences between the 2 themes (
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
vs http://docs.jboss.org/hibernate/beta/html_single/):
- black banner vs white banner
- original Docbook icons vs font based icons (Font Awesome)
- dark blue titles vs standard red ones
- admonitions are totally different (compare
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
and the end of this paragraph
http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-th...
)
- a lots of fonts loaded in the ORM doc but I must admit that I think most
are useless:
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
so we could probably clean this up
- more overrides (compare
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so
more maintenance if the HTML output of AsciiDoctor is changed - note that
I'm new to AsciiDoctor so I don't know how stable the HTML output is
The ORM output might have been better than the default AsciiDoctor output
at the time it was made, but as of now I really think the current
AsciiDoctor output is more pleasant to read and more modern. And we would
benefit from future improvements for free.
--
Guillaume
4:21 p.m.
New subject: Hibernate Commons project
Hey all,
On the license, I think ASL 2.0 is the best for such project.
On the group id, am I right that this project is some utilities used by us internally? And
would not be imported by a user?
If true then I’d avoid common as it feels like something that a user would import.
internal could work. Some other proposal (to be combined or not):
- utilities
- infra
- toolbox
On the theme, I don't have a definitive opinion but I think like Guillaume I’d prefer
a lighter customized version of the default Asciidoc theme rather than the heavyweight
one.
Emmanuel
On 31 Jan 2017, at 12:27, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> == Repo organization ==
>
> I would prefer to have the AsciiDoc style, shared testing utilities
> and other utilities in separate repos, not a shared one. To me, a repo
> represents a coherent unit of "things" with its own lifecycle. Updates
> to the style should not mandate an update of the version of the
> testing and other utilities, so they should be in their own repo. This
> should also make it easier in terms of licenses (no need for
> relicensing).
>
Yeah, that was my first intention but I got outnumbered and to be honest I
don't really care as long as they are purely internal projects. I'll let
Yoann and Sanne explain their point of view as they will do that better
than me (IIRC, it was mostly about the maintenance cost but I'm not sure it
makes a difference if the lifecycles are completely different).
Anyway, it does not solve the license issue. As per our discussion last
week, if we have some general utilities to share between the NoORM projects
for instance, we would probably like to copy the sources of the utilities
to avoid conflicting dependencies when depending on 2 of the projects
(probably using
https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-d...).
In this case, I think we would need to dual license (ASL 2 + LGPL) the
utilities as the sources will be distributed with the rest of the projects.
So, if I try to sum it up:
== GroupId ==
2 proposals:
- org.hibernate.common (the same as hibernate-commons-annotations)
- org.hibernate.internal
(let's drop my initial org.hibernate.commons proposal, it's too confusing
with org.hibernate.common)
== The license ==
The license: probably better to dual license everything under the ASL2 and
the LGPL - especially if we start to share utilities.
Will check with Emmanuel when he's back.
== The AsciiDoctor theme ==
We mostly agree that it's probably better to converge on a similar layout.
Steve seems to be strongly attached to the Hibernate theme.
I personally don't like it and think it would be more painful to maintain
in the long term as it overrides more things. Sanne was also more convinced
by the white banner.
If I sum up the differences between the 2 themes (
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
vs http://docs.jboss.org/hibernate/beta/html_single/):
- black banner vs white banner
- original Docbook icons vs font based icons (Font Awesome)
- dark blue titles vs standard red ones
- admonitions are totally different (compare
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
and the end of this paragraph
http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-th...
)
- a lots of fonts loaded in the ORM doc but I must admit that I think most
are useless:
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
so we could probably clean this up
- more overrides (compare
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so
more maintenance if the HTML output of AsciiDoctor is changed - note that
I'm new to AsciiDoctor so I don't know how stable the HTML output is
The ORM output might have been better than the default AsciiDoctor output
at the time it was made, but as of now I really think the current
AsciiDoctor output is more pleasant to read and more modern. And we would
benefit from future improvements for free.
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:34 p.m.
New subject: Hibernate Commons project
On 6 February 2017 at 15:21, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Hey all,
On the license, I think ASL 2.0 is the best for such project.
On the group id, am I right that this project is some utilities used by us internally?
And would not be imported by a user?
That's what I hope should be the intent as well. This repo would be
useful to e.g. not rebuild the same checkstyle extensions over and
over, but I'd not like to share actual runtime code from this project.
Project inter-dependency matrix is complex enough for end-users.
Thanks,
Sanne
If true then I’d avoid common as it feels like something that a user would import.
internal could work. Some other proposal (to be combined or not):
- utilities
- infra
- toolbox
On the theme, I don't have a definitive opinion but I think like Guillaume I’d prefer
a lighter customized version of the default Asciidoc theme rather than the heavyweight
one.
Emmanuel
> On 31 Jan 2017, at 12:27, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
>
> On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>
>> == Repo organization ==
>>
>> I would prefer to have the AsciiDoc style, shared testing utilities
>> and other utilities in separate repos, not a shared one. To me, a repo
>> represents a coherent unit of "things" with its own lifecycle. Updates
>> to the style should not mandate an update of the version of the
>> testing and other utilities, so they should be in their own repo. This
>> should also make it easier in terms of licenses (no need for
>> relicensing).
>>
>
> Yeah, that was my first intention but I got outnumbered and to be honest I
> don't really care as long as they are purely internal projects. I'll let
> Yoann and Sanne explain their point of view as they will do that better
> than me (IIRC, it was mostly about the maintenance cost but I'm not sure it
> makes a difference if the lifecycles are completely different).
>
> Anyway, it does not solve the license issue. As per our discussion last
> week, if we have some general utilities to share between the NoORM projects
> for instance, we would probably like to copy the sources of the utilities
> to avoid conflicting dependencies when depending on 2 of the projects
> (probably using
>
https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-d...).
> In this case, I think we would need to dual license (ASL 2 + LGPL) the
> utilities as the sources will be distributed with the rest of the projects.
>
> So, if I try to sum it up:
>
> == GroupId ==
>
> 2 proposals:
> - org.hibernate.common (the same as hibernate-commons-annotations)
> - org.hibernate.internal
>
> (let's drop my initial org.hibernate.commons proposal, it's too confusing
> with org.hibernate.common)
>
> == The license ==
>
> The license: probably better to dual license everything under the ASL2 and
> the LGPL - especially if we start to share utilities.
>
> Will check with Emmanuel when he's back.
>
> == The AsciiDoctor theme ==
>
> We mostly agree that it's probably better to converge on a similar layout.
>
> Steve seems to be strongly attached to the Hibernate theme.
>
> I personally don't like it and think it would be more painful to maintain
> in the long term as it overrides more things. Sanne was also more convinced
> by the white banner.
>
> If I sum up the differences between the 2 themes (
>
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
> vs http://docs.jboss.org/hibernate/beta/html_single/):
> - black banner vs white banner
> - original Docbook icons vs font based icons (Font Awesome)
> - dark blue titles vs standard red ones
> - admonitions are totally different (compare
>
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernat...
> and the end of this paragraph
>
http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-th...
> )
> - a lots of fonts loaded in the ORM doc but I must admit that I think most
> are useless:
>
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
> so we could probably clean this up
> - more overrides (compare
>
http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibe...
> vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so
> more maintenance if the HTML output of AsciiDoctor is changed - note that
> I'm new to AsciiDoctor so I don't know how stable the HTML output is
>
> The ORM output might have been better than the default AsciiDoctor output
> at the time it was made, but as of now I really think the current
> AsciiDoctor output is more pleasant to read and more modern. And we would
> benefit from future improvements for free.
>
> --
> Guillaume
> _______________________________________________
> 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
12:03 p.m.
New subject: Hibernate Commons project
Hi,
On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
On the license, I think ASL 2.0 is the best for such project.
As we discussed it in Lisbon, we might "copy" (using Maven) sources from an
internal utility project to the NoORM projects, as we want to avoid
dependency hell with different versions of the utilities. In this case,
they might be included in the source jar. Thus, I think the best is to dual
license everything from the start.
I'll go do that.
On the group id, am I right that this project is some utilities used
by us
internally? And would not be imported by a user?
If true then I’d avoid common as it feels like something that a user would
import. internal could work. Some other proposal (to be combined or not):
- utilities
- infra
- toolbox
OK, if internal works for you, let's settle on it. It's widely used in the
Java world to name internal packages. It makes perfect sense here.
On the theme, I don't have a definitive opinion but I think like
Guillaume
I’d prefer a lighter customized version of the default Asciidoc theme
rather than the heavyweight one.
OK, let's start with this to unblock the situation with OGM and Search. ORM
can still use part of the theme (the PDF goodies) and keep their CSS if
they prefer. And once they moved to use part of it, we can revisit and
adjust so that everyone is happy. It's not as if the changes were breaking
changes for the users, it won't be an issue to adjust one way or the other.
--
Guillaume
8:07 p.m.
New subject: Hibernate Commons project
Hi,
So, apparently, people didn't like internal in the groupId so we ended up
with org.hibernate.infra which was one of the groupIds suggested by
Emmanuel.
The Asciidoctor theme is here:
https://github.com/hibernate/hibernate-asciidoctor-theme .
I just pushed the first version to our Nexus so I will start pushing the PR
to all the NoORM projects.
--
Guillaume
On Tue, Feb 7, 2017 at 12:03 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi,
On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
> On the license, I think ASL 2.0 is the best for such project.
>
As we discussed it in Lisbon, we might "copy" (using Maven) sources from
an internal utility project to the NoORM projects, as we want to avoid
dependency hell with different versions of the utilities. In this case,
they might be included in the source jar. Thus, I think the best is to dual
license everything from the start.
I'll go do that.
> On the group id, am I right that this project is some utilities used by
> us internally? And would not be imported by a user?
>
> If true then I’d avoid common as it feels like something that a user
> would import. internal could work. Some other proposal (to be combined or
> not):
> - utilities
> - infra
> - toolbox
>
OK, if internal works for you, let's settle on it. It's widely used in the
Java world to name internal packages. It makes perfect sense here.
> On the theme, I don't have a definitive opinion but I think like
> Guillaume I’d prefer a lighter customized version of the default Asciidoc
> theme rather than the heavyweight one.
>
OK, let's start with this to unblock the situation with OGM and Search.
ORM can still use part of the theme (the PDF goodies) and keep their CSS if
they prefer. And once they moved to use part of it, we can revisit and
adjust so that everyone is happy. It's not as if the changes were breaking
changes for the users, it won't be an issue to adjust one way or the other.
--
Guillaume
11:01 a.m.
New subject: Hibernate Commons project
On 7 Feb 2017, at 12:03, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
Hi,
On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard <emmanuel(a)hibernate.org
<mailto:emmanuel@hibernate.org>> wrote:
On the license, I think ASL 2.0 is the best for such project.
As we discussed it in Lisbon, we might "copy" (using Maven) sources from an
internal utility project to the NoORM projects, as we want to avoid dependency hell with
different versions of the utilities. In this case, they might be included in the source
jar. Thus, I think the best is to dual license everything from the start.
I'll go do that.
For your info, having ASL licensed files side by side LGPL code is fine. Just make sure
that each ASL file retains their copyright and license headers. The Apache Software
Foundation has stricter rules for its projects consuming other licenses than what the
license text says. But dual licensing works.
2626
days inactive
2635
days old
9 comments
5 participants
participants (5)
-
Emmanuel Bernard -
Guillaume Smet -
Gunnar Morling -
Sanne Grinovero -
Steve Ebersole