Re: m2 and -Plocal (was: mime4j 0.6 preview packages)

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Feb 15, 2009 at 8:41 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>> On Sun, Feb 15, 2009 at 16:55, Stefano Bagnara <ap...@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.

i can appreciate this reasoning

i think that maintaining an offline build capability would be easier
than the current compromise

<snip>

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

the maven build is currently broken but i'm working on fixing it

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

the continuous integration needs sorting out (too much to do, too
little time), and IMHO should be running both maven and ant builds

>> 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 now clean the repo for my build user but not when i develop

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

getting a working offline build isn't that much of a hassle for a
release. what's much more annoying is the active excluding of
repositories for security reasons since this slows down development
for IMHO little gain.

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

the pre-requisite to this would be solving the known potential
licensing and security issues. if these were solved then there would
be little to be gained by hosting a general repository at apache.

- robert