Internal (company) repository layout best practices

[Borut Bolčina <bo...@gmail.com>]

Hello,

can you state pros and cons for your company's maven internal repository
layout. Why (for example) have "internal-snapshots" and "internal" repos.

Which remote repos besides http://repo1.maven.org/maven2 and
http://people.apache.org/repo/m2-snapshot-repository? Any better ones? How
to keep company repo "hygienic"?

Regards,
Borut

Re: Internal (company) repository layout best practices

[aldana <al...@gmx.de>]

we are not splitting repositories for releases and snapshots. in our case we
are modularizing our "bigger" application to single maven artifacts, so when
developing for a new release, changes (fixes, features) are often added
often to more than one project. as soon there is a change we switch from
release mode to snapshot mode for the new release.

i think the main reason to split repositories is if you have got public
libraries which external organisations/companies are using. i think in that
case it is senseful to have a strict isolated view.

but if you're developing for a new release and if you've got many modules,
which are "forming one bigger" application i would not split repositories,
because in that situation i do not want to have a separated snapshot vs.
release view.

the first post mentioned hygiene: i still look for a way to get an overview
of the dependencies of all my internal modules (release or snapshot
version). especially when working with lots of modules and still supporting
older releases in branches an overview of module-couplings could be
invaluable.
i know that in the standard report of a project you can see the
library-dependencies of one module. what i miss is the bigger pictures of
the dependencies between all modules you are working on during development.


-- 
View this message in context: http://www.nabble.com/Internal-%28company%29-repository-layout-best-practices-tf4645351s177.html#a13347335
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Internal (company) repository layout best practices

[Barrie Treloar <ba...@gmail.com>]

On 10/18/07, Borut Bolčina <bo...@gmail.com> wrote:
> Hello,
>
> can you state pros and cons for your company's maven internal repository
> layout. Why (for example) have "internal-snapshots" and "internal" repos.

It is best practice to separate releases from snapshots. In general
other people are only interested in the released versions, they are
not interested in snapshots unless they want to work on the bleeding
edge.  A side effect of including snapshots in your release repository
is that a snapshot is always considered newer than a release and
unless the pom specifies a specific version people will be using
(potentially unstable) snapshot versions.

See http://docs.codehaus.org/display/MAVENUSER/Using+Maven+in+a+corporate+environment
which I wrote up with the reasons for why I laid out Maven,
repositories etc in this way.

> Which remote repos besides http://repo1.maven.org/maven2 and
> http://people.apache.org/repo/m2-snapshot-repository? Any better ones? How
> to keep company repo "hygienic"?

Again see the above links.

I firmly believe that you should not include the maven snapshot
repositories in your build, unless you are a maven developer!

If you include the maven snapshot repositories then as described
above, you will always be using a snapshot version as they are newer
than releases.  I would really think about that before you choose this
path.

The alternative is to take a source copy of the plugin you want and to
internally release it.  This way you know what version revision you
took, what patches were applied, and you can  reproduce your build
internally if you need to.  If you are an open source project then
this workaround won't help you.