You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by softwarepills <os...@softwarepills.com> on 2008/10/02 11:43:03 UTC
Deterministic update of snapshots
If i am not wrong, with unique=false and policy=daily, snaphot updating
follows this rules:
1.- Update check (and posibly update itself) is made a day after last
publishing in the remote repository of the single artifact being checked. So
it could be at any time, any day, and different for every artifact, as they
are involved in the current build (not all artifacts at the same time at
12:00 pm, for example).
2.- As said in http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
every time a new remote snapshot is published, it will overwrite a local
snapshot regardless of age. This is the only way to provide consistent
behaviour and avoid clock skew - for example, while it might make sense to
honour a local snapshot if it were newer than the remote snapshot, it may be
that the local one was built from older sources and so is, in fact, older.
For me, this could be very confusing in a team development process
(especially 2).
I think a deterministic way of snapshot updating is preferable using
policiy=never. In this way you always preserve the same snaphots and,
eventually, you can use -U to compile with fresh snaphost and get in sync
with the team.
Of course, you get a deterministic way of snaphot updating at expense of
automatic updates, and posibilly, you can discover that one lazy developer
has never used -U and is using very old snaphots.
Please, any comments are welcome.
--
View this message in context: http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19776315.html
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: Deterministic update of snapshots
Posted by softwarepills <os...@softwarepills.com>.
Please, could someone confirm points 1 and 2?
softwarepills wrote:
>
> Thanks for your response.
>
> Yes, you are right. But we are now starting the development of a big
> system, so till we reach a stable stage where release is posible, we have
> many snaphosts.
>
> I was using "deterministic" applied to the update moment as now happens
> that someone is working on a module and suddenly it get compile errors as
> some snapshot has been updated. In that moment he may think that the error
> is due to his own changes in the code of the assigned module. The result
> is that many people comes to me to ask about strange behaviors of Maven.
>
> So, only to let it clear, my assumptions 1 and 2 are correct?
>
> If the answer is yes, do you think its correct to use policy=never in this
> scenario?
>
>
> Michael McCallum-3 wrote:
>>
>> deterministic and snapshot just don't go together... as the result of any
>> update is non-deterministic and being able to undo an update if rather
>> difficult.
>>
>> you can use range to achieve and agile deterministic release process
>> where you
>> can roll forward or back anytime you like but get the latest by
>> default...
>>
>> assuming you have reasonable tests and some communication you rarely
>> break
>> people in this way
>>
>> On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
>>> If i am not wrong, with unique=false and policy=daily, snaphot updating
>>> follows this rules:
>>>
>>> 1.- Update check (and posibly update itself) is made a day after last
>>> publishing in the remote repository of the single artifact being
>>> checked.
>>> So it could be at any time, any day, and different for every artifact,
>>> as
>>> they are involved in the current build (not all artifacts at the same
>>> time
>>> at 12:00 pm, for example).
>>>
>>> 2.- As said in
>>> http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
>>> every time a new remote snapshot is published, it will overwrite a local
>>> snapshot regardless of age. This is the only way to provide consistent
>>> behaviour and avoid clock skew - for example, while it might make sense
>>> to
>>> honour a local snapshot if it were newer than the remote snapshot, it
>>> may
>>> be that the local one was built from older sources and so is, in fact,
>>> older.
>>>
>>> For me, this could be very confusing in a team development process
>>> (especially 2).
>>>
>>> I think a deterministic way of snapshot updating is preferable using
>>> policiy=never. In this way you always preserve the same snaphots and,
>>> eventually, you can use -U to compile with fresh snaphost and get in
>>> sync
>>> with the team.
>>>
>>> Of course, you get a deterministic way of snaphot updating at expense of
>>> automatic updates, and posibilly, you can discover that one lazy
>>> developer
>>> has never used -U and is using very old snaphots.
>>>
>>> Please, any comments are welcome.
>>
>>
>>
>> --
>> Michael McCallum
>> Enterprise Engineer
>> mailto:gholam@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19784075.html
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: Deterministic update of snapshots
Posted by softwarepills <os...@softwarepills.com>.
Thanks for your response.
Yes, you are right. But we are now starting the development of a big system,
so till we reach a stable stage where release is posible, we have many
snaphosts.
I was using "deterministic" applied to the update moment as now happens that
someone is working on a module and suddenly it get compile errors as some
snapshot has been updated. In that moment he may think that the error is due
to his own changes in the code of the assigned module. The result is that
many people comes to me to ask about strange behaviors of Maven.
So, only to let it clear, my assumptions 1 and 2 are correct?
If the answer is yes, do you think its correct to use policy=never in this
scenario?
Michael McCallum-3 wrote:
>
> deterministic and snapshot just don't go together... as the result of any
> update is non-deterministic and being able to undo an update if rather
> difficult.
>
> you can use range to achieve and agile deterministic release process where
> you
> can roll forward or back anytime you like but get the latest by default...
>
> assuming you have reasonable tests and some communication you rarely break
> people in this way
>
> On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
>> If i am not wrong, with unique=false and policy=daily, snaphot updating
>> follows this rules:
>>
>> 1.- Update check (and posibly update itself) is made a day after last
>> publishing in the remote repository of the single artifact being checked.
>> So it could be at any time, any day, and different for every artifact, as
>> they are involved in the current build (not all artifacts at the same
>> time
>> at 12:00 pm, for example).
>>
>> 2.- As said in
>> http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
>> every time a new remote snapshot is published, it will overwrite a local
>> snapshot regardless of age. This is the only way to provide consistent
>> behaviour and avoid clock skew - for example, while it might make sense
>> to
>> honour a local snapshot if it were newer than the remote snapshot, it may
>> be that the local one was built from older sources and so is, in fact,
>> older.
>>
>> For me, this could be very confusing in a team development process
>> (especially 2).
>>
>> I think a deterministic way of snapshot updating is preferable using
>> policiy=never. In this way you always preserve the same snaphots and,
>> eventually, you can use -U to compile with fresh snaphost and get in sync
>> with the team.
>>
>> Of course, you get a deterministic way of snaphot updating at expense of
>> automatic updates, and posibilly, you can discover that one lazy
>> developer
>> has never used -U and is using very old snaphots.
>>
>> Please, any comments are welcome.
>
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19776836.html
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: Deterministic update of snapshots
Posted by Michael McCallum <gh...@apache.org>.
deterministic and snapshot just don't go together... as the result of any
update is non-deterministic and being able to undo an update if rather
difficult.
you can use range to achieve and agile deterministic release process where you
can roll forward or back anytime you like but get the latest by default...
assuming you have reasonable tests and some communication you rarely break
people in this way
On Thu, 02 Oct 2008 22:43:03 softwarepills wrote:
> If i am not wrong, with unique=false and policy=daily, snaphot updating
> follows this rules:
>
> 1.- Update check (and posibly update itself) is made a day after last
> publishing in the remote repository of the single artifact being checked.
> So it could be at any time, any day, and different for every artifact, as
> they are involved in the current build (not all artifacts at the same time
> at 12:00 pm, for example).
>
> 2.- As said in http://docs.codehaus.org/pages/viewpage.action?pageId=22585,
> every time a new remote snapshot is published, it will overwrite a local
> snapshot regardless of age. This is the only way to provide consistent
> behaviour and avoid clock skew - for example, while it might make sense to
> honour a local snapshot if it were newer than the remote snapshot, it may
> be that the local one was built from older sources and so is, in fact,
> older.
>
> For me, this could be very confusing in a team development process
> (especially 2).
>
> I think a deterministic way of snapshot updating is preferable using
> policiy=never. In this way you always preserve the same snaphots and,
> eventually, you can use -U to compile with fresh snaphost and get in sync
> with the team.
>
> Of course, you get a deterministic way of snaphot updating at expense of
> automatic updates, and posibilly, you can discover that one lazy developer
> has never used -U and is using very old snaphots.
>
> Please, any comments are welcome.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org