You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Frey, John (MED)" <Jo...@med.ge.com> on 2003/02/18 01:10:11 UTC
using a central repository other than ibiblio ?
Can anyone tell me how to configure maven to use a central repository
other than the default repository at ibiblio? In beta-7 this was
accomplished by overriding several properties found in
"$MAVEN_HOME/bin/driver.properties"...
maven.repo.remote = http://www.ibiblio.org/maven
<http://www.ibiblio.org/maven>
maven.repo.central = login.ibiblio.org
maven.repo.central.directory = /public/html/maven
This still seems to work in beta-8 however the driver.properties file
has been removed from the distribution. Is this feature going to carry
forward into 1.0 release? This feature seems essential for closed source
organizations that share code.
GE Medical Systems
______________________________________________________
John E. Frey
Lead Software Developer, iCenter
Global Service Technology
Phone: (262) 896-2800 Fx: (262) 896-2790
email: John.Frey@med.ge.com
http://www.gemedicalsystems.com <http://www.gemedicalsystems.com/>
Re: using a central repository other than ibiblio ?
Posted by Pete Kazmier <pe...@kazmier.com>.
>>>>> Frey, John (MED) writes:
Frey> Can anyone tell me how to configure maven to use a central
Frey> repository other than the default repository at ibiblio? In
Frey> beta-7 this was accomplished by overriding several properties
Frey> found in "$MAVEN_HOME/bin/driver.properties"...
You should never have been modifying driver.properties. The
appropriate mechanism is to define the property in your
~/build.properties file or your project.properties file.
Thanks,
Pete
Re: using a central repository other than ibiblio ?
Posted by Stephen McConnell <mc...@apache.org>.
Rafal Krzewski wrote:
>Konstantin Priblouda wrote:
>
>
>In the future, there should be support for
>various deployment mechanisms including local filesystem, ftp,
>http (webdav), scp (the current method).
>
>We need to develop a mechanism for publishing artifacts without
>human interaction, but with strong security mechanism. An idea
>from the top of my head is delivering artifact + it's descriptor
>(including publishing organization's signature) with one of the
>aforementioned mechanisms to an 'incoming' directory. There would
>be a cron job running on the repository machine that would pick
>up incoming artifacts, verify the signatures using organizations'
>public keys stored in the repo and move artifacts into their proper
>place.
>
>
+1 - just what I've been thinking about.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Re: using a central repository other than ibiblio ?
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 18 Feb 2003 22:46, Jason van Zyl wrote:
> I actually have a Java-based ssh2, FTP and HTTP (using httpclient)
> deployers.
FTP would rock! :)
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
Re: using a central repository other than ibiblio ?
Posted by Colin Sampaleanu <co...@exis.com>.
Henning P. Schmiedehausen wrote:
>Russell Gold <ru...@httpunit.org> writes:
>
>>I suppose my biggest concern is in the lag in getting jars into the
>>repository. When I need to build using a new jar that is not at
>>iBiblio, I have to make other arrangements as a temporary measure - and
>>then tell my co-workers to do the same thing. if I could simply point
>>to the sourceforge project which is the ultimate host, I wouldn't need
>>to do that. And I could use the exact same mechanism for internal
>>projects. The distribution is available already, so why should I have
>>to take an extra step to argue for the inclusion of a new jar evertime
>>it is released - or even when a pre-release version is available?
>>
>>
>I have
>
>maven.repo.local=${user.home}/javalibs/intermeta
>maven.repo.remote=http://maven.intermeta.de
>
>in my ~/build.properties since ages. The whole ibiblio stuff is
>primary politics and ideology and I try to keep away from this as much
>as possible.
>
>Whenever I have to rebuild a jakarta project, I switch these lines to
>
>maven.repo.local=${user.home}/javalibs/ibiblio
>
>(note the missing maven.repo.remote line)
>
>and rebuild. Most of the time I have to hand-correct some dependencies
>(such as the missing sun jars).
>
>I very much prefer to be in charge of my build process and get
>reproduceable results. And we have about 25 jars in our repository
>which are not public or open-source.
>
>Maven gets crippled by hardcoding ideology like ibiblio.
>
This is very easy to handle. In our project.properties files, we have
for example:
# override remote repo since we want to also point to a cvs based remote
repo
# to get some jars not found at ibiblio
maven.repo.remote=http://www.ibiblio.com/maven,file:${basedir}/../../shared/repository
# override local repo since we want to allow this set of related source
projects
# to be built from multiple locations without conflicting
maven.repo.local=${basedir}/../mavenrepo
This means that jar files come down from ibiblio. They also come down
from a 'local' remote repository that is on the filesystem and is in
CVS. This is where we dump jars that are not on ibiblio. This could of
course also be another repo accessed by http. We also override the local
repo to another value, so we can have multiple checkouts (different
branches, experimentals, etc.) of the same project, and when jar:install
is used to put up a jar to the local repo for use by another project,
the two variants/branches can have the same version number and not
interfere with each other.
You can of course put something like the above in your
~/build.properties file, but I find it more flexible to do at the
project level.
There is still one issue with the above setup, in that there still
appears to be a bug (filed by me on Jira) with plugins pulling down jars
and using the overriden remote repo value. Plugin jars seem to always
come from ibiblio. This is annoying, but so far has not been an issue
for us since all the plugins we use have jars on ibiblio.
Colin
Re: using a central repository other than ibiblio ?
Posted by di...@multitask.com.au.
"Henning P. Schmiedehausen" <hp...@intermeta.de> wrote on 19/02/2003
04:17:47 AM:
>
> Maven gets crippled by hardcoding ideology like ibiblio.
>
Could you please explain this comment further please?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: using a central repository other than ibiblio ?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Russell Gold <ru...@httpunit.org> writes:
>I suppose my biggest concern is in the lag in getting jars into the
>repository. When I need to build using a new jar that is not at
>iBiblio, I have to make other arrangements as a temporary measure - and
>then tell my co-workers to do the same thing. if I could simply point
>to the sourceforge project which is the ultimate host, I wouldn't need
>to do that. And I could use the exact same mechanism for internal
>projects. The distribution is available already, so why should I have
>to take an extra step to argue for the inclusion of a new jar evertime
>it is released - or even when a pre-release version is available?
I have
maven.repo.local=${user.home}/javalibs/intermeta
maven.repo.remote=http://maven.intermeta.de
in my ~/build.properties since ages. The whole ibiblio stuff is
primary politics and ideology and I try to keep away from this as much
as possible.
Whenever I have to rebuild a jakarta project, I switch these lines to
maven.repo.local=${user.home}/javalibs/ibiblio
(note the missing maven.repo.remote line)
and rebuild. Most of the time I have to hand-correct some dependencies
(such as the missing sun jars).
I very much prefer to be in charge of my build process and get
reproduceable results. And we have about 25 jars in our repository
which are not public or open-source.
Maven gets crippled by hardcoding ideology like ibiblio.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
Re: using a central repository other than ibiblio ?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-02-18 at 09:05, Russell Gold wrote:
> On Tuesday, February 18, 2003, at 08:52 AM, Jason van Zyl wrote:
>
> > On Tue, 2003-02-18 at 08:38, Russell Gold wrote:
> >> 2) directly from the distribution sites to avoid the need to burden a
> >> central repository?
> >
> > There has been discussion of a PORTs like system, but I feel the
> > central
> > repository is not a burden at all and a good thing. Ibiblio is
> > sometimes
> > slow but reliable and many Maven users have commented on the
> > convenience
> > of single stop shopping at the central repository. We can certainly add
> > pointers but when things land at Ibiblio they are archived in
> > perpetuity. And one of their primary mandates is the proliferation of
> > OSS software.
>
> I suppose my biggest concern is in the lag in getting jars into the
> repository. When I need to build using a new jar that is not at
> iBiblio, I have to make other arrangements as a temporary measure - and
> then tell my co-workers to do the same thing.
It is not a trivial task but we are working toward general acceptance of
artifacts by projects into the repository.
You can always setup a remote repository of your own. If it's strictly
between your co-workers that would probably work out well. You can put
it anywhere. So when you build a new artifact put in your remote
repository and all your coworkers have to do is alter their
maven.repo.remote property. When it goes to Ibiblio nothing will change.
> if I could simply point
> to the sourceforge project which is the ultimate host, I wouldn't need
> to do that.
You can make your own repo, and make a project.properties entry that
states the use of that repo.
> And I could use the exact same mechanism for internal
> projects. The distribution is available already, so why should I have
> to take an extra step to argue for the inclusion of a new jar evertime
> it is released - or even when a pre-release version is available?
You don't have to. If you don't want to archive at Ibiblio you've got
the multiple remote repo option or the maven JAR override feature. Both
are now doco'd in the user guide.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: using a central repository other than ibiblio ?
Posted by Russell Gold <ru...@httpunit.org>.
On Tuesday, February 18, 2003, at 08:52 AM, Jason van Zyl wrote:
> On Tue, 2003-02-18 at 08:38, Russell Gold wrote:
>> 2) directly from the distribution sites to avoid the need to burden a
>> central repository?
>
> There has been discussion of a PORTs like system, but I feel the
> central
> repository is not a burden at all and a good thing. Ibiblio is
> sometimes
> slow but reliable and many Maven users have commented on the
> convenience
> of single stop shopping at the central repository. We can certainly add
> pointers but when things land at Ibiblio they are archived in
> perpetuity. And one of their primary mandates is the proliferation of
> OSS software.
I suppose my biggest concern is in the lag in getting jars into the
repository. When I need to build using a new jar that is not at
iBiblio, I have to make other arrangements as a temporary measure - and
then tell my co-workers to do the same thing. if I could simply point
to the sourceforge project which is the ultimate host, I wouldn't need
to do that. And I could use the exact same mechanism for internal
projects. The distribution is available already, so why should I have
to take an extra step to argue for the inclusion of a new jar evertime
it is released - or even when a pre-release version is available?
Re: using a central repository other than ibiblio ?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-02-18 at 08:38, Russell Gold wrote:
> On Tuesday, February 18, 2003, at 06:46 AM, Jason van Zyl wrote:
> > I actually have a Java-based ssh2, FTP and HTTP (using httpclient)
> > deployers. They got lost in the plugin shuffle done a couple weeks ago
> > but they will definitely go back in. I'm also working on deployment to
> > maven.org so that any project can deploy to the repository (not
> > directly, but the artifacts will make their way there).
>
> Wouldn't it make sense to make this work:
> 1) independently of Maven, so that it is available for other build
> systems (maybe an ant plugin)?
We only ever make beans. We don't have anything nasty like Tasks that
would bind any of our bean code to Maven. So you could take the very
small maven plugin JAR with the beans in them and make an Tasks if you
like.
> 2) directly from the distribution sites to avoid the need to burden a
> central repository?
There has been discussion of a PORTs like system, but I feel the central
repository is not a burden at all and a good thing. Ibiblio is sometimes
slow but reliable and many Maven users have commented on the convenience
of single stop shopping at the central repository. We can certainly add
pointers but when things land at Ibiblio they are archived in
perpetuity. And one of their primary mandates is the proliferation of
OSS software.
> Or is this completely out-of-scope and possibly a spec for a separate
> project?
There is some interest in the download/dependency code as well. These
builds can be split. Just convenience for us really and what keeps
people using Maven. The same as Ant has never gone to any great lengths
to separate out all their bean code which _is_ hard to given its bound
to a Task and the AntClassLoader, yada yada yada.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: using a central repository other than ibiblio ?
Posted by Russell Gold <ru...@httpunit.org>.
On Tuesday, February 18, 2003, at 06:46 AM, Jason van Zyl wrote:
> I actually have a Java-based ssh2, FTP and HTTP (using httpclient)
> deployers. They got lost in the plugin shuffle done a couple weeks ago
> but they will definitely go back in. I'm also working on deployment to
> maven.org so that any project can deploy to the repository (not
> directly, but the artifacts will make their way there).
Wouldn't it make sense to make this work:
1) independently of Maven, so that it is available for other build
systems (maybe an ant plugin)?
2) directly from the distribution sites to avoid the need to burden a
central repository?
Or is this completely out-of-scope and possibly a spec for a separate
project?
Re: using a central repository other than ibiblio ?
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-02-18 at 04:59, Rafal Krzewski wrote:
> Konstantin Priblouda wrote:
> > This will not help for certain plugins - like release
> > - its hardwired to ibiblio... at least for resolving
> > snapshots.
>
> This apparently needs fixing. There are more shortcomings to the
> deploy plugin though. In the future, there should be support for
> various deployment mechanisms including local filesystem, ftp,
> http (webdav), scp (the current method).
I actually have a Java-based ssh2, FTP and HTTP (using httpclient)
deployers. They got lost in the plugin shuffle done a couple weeks ago
but they will definitely go back in. I'm also working on deployment to
maven.org so that any project can deploy to the repository (not
directly, but the artifacts will make their way there).
> We need to develop a mechanism for publishing artifacts without
> human interaction, but with strong security mechanism. An idea
> from the top of my head is delivering artifact + it's descriptor
> (including publishing organization's signature) with one of the
> aforementioned mechanisms to an 'incoming' directory. There would
> be a cron job running on the repository machine that would pick
> up incoming artifacts, verify the signatures using organizations'
> public keys stored in the repo and move artifacts into their proper
> place.
Yup, all in the works. For some time actually.
>
> R.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: using a central repository other than ibiblio ?
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- Rafal Krzewski <Ra...@caltha.pl> wrote:
> Konstantin Priblouda wrote:
> > This will not help for certain plugins - like
> release
> > - its hardwired to ibiblio... at least for
> resolving
> > snapshots.
>
> This apparently needs fixing. There are more
> shortcomings to the
> deploy plugin though. In the future, there should be
> support for
> various deployment mechanisms including local
> filesystem, ftp,
> http (webdav), scp (the current method).
There is a lot of things in maven that need fixing :)
I'm forced to live off cvs now :)
> We need to develop a mechanism for publishing
> artifacts without
> human interaction, but with strong security
> mechanism. An idea
> from the top of my head is delivering artifact +
> it's descriptor
> (including publishing organization's signature) with
> one of the
> aforementioned mechanisms to an 'incoming'
> directory. There would
> be a cron job running on the repository machine that
> would pick
> up incoming artifacts, verify the signatures using
> organizations'
> public keys stored in the repo and move artifacts
> into their proper
> place.
Would be nice, because I'm in the same need -
we got distributed project, with a lot of artifacts
which can be used independetly and need top be
distributed and propagated somehow...
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
Re: using a central repository other than ibiblio ?
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Konstantin Priblouda wrote:
> This will not help for certain plugins - like release
> - its hardwired to ibiblio... at least for resolving
> snapshots.
This apparently needs fixing. There are more shortcomings to the
deploy plugin though. In the future, there should be support for
various deployment mechanisms including local filesystem, ftp,
http (webdav), scp (the current method).
We need to develop a mechanism for publishing artifacts without
human interaction, but with strong security mechanism. An idea
from the top of my head is delivering artifact + it's descriptor
(including publishing organization's signature) with one of the
aforementioned mechanisms to an 'incoming' directory. There would
be a cron job running on the repository machine that would pick
up incoming artifacts, verify the signatures using organizations'
public keys stored in the repo and move artifacts into their proper
place.
R.
Re: using a central repository other than ibiblio ?
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- Philip Crotwell <cr...@seis.sc.edu> wrote:
>
> You can set maven.repo.remote in each the
> build.properties file, and can
> have multiple entries separated by commas.
> For example:
>
maven.repo.remote=http://www.ibiblio.org/maven/,http://www.geotools.org/gt2modul
> es/extbin
This will not help for certain plugins - like release
- its hardwired to ibiblio... at least for resolving
snapshots.
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
Re: using a central repository other than ibiblio ?
Posted by Philip Crotwell <cr...@seis.sc.edu>.
You can set maven.repo.remote in each the build.properties file, and can
have multiple entries separated by commas.
For example:
maven.repo.remote=http://www.ibiblio.org/maven/,http://www.geotools.org/gt2modul
es/extbin
Philip
On Mon, 17 Feb 2003, Frey, John (MED) wrote:
> Can anyone tell me how to configure maven to use a central repository
> other than the default repository at ibiblio? In beta-7 this was
> accomplished by overriding several properties found in
> "$MAVEN_HOME/bin/driver.properties"...
>
> maven.repo.remote = http://www.ibiblio.org/maven
> <http://www.ibiblio.org/maven>
> maven.repo.central = login.ibiblio.org
> maven.repo.central.directory = /public/html/maven
>
> This still seems to work in beta-8 however the driver.properties file
> has been removed from the distribution. Is this feature going to carry
> forward into 1.0 release? This feature seems essential for closed source
> organizations that share code.
>
> GE Medical Systems
> ______________________________________________________
> John E. Frey
> Lead Software Developer, iCenter
> Global Service Technology
> Phone: (262) 896-2800 Fx: (262) 896-2790
> email: John.Frey@med.ge.com
> http://www.gemedicalsystems.com <http://www.gemedicalsystems.com/>
>
>
>