You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jarret R <ja...@gmail.com> on 2007/01/31 03:11:55 UTC
Managing Dependent Jars
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Wayne Fay <wa...@gmail.com>.
I'm still on Oracle App Server v10.1.2 which means J2EE 1.3 on more
than one project, so don't complain too loudly... ;-)
OAS v10.1.3 is out but our Production Support team isn't fully trained
etc on it and won't move us to it yet.
Wayne
On 2/1/07, Lasse Koskela <la...@gmail.com> wrote:
> On 1/31/07, Wayne Fay <wa...@gmail.com> wrote:
> > 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.
>
> Anyone except all of those thousands of poor corporate developers who
> just this week celebrated a successful upgrade of their standard
> technology stack from WebLogic 6.1 to 7.0 and Java 1.3 to Java 1.4...
>
> Lasse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Lasse Koskela <la...@gmail.com>.
On 1/31/07, Wayne Fay <wa...@gmail.com> wrote:
> 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.
Anyone except all of those thousands of poor corporate developers who
just this week celebrated a successful upgrade of their standard
technology stack from WebLogic 6.1 to 7.0 and Java 1.3 to Java 1.4...
Lasse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Eric Redmond <er...@gmail.com>.
True, I should have mentioned that as well. Definitely file bugs with the
artifact owners... my suggestion should just be considered an interim fix.
Think of it as a project deploying with a faulty rpm or msi installer... the
onus is on the owner to fix, not the mirror that hosts it.
Thanks;
Eric
On 1/30/07, Wayne Fay <wa...@gmail.com> wrote:
>
> As for the comment regarding Hibernate, this is again not the Maven
> team's fault, but rather entirely Hibernate's fault.
>
> It is entirely the responsibility of the artifact owner to produce
> proper poms. If they fail to do so, the users of those artifacts will
> suffer (as you've experienced). The proper response to these troubles
> is not to complain loudly about how much Maven sucks etc but rather to
> file bugs with the various parties and do your part to help update the
> incorrect pom files for the benefit of everyone.
>
> Don't place the blame for these issues on the wrong party... When
> Maven works as intended with proper artifacts and poms etc, it is
> truly a great thing.
>
> Wayne
>
> On 1/30/07, Wayne Fay <wa...@gmail.com> wrote:
> > 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 <ja...@gmail.com> 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 <er...@gmail.com> 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 <ja...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Eric Redmond
> > > > http://codehaus.org/~eredmond
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: Managing Dependent Jars
Posted by Wayne Fay <wa...@gmail.com>.
As for the comment regarding Hibernate, this is again not the Maven
team's fault, but rather entirely Hibernate's fault.
It is entirely the responsibility of the artifact owner to produce
proper poms. If they fail to do so, the users of those artifacts will
suffer (as you've experienced). The proper response to these troubles
is not to complain loudly about how much Maven sucks etc but rather to
file bugs with the various parties and do your part to help update the
incorrect pom files for the benefit of everyone.
Don't place the blame for these issues on the wrong party... When
Maven works as intended with proper artifacts and poms etc, it is
truly a great thing.
Wayne
On 1/30/07, Wayne Fay <wa...@gmail.com> wrote:
> 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 <ja...@gmail.com> 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 <er...@gmail.com> 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 <ja...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Eric Redmond
> > > http://codehaus.org/~eredmond
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Wayne Fay <wa...@gmail.com>.
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 <ja...@gmail.com> 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 <er...@gmail.com> 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 <ja...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Eric Redmond
> > http://codehaus.org/~eredmond
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Jarret R <ja...@gmail.com>.
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 <er...@gmail.com> 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 <ja...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Dependent Jars
Posted by Eric Redmond <er...@gmail.com>.
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 <ja...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond