Re: Testing Fulcrum components

[Stephen McConnell <mc...@apache.org>]

Daniel:

I have located the problem.  Under Maven RC2 the content of the 
generated jar manifest has changed and now sets the Specification 
Version to the same value as the Implementation Version (which is really 
strange).  An even bigger problem here is that a valid Specification 
Version *must* be a dewey decimal (implementation versions may be 
strings) but the jar plugin is not validating the value it is assigning.

This issue has already been resolved in the version 1.2 dev of the 
avalon-util-extension package which will be included in the upcoming 
merlin 3.3.0 release.  In the meantime - the solution is to set you 
project versions to dewey decimals.

Cheers, Stephen.


Daniel Rall wrote:

> Daniel Rall wrote:
> 
>> Eric Pugh wrote:
>> ...
>>
>>> Right now, basically I need help on testing and if someone is motivated,
>>> maybe deprecating the Factory and Pool services in T2.4 and using the
>>> Fulcrum equivalents.
>>
>>
>>
>> Eric, speaking of testing Fulcrum components, today I wrote some tests 
>> for some improvements I made to the MimeTypeService, and was trying to 
>> run them using the Maven build.  Here's the excerpt from my change log 
>> message which describes the problem I was running into:
>>
>>   Note that I could not test this class with
>>   merlin-plugin-1.1-SNAPSHOT, merlin-unit-3.2.10,
>>   avalon-extension-impl-1.1, and avalon-extension-spi-1.1 due to the
>>   following exception:
>>
>>     java.lang.IllegalArgumentException: Bad specification version
>>     format '1.0-alpha-4' in 'fulcrum-mimetype-api'. (Reason:
>>     java.lang.NumberFormatException: For input string: "0-alpha-4")
>>     org.apache.avalon.extension.Extension.<init>(Extension.java:444)
>>     ...
>>
>> org.apache.avalon.merlin.unit.AbstractMerlinTestCase.setUp(AbstractMerlinTestCase.java:198) 
>>
>>     ...
>>
>>   This has something to do with the format of the version number used
>>   in both the Avalon block.xml used while running the tests, which is
>>   repeated in mimetype-impl's project.xml.  The test case for the
>>   following class ran fine (as no Avalon init necessary), so I was
>>   able to verify the core of the change.
>>
>> Care to hit me with the clue bat?
> 
> 
> Rummaging around in the archive turned up a tidbit of info on this.  
> Angelo Turetta asked this question back near the end of 2003 (Subject: 
> "What kind of magic am I missing?").  Eric wasn't sure about this, and 
> Stephen McConnell -- with hazy references to Java's manifest spec -- 
> responded that the version numbers should be made dotted-decimal.  Any 
> plans in this regard?
> 
> I've been a fan of the three part dotted-numeric version number for 
> quite some time now.  You _release_ (neat, that) x.y.z, and call it an 
> alpha or beta or gamma or whatever Greek character you pulled from your 
> alphabet soup that morning, and bump z (or even y) until enough bug 
> fixes have gone in give it the stability to be deemed "final".  In this 
> scenario, the label designating the quality of or vendor (us) confidence 
> in the release is separate from the version number.  This allows you to 
> do things like ship a 3.0.0 and call it a GA, production quality, 
> scalable piece of software, and (bonus!) have users actually believe 
> you.  APR has some good guidelines along these lines 
> <http://apr.apache.org/versioning.html>, which I believe I've mentioned 
> on this list before (hint hint).
> 
> - Dan
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> 
> 


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org