The problem with Spring being in multiple places etc is really not the Maven team's fault, but rather the Spring group's responsibility. Without looking too hard into the details, I'd guess they initially picked groupId spring, then springframework, then org.spring, and finally org.springframework for their groupIds. However, Maven has a strict "once published, never changed" policy for artifacts etc so they couldn't just consolidate all those old artifacts (under the old groupIds) into the latest Spring groupId. Hopefully, going forward, the Spring group (and other similar groups) will decide on one single groupId (per group/product) to reduce confusion in the community.
Look for the most recent version of Spring in the various places you mentioned -- in all likelihood, only one of those groupIds will have the latest builds, and they have probably finally decided to use that groupId rather than the others. This is really not much of a problem once you start using Maven2 and standardize on particular versions of various artifacts. I doubt anyone will need to use Spring 1.2.1 for example when 2.0 is available, so you won't need to ever access those older /spring etc artifacts. Wayne On 1/30/07, Jarret R <[EMAIL PROTECTED]> wrote:
Thanks for the reply. I am currently just testing this process out locally to build a case to use Maven, so I haven't set everything up yet, but I will take a look at the proxies. I took a look at the main repository and it seems to have some of the same issues I had mentioned earlier. I understand the requirement to hand build some POMs, but I'm still seeing Spring in three or four different places. Is there a standard version to use? I do somewhat disagree with the statement that this would be harder with ANT. In ANT, I can just drop the dependencies into my lib/ folder and they are picked up. Tracking them down is usually not an issue since most major projects come with their own dependencies. Converting the 20+ libs references in Hibernate requires me to look up each one in the Maven repository to get the correct references and I might have to add those if they don't exist yet. All in all, it seems much more painful than a standard ANT set up, at least in this respect. I do still think that a Mavenized build has a lot to recommend even if some of the dependencies need to be massaged :). Thanks, Jarret On 1/30/07, Eric Redmond <[EMAIL PROTECTED]> wrote: > The official repository location is http://repo1.maven.org/maven2/ ... check > out the hibernate data there (upgrade to at least maven 2.0.4). > > Also: you must set up an in-house repository[1]. This is not really optional > for an enterprise setup... where else can you put your own generated > artifacts for all to use? If you find discrepencies in public repository > setups, having your own repository is the best way to control that (in which > case, yes, you may have to put a hand-written pom w/ real dependencies in > there). It's also necessary when you require the ability to share a > closed-source or licensed artifact through-out the org. Luckly the cases of > this in practice are kind of rare. Once your repo is up, you won't have to > touch it too often. Plus, think of Ant... you have to manually grab the > dependencies for those - so it's not like you're doing MORE work. > > A good proxy (about 8 months old) is Proximity[2]. If you want something > sanctified by the Maven team, check out Archiva[3][4] (still in development, > but usable). > > [1] http://www.devx.com/Java/Article/32386 > [2] http://proximity.abstracthorizon.org/ > [3] http://maven.apache.org/archiva/ > [4] http://coderoshi.blogspot.com/2006/12/apache-archiva-part-one.html > > Eric > > On 1/30/07, Jarret R <[EMAIL PROTECTED]> wrote: > > > > I have been trying to make a case for our development environment to > > switch to using Maven for our build processes, however I am running > > into some problems that I would like to see if anyone has answers too > > :). > > > > We want to be able to specify which version of which jar we want to > > use. I can solve this by creating a maven proxy and an internal maven > > repository, but this leads to my main problem. > > > > Maven repositories are not consistent. > > > > If I look at http://mirrors.ibiblio.org/pub/mirrors/maven2/, I can see > > that under hibernate/hibernate the newest version listed is 3.1rc. > > However this entry is invalid as it does not contain the dependencies. > > This resource [http://mvnrepository.com/artifact/org.hibernate/hibernate] > > specifies that 3.2.1ga is available. This is not obvious from looking > > at Ibiblio, but when I put this entry into my pom, it almost downloads > > (fails on a JTA dependency). What is the best way to determine what > > jars are available in the repository? > > > > The core issue is that this inconsistency is unacceptable for our > > process. I need to be able to pick any version of a library (including > > the newest) and have it 'just work'. How are others handling this? Are > > you all writing your own poms for internal repositories? This seems > > tedious since Hibernate can have 20+ dependencies that have to be hand > > coded into the pom file. This problem also occurs for PostgreSQL since > > the latest Maven definition I could find was for 7.x and we are on > > 8.1. > > > > Another example is the Spring Framework. As far as I can tell, Spring is > > in: > > > > spring/ > > springframework/ > > org/spring > > org.springframework/ > > > > and so on. Each of these directories contain different collections of > > the spring jars. Why are there so many? What is the right one? > > > > Can anyone shed some light on how to manage Maven in a corporate > > environment where I need to be able to specify any version of any jar? > > > > > > Thanks, > > Jarret Raim > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Eric Redmond > http://codehaus.org/~eredmond > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
