As far as I understood, only stable plugins are used, which are provided for
a bunch of other projects. Each of these projects is dependent on the
accuracy of these plugins, so the probability that an error (if introduced)
is found very quickly is extremely high. If a smaller group is maintaining
and using the repository, not only the effort for maintenance is higher,
also the probability of finding introduced errors is way smaller (not
talking about licensing issues).
Before having this, I would prefer to have a weekly auto build with
integrated unit tests, performance tests, result storage and report
generation like Eclipse does it. In that case it is possible to monitor
stability and the development progress at least in terms of functionality
and performance. The effort for that shouldn't be too high (one time effort)
and might be worth it. Well, just a thought.
-- Mirko
On 1/16/07, Adam Lally [EMAIL PROTECTED] wrote:
On 1/16/07, Marshall Schor [EMAIL PROTECTED] wrote:
In our Maven use, many times (for a new installation) Maven will fetch
Jars from a central Maven repository.
When running builds, Maven will query the central Maven repository to
see if more recent versions of a Jar are available, and if found, will
download them.
My understanding is that this is not quite true. We say what version
we want in our POM. For example for the Eclipse jars we can specify
either v3.1 or v3.2 (the repository that we use contains both) and
will get that version. Now, I suppose it is possible that someone may
*replace* the v3.1 jars in the repository with different ones (without
incrementing the version number), so in that sense our build would not
be repeatable. We have to rely on proper management of the
repository.
This page
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
suggests it may be possible to set up additional Maven repositories and
have them searched for things, ahead of the regular sites.
That page is about plugin snapshot repositories, which is something
complely different than repositories of dependent jar files. This is
a repository for Maven plugins, and is their snapshot versions, not
official released ones. We don't use snapshot plugins.
If so, I think we should do the following:
1) Create a repository (on Apache, if licensing permits) for anything
where we want more control over the updates.
2) Create a repository (probably not on Apache, for licensing reasons?)
where the Eclipse plugin jars with their sources and/or javaDocs can be
found.
3) Change our Maven profiles to use these ahead of other common Maven
repositories.
Do other projects using Maven do this?
You may want to check out the repository@apache.org mailing list.
Back when I was trying to figure out what to do about our Eclipse
dependencies, I asked some questions there. The answers I got
indicated that their preference was for someone else (ideally the
Eclipse developers themselves) to post their artifacts to ibiblio (the
maven central repo) as they released new versions. (The Eclipse
project seemed uninterested in doing so, however, so the job fell on
someone who had an itch to scratch.) Also, Apache maintains a mirror
of ibiblio, which leads me to believe that lots of Apache projects use
it.
-Adam
