Well, I originally had them all in one groupId but it was suggested that they be split to distinguish core functionality from the extra stuff. That did and still does make sense to me, although using the groupId may not be the best way to distinguish it. It might be done simply through a better web site design. We have had a couple of users now include all the jars in their project. The different groupIds hasn't stopped that. To be honest, I'm not really sure what would.
I have no problem switching back to a single groupId if that is the consensus, but we really need to lock that down as we can't be doing that after 2.0 GA is released. Ralph On Apr 10, 2013, at 6:21 AM, Gary Gregory wrote: > Hi All: > > I find it confusing to have >1 group Id, for example in Ivy, when I tried > > <dependency org="org.apache.logging.log4j" name="log4j-api" > rev="2.0-beta4" /> > <dependency org="org.apache.logging.log4j" name="log4j-core" > rev="2.0-beta4" /> > <dependency org="org.apache.logging.log4j" name="log4j-1.2-api" > rev="2.0-beta4" /> > > it bombed because the 1.2 API is in "org.apache.logging.log4j.adapter" not > "org.apache.logging.log4j" > > What is the point of this complication? It's bad enough we have a bunch of > jars, but multiple group ids? > > Gary > > -- > E-Mail: [email protected] | [email protected] > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
