Henning P. Schmiedehausen wrote:
This is very easy to handle. In our project.properties files, we have for example:Russell Gold <[EMAIL PROTECTED]> 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.
# 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
