Re: [hibernate-dev] groupId vs artifactId

2011-03-11 Thread Emmanuel Bernard
Everybody thinks it's a good idea so I went for it. welcome org.hibernate,ogm @Sanne, you mean modules for OGM? At least one per NoSQL. On 11 mars 2011, at 20:52, Sanne Grinovero wrote: > +1 on the approach, > > do you already have plans of many modules? > > 2011/3/11 Emmanuel Bernard : >> Tod

Re: [hibernate-dev] groupId vs artifactId

2011-03-11 Thread Sanne Grinovero
+1 on the approach, do you already have plans of many modules? 2011/3/11 Emmanuel Bernard : > Today we have the following approach for most of our projects > > groupId: org.hibernate > artifactId hibernate-search-parent, hibernate-search etc > > Since I'm working on the ogm packaging, I wonder if

Re: [hibernate-dev] groupId vs artifactId

2011-03-11 Thread Gunnar Morling
2011/3/11 Hardy Ferentschik The artifactId should stay, however, hibernate-ogm-core. Remember the > artifactId determines the name of the jar file. I prefer > hibernate-ogm-core over ogm-core.jar. > +1 for this approach. This style is also followed by the Seam modules, e.g.: org.jboss.seam.vali

Re: [hibernate-dev] groupId vs artifactId

2011-03-11 Thread Hardy Ferentschik
+1 If we would have started this earlier, we would have a much nicer namespace under https://repository.jboss.org/nexus/content/repositories/public/org/hibernate/ Obviously we cannot get rid of/change the existing structure by changing the groupIds of existing projects, because we have to ke

[hibernate-dev] groupId vs artifactId

2011-03-11 Thread Emmanuel Bernard
Today we have the following approach for most of our projects groupId: org.hibernate artifactId hibernate-search-parent, hibernate-search etc Since I'm working on the ogm packaging, I wonder if we should do something like groupId: org.hibernate.ogm artifactId hibernate-ogm-parent, hibernate-ogm-