Basically this comes down to whether we want to continue to provide an uber- jar of all Hibernate classes. Currently we do this for the release bundles as hibernate3.jar Do we want to continue this practice into 4.x?  If we are going to do it, then I think we should be consistent and also provide the same through the Maven repository.  So to me either: 1) Provide option for uber-jar both in release bundles and in JBoss Maven repository (as separate artifactId) 2) Completely stop providing the uber-jar option. Have also been thinking about whether it makes sense to provide "guidance" on different base setups.  This is mostly unrelated to the discussion above, but there is a bearing.  Mostly people want the uber-jar because they find it easier then naming 3 jars to get hibernate+c3p0 up and running (for example). But if we had a way for them to do this easier maybe it lessens the need for the uber-jar even more.  Initially for "guidance" I was thinking ivy configurations since I think ivy is available pretty ubiquitously (can't you even use ivy from maven?); plus the fact that you can name custom configurations and mix them together make it much more flexible and simultaneously much less verbose than poms for this purpose.   So in their projects, instead of depending on "hibernate" they could depend on the ivy configuration "hiberate+c3p0". -- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Sunday, October 10, 2010 01:25:38 pm Paul Benedict wrote: > I think uber jars are never a good idea. You get everything and > developers don't care to find out what features they want or don't > want. Personally I agree 100% there. Maybe even 10000000000% ;) > As for Maven, have you considered profiles? If developers could > activate them, there would be pre-built dependencies (like for c3p0). > I find this better than Ivy. Well couple of things there. First, these would need to be profiles in their poms. AFAIK you cannot "invoke" profiles in poms of dependencies. This however is completely possible in Ivy, which is why I stated I thought it would be the more flexible way to go. Also, Hibernate 4 will not be built with Maven. I am taking the opportunity to also move to Gradle which I have wanted to do for quite some time. Of course if you say there is a way to do what I said above I thought was not possible with Maven and "show me the light" we could make the generated poms reflect these profiles. As far as I know, the only way to do what you suggest with Maven would be for us to develop an archetype. The problem with these imho is that you rarely are developing a "hibernate application"; more usually you are developing a "web application", within which you are using hibernate. So you need to decide up front which archetype you want to use. Its just very inflexible.

Hello, > As far as I know, the only way to do what you suggest with Maven would be > for us to develop an archetype. The problem with these imho is that you > rarely are developing a "hibernate application"; more usually you are > developing a "web application", within which you are using hibernate. > So you need to decide up front which archetype you want to use. Its > just very inflexible. What about a maven artifact (afaik gardle and ivy also use maven repositories for dependencies), which only contains dependencies to other hibernate modules (the ones that are before went into the uber-jar and are not transitive deps of the hibernate core artifact)?

People loving uber-jars are (in my experience) those who don't have an automated dependency management system, so having special maven artifacts won't help them. It could be useful to document what modules are needed for each use case by providing short descriptions for each jar. Sanne

People loving uber-jars are (in my experience) those who don't have an automated dependency management system, so having special maven artifacts won't help them. It could be useful to document what modules are needed for each use case by providing short descriptions for each jar. Sanne 2010/10/11 Steve Ebersole <steve(a)hibernate.org&gt;: > That would work sure. But each combination would require an artifact in > this scheme. And that's a lot of combinations. > > On Sunday, October 10, 2010 03:29:03 pm Adam Warski wrote: >> Hello, >> >> > As far as I know, the only way to do what you suggest with Maven would >> > be for us to develop an archetype. The problem with these imho is >> > that you rarely are developing a "hibernate application"; more >> > usually you are developing a "web application", within which you are >> > using hibernate. So you need to decide up front which archetype you >> > want to use. Its just very inflexible. >> >> What about a maven artifact (afaik gardle and ivy also use maven >> repositories for dependencies), which only contains dependencies to >> other hibernate modules (the ones that are before went into the >> uber-jar and are not transitive deps of the hibernate core artifact)? > > -- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev