james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject m2 and -Plocal (was: mime4j 0.6 preview packages)
Date Sun, 15 Feb 2009 20:41:15 GMT
Bernd Fondermann ha scritto:
> On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <apache@bago.org> wrote:
> <snip/>
> 
>>>> Is maven version 2.0.6 still sufficient?
>>>> And for me "mvn package" always did the job; no -U, no -Plocal..
>>>>
>>> Neither option is required. I guess -Plocal can come handy when building
>>> packages while off-line.
>> -Plocal has been introduced as a *compromise* by me 2 years ago, after
>> working weeks (if not months) trying to satisfy really strict security
>> requirements from other PMC members. They was rejecting the use of maven
>> to make releases if this meant to use remote repositories because of
>> security concerns.
>>
>> Even if I understand and share the security issues and the
>> reproducibility issues with m2, I always thought that the whole issue
>> was a big waste of time for me and for the JAMES project. THE solution
>> for maven and this issue is to setup our own repository with a
>> repository manager. Unfortunately it seems there is no will to setup
>> this kind of 3rd party repository inside the ASF.
>>
>> The whole thing had already found inconsistency when we decided that we
>> was not entitled shipping poms for jars that we ship in the stage folder
>> (expecially wrt javamail stuff).
>>
>> That said, here is my +1 to remove the -Plocal suggestion in BUILDING.txt.
> 
> For me the foremost reason to not rely on a remote maven repos is that
> I firmly believe that any ASF project should be self-hosting.
> (I'm repeating myself here of course, but I'd like to say it again as
> the maven question has been brought up again.)
> Self-hosting has its limits, of course we won't keep copies of ant or
> the JDK around. But all the funny (to use a nice f-word) little maven
> dependencies and plug-ins can really make your day, especially when
> not accessible, either because servers are unreachable or working
> offline.

Have you ever tried a repository manager? (e.g: Nexus, or Archiva if you
want to stay Apache).

> For example: I'm connected to the net right now. I run 'mvn
> dependency:tree', on a James server trunk checkout and I'm getting
> errors. Mmhhh. Maybe this mvn build is not maintained, but the general
> experience is: If maven works, you're fine. But if you get dependency
> errors, you are really in trouble.

I feel the same with any build tool I don't know. Whenever I have to
build a python or perl project if it works I'm fine, but if I get any
error I'm really in trouble. It's just a matter of knowledge of the
tool. The choice of the build tool is just as important as the choice of
the language or the choice of a dependency.

> Purging a local m2 repo cannot be recommended. So prestine builds are
> not really happening, because of the local m2.

You can specify a custom local repository when you run m2.

> What if somebody wants to build one of our mvn dependent products in 5
> or 10 years? Should that work? I firmly doubt it will!

IMO to release is much more important than to be able to reproduce a
release in 10 years. So first we should be able to release with no PITA,
then when there will be spare cycle we'll find time to create a virtual
machine with the right os, the right libraries, the right JVM, the right
DATE/TIME of the virtual machine, the right build tool, and all the
dependencies.

> Maybe the solution is to establish a repo for our James product
> dependencies here in our own project. But that will likely create
> distribution issues.
> 
> I don't want to be a PITA, you can change the build to not depend on
> -Plocal. I backup my local m2 anyway.

IMHO ASF should have an ASF managed m2 repository (the maven central is
managed by apache people, but not with their apache hats). Or even
better, each PMC should have its own repository (disk space is cheap,
cheaper than discussions to achieve compromises).

Stefano

Mime
View raw message