james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bernd.fonderm...@googlemail.com>
Subject Re: m2 and -Plocal (was: mime4j 0.6 preview packages)
Date Sun, 15 Feb 2009 20:58:48 GMT
On Sun, Feb 15, 2009 at 21:41, Stefano Bagnara <apache@bago.org> wrote:
> 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).

I know them. There are simply no additional benefits for me in them.

>> 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.

I know maven well enough. I use it nearly every day. That's not the
problem here.

>> 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.

I know. But who does that before building? Robert. But no other sane person.

>> 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.

We primarily ship code. Do you say we should stop that, because it's
not important if that works (now or in 1 or 5 or 10 years)? To build a
src dist with mvn you need resolve much to much dependencies (IMHO).

> So first we should be able to release with no PITA,

at least this works with maven ;-)

> 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
>

Bernd

Mime
View raw message