You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@collab.net> on 2004/04/13 04:52:00 UTC
Testing Fulcrum components
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?
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by 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
RE: Testing Fulcrum components
Posted by Eric Pugh <ep...@upstate.com>.
If all this heartburn is from the use of alpha characters in the version,
then I'm happy if a volunteer just updates the various versions (hint
hint!)...
Daniel, glad to see your commits!
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, April 14, 2004 7:34 PM
> To: Turbine Developers List
> Subject: Re: Testing Fulcrum components
>
>
> Daniel Rall wrote:
>
> > Angelo Turetta wrote:
> >
> >> ----- Original Message ----- From: "Daniel L. Rall"
> >> <dl...@finemaltcoding.com>
> >> Sent: Tuesday, April 13, 2004 8:54 PM
> >>
> >>
> >>> The problem has to do with the initialization parameters provided
> >>> to the MimeTypeService when running the tests. I'd be interested
> >>> in hearing more of your thoughts on how use of an alternate build
> >>> environment (e.g. Eclipse) changes things in this regard.
> >>
> >>
> >>
> >> Ever heard me talk about MimeTypeService ?
> >
> >
> > No.
> >
> >> I thought you where referring to my message about Merlin
> refusing to run
> >> because the version string of a component contains the word 'ALPHA'
> >> where a
> >> number is expected!
> >
> >
> > Yes, that's right. I ran into this while attempting to run the tests
> > for the MimeTypeService's implementation (which are triggered
> > automatically on build, bleh).
> >
> >> I argued that, given Eric is obviously not having the same problem, he
> >> should have a different build environment than me.
> >> As Stephen pointed out yesterday, that is true but not in the way I
> >> suggested: I am indeed using maven RC2, which is a main factor, if I
> >> understand correctly.
> >
> >
> > Okay.
>
> Have just patched the avalon distributions for extension handling to
> basically ignore invalid spec versions - if your delete the maven
> /repository/avalon-extension/jars directory and try building ... you
> should trigger a download of the patched jar files - and in principal
> the error should not occur (but I havn't tested it against the fulcrum
> base).
>
> Cheers, Steve.
>
> >
> >
> > ---------------------------------------------------------------------
> > 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by Stephen McConnell <mc...@apache.org>.
Daniel Rall wrote:
> Angelo Turetta wrote:
>
>> ----- Original Message ----- From: "Daniel L. Rall"
>> <dl...@finemaltcoding.com>
>> Sent: Tuesday, April 13, 2004 8:54 PM
>>
>>
>>> The problem has to do with the initialization parameters provided
>>> to the MimeTypeService when running the tests. I'd be interested
>>> in hearing more of your thoughts on how use of an alternate build
>>> environment (e.g. Eclipse) changes things in this regard.
>>
>>
>>
>> Ever heard me talk about MimeTypeService ?
>
>
> No.
>
>> I thought you where referring to my message about Merlin refusing to run
>> because the version string of a component contains the word 'ALPHA'
>> where a
>> number is expected!
>
>
> Yes, that's right. I ran into this while attempting to run the tests
> for the MimeTypeService's implementation (which are triggered
> automatically on build, bleh).
>
>> I argued that, given Eric is obviously not having the same problem, he
>> should have a different build environment than me.
>> As Stephen pointed out yesterday, that is true but not in the way I
>> suggested: I am indeed using maven RC2, which is a main factor, if I
>> understand correctly.
>
>
> Okay.
Have just patched the avalon distributions for extension handling to
basically ignore invalid spec versions - if your delete the maven
/repository/avalon-extension/jars directory and try building ... you
should trigger a download of the patched jar files - and in principal
the error should not occur (but I havn't tested it against the fulcrum
base).
Cheers, Steve.
>
>
> ---------------------------------------------------------------------
> 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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by Daniel Rall <dl...@collab.net>.
Angelo Turetta wrote:
> ----- Original Message -----
> From: "Daniel L. Rall" <dl...@finemaltcoding.com>
> Sent: Tuesday, April 13, 2004 8:54 PM
>
>
>>The problem has to do with the initialization parameters provided
>>to the MimeTypeService when running the tests. I'd be interested
>>in hearing more of your thoughts on how use of an alternate build
>>environment (e.g. Eclipse) changes things in this regard.
>
>
> Ever heard me talk about MimeTypeService ?
No.
> I thought you where referring to my message about Merlin refusing to run
> because the version string of a component contains the word 'ALPHA' where a
> number is expected!
Yes, that's right. I ran into this while attempting to run the tests for the
MimeTypeService's implementation (which are triggered automatically on build, bleh).
> I argued that, given Eric is obviously not having the same problem, he
> should have a different build environment than me.
> As Stephen pointed out yesterday, that is true but not in the way I
> suggested: I am indeed using maven RC2, which is a main factor, if I
> understand correctly.
Okay.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by Angelo Turetta <at...@commit.it>.
----- Original Message -----
From: "Daniel L. Rall" <dl...@finemaltcoding.com>
Sent: Tuesday, April 13, 2004 8:54 PM
> The problem has to do with the initialization parameters provided
> to the MimeTypeService when running the tests. I'd be interested
> in hearing more of your thoughts on how use of an alternate build
> environment (e.g. Eclipse) changes things in this regard.
Ever heard me talk about MimeTypeService ?
I thought you where referring to my message about Merlin refusing to run
because the version string of a component contains the word 'ALPHA' where a
number is expected!
I argued that, given Eric is obviously not having the same problem, he
should have a different build environment than me.
As Stephen pointed out yesterday, that is true but not in the way I
suggested: I am indeed using maven RC2, which is a main factor, if I
understand correctly.
Angelo Turetta
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Angelo Turetta wrote:
> ----- Original Message -----
> From: "Daniel Rall" <dl...@collab.net>
> Sent: Tuesday, April 13, 2004 5:30 AM
>
>
>
>>Daniel Rall wrote:
>>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?
...
> But I'm pretty sure Eric is using some non-maven build environment (Eclipse,
> I think) that solves the right dependencies for him.
The problem has to do with the initialization parameters provided to the
MimeTypeService when running the tests. I'd be interested in hearing more of
your thoughts on how use of an alternate build environment (e.g. Eclipse)
changes things in this regard.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by Angelo Turetta <at...@commit.it>.
----- Original Message -----
From: "Daniel Rall" <dl...@collab.net>
Sent: Tuesday, April 13, 2004 5:30 AM
> Daniel Rall wrote:
> 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 can confirm that I never managed to make the fulcrum tests succeed.
Unluckily I've been very busy this last two months, so I never got back to
try again and investigate the matter.
But I'm pretty sure Eric is using some non-maven build environment (Eclipse,
I think) that solves the right dependencies for him.
Angelo Turetta
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by 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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Testing Fulcrum components
Posted by Daniel Rall <dl...@collab.net>.
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