jmod question

[Brian Pontarelli]

On Nov 12, 2009, at 8:57 AM, Jonathan Gibbons wrote:

> Brian Pontarelli wrote:
>>
>> On Nov 11, 2009, at 9:32 PM, Mark Reinhold wrote:
>>
>>>> Date: Wed, 11 Nov 2009 18:31:51 -0800
>>>> From: jonathan.gibbons at sun.com
>>>
>>>> I don't appear to be able to reinstall a module, and there does  
>>>> not appear to
>>>> be a way to remove a module from a library.
>>>
>>> That's right.
>>>
>>>> Does this mean I have to start from scratch every time I want to  
>>>> update the
>>>> modules in a module library?
>>>
>>> I'm afraid so.
>>>
>>> Implementing re-install and un-install is not difficult, it just  
>>> hasn't
>>> yet been a priority.
>>
>> I could be behind on the Jigsaw terms, but why are you re- 
>> installing or un-installing anything? Versioned artifacts should  
>> never change and I'm assuming that a "module" is a versioned  
>> artifact that at some point is associated with class files. Are you  
>> allowing the system to have an artifact change over time?
>>
>> -bp
>>
> I think this boils down to the pragmatic: "mistakes happen."

There a many ways around this. One of the important things I've  
learned over the years of doing dependency management and running the  
Savant project is that allowing a single artifact to change over time  
is really not a good idea. The whole concept of SNAPSHOTs is really  
bad and allowing an artifact to be re-released should be avoided.

By the way, when I say an artifact, it refers to these identifiers  
that uniquely identify a single released entity:

	group (i.e. commons.apache.org)
	project (commons-collections)
	name (commons-collections)
	version (3.1)
	type (jar)

I traditional unified repository (Maven2, Savant, Ivy) this would  
point to a JAR file in this location:

	org/apache/commons/commons-collections/commons-collections/3.1/ 
commons-collections-3.1.jar

Savant uses the concept of integration builds. It puts a lot of  
controls around this concept because auto-upgrading is also extremely  
dangerous. For example, Savant never allows the build to include  
different artifacts on subsequent builds if the configuration hasn't  
changed (no version ranges or latest semantics). It also ensures that  
a single artifact is always consistent (immutable). That is to say  
that a JAR such the commons-collections from above is 100% guaranteed  
to be exactly same no matter where it exists.

You really should never allow re-releasing of artifacts to occur and  
not allow the system to auto-upgrade. I would suggest that you highly  
consider using an integration build concept. It makes life much better  
overall and allows the "mistakes happen" situations to occur without  
impacting consistency. Any time that "mistakes happen" during a full  
release (non-integration build), you should force the developer to  
release a new version to fix it.

-bp