maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
Subject Re: m2 and offline mode
Date Fri, 08 Apr 2005 19:31:50 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Michal Maczka wrote:
>>> Wasn't the offline mode in maven needed only for avoiding checking if
>>> newer snapshots are available
>>> every time maven was run?
>>>
>>>   
>>
>>
>> To me, offline mode is extremely valuable, not only as a way of keeping
>> m2 from attempting to download artifacts, but also in determining what
>> level of success we can expect from other network-related operations.
>>
>> No, it's not only related to snapshots. Even if you were to ignore the
>> other network operations that mojos might attempt, you still have to
>> consider that the download of regular artifacts will be affected by
>> offline status.
>>
>>
>>  
>>
> The dowload of regular artiafcts will only be made if any of them is
> missing and build is going to fail.
> Maybe I am not seeing a full picture here and thinking about  loking too
> much at m1:
> why do you think it might be useful not to perform such operations?
> 

1. Suppose you checked out a project's source code, but haven't built it
yet. Now, you get on a plane, and then try to build the project. At this
point, you will not be able to download anything, regardless of its
version. If we have a good offline mode, it should give a user-friendly
warning here rather than ripping itself apart at the seams.

I admit that this is a bit contrived, but the fact remains that offline
status has wider ramifications than simply dealing with snapshots.

2. In the event that you bind a cvsup goal into your lifecycle ahead of
the compile phase (because you're normally online, and this keeps things
up-to-date), providing a good offline mode would allow your build to
either fail in a very user-friendly and predictable way, or else simply
skip the cvsup goal...and maybe proceed with an invocation of 'compile'.

>>> Is it still needed if better control if and when such checks have to be
>>> made is going to be given?
>>>
>>>   
>>
>>
>> I'm not sure I follow what you're trying to say here. Can you clarify?
>>  
>>
> Sure.
> 
> I meant that if you could :
> 
> - precisly control when snapshot artifacts are updated (via setting some
> repository or even dependecy properties).
>  Brett recently stared implementing some simple strategies for that. It
> will be nice to test how they work in pratice
>  and if anything is missing and if even finer control is needed.
> 
> 
> - define which repositories contain snapshot artifacts  so for example
> you are never going to hit ibiblio
> for checking if newer version of one of your company "private" artifacts
> which obviosly never can  be uploaded there
> is present in it (so snapshot  checking will always be very fast). Note
> that the same can be also applied to regular artifacts.
> 
> then imo there won't be a big need for "offline mode".
> 
> I personally use offline mode in m1 only for avoiding slow connection to
> ibiblio during every run of maven.
> If only intranet repos were checked I would not need it.
> 

Michal, it strikes me that your objections reflect this last statement
strongly...which is to say that since you don't use offline mode for
anything other than snapshot management, you cannot imagine why anyone
ever would do so.

Also, using maven1 as the model here is perhaps not the best idea.
Offline mode in m1 is really rather limited, especially with respect to
disabling infrastructure and providing good feedback to the user. What
I'd really like to see is a build system with a fully integrated offline
mode, which will help the user avoid needless hours debugging the build
system itself. That's what I'm hoping we can design here.

In short, maybe we should examine every behavior of m1 on their merits
before we blindly replicate them.

> 
> 
> Other remark:
> 
> In offline mode in m1 snapshots are not dowloaded from any repository
> including those accessed by file:// protcol.
> 

Again, this is an artifact of m1's behavior and implementation...it's
unnecessary to place such a restriction on the build process.

> 
> best regards
> 
> Michal
> 
> ------------------------------------------------------------------
> Jan Pawel II 1920 - 2005
> http://link.interia.pl/f1871
> 
> 

Regards,

john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCVtwmK3h2CZwO/4URAslSAJsHfk1Wj7q8YuoWRMIOUOytUrlPZgCfS8Yy
VQAnVoLqvsMdtk52gEmr/LA=
=7HKg
-----END PGP SIGNATURE-----

Mime
View raw message