[classlib] metadata-fest

[Tim Ellison <t....@gmail.com>]

[ If you don't know/care about either OSGi manifests or Eclipse, then
don't worry, you can ignore this note -- just continue as you are. ]


I'm going through the module manifests and putting in some explicit
imports to satisfy the requirements of the tests within a module.

Since this means that a module will now 'import' (depend upon) a package
only because a test case uses it, I'm marking such imports in the
manifest as 'optional' -- this means that the same manifest can be used
in development and in the JARs that we deploy at runtime (which don't
contain the test code).  The alternative would have been to move test
code out into a separate module but I'm NOT going there!

Similarly, where a module manifest exports a package only to satisfy
somebody else's test code, it is done with a mandatory attribute to show
why it is being imported.

I'll also commit updates Eclipse metadata (.project and .classpath
files) for our modules, for those people who want to follow along.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib] metadata-fest

[Geir Magnusson Jr <ge...@pobox.com>]

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> [ If you don't know/care about either OSGi manifests or Eclipse, then
>>> don't worry, you can ignore this note -- just continue as you are. ]
>>>
>>>
>>> I'm going through the module manifests and putting in some explicit
>>> imports to satisfy the requirements of the tests within a module.
>>>
>>> Since this means that a module will now 'import' (depend upon) a package
>>> only because a test case uses it, I'm marking such imports in the
>>> manifest as 'optional' -- this means that the same manifest can be used
>>> in development and in the JARs that we deploy at runtime (which don't
>>> contain the test code).  The alternative would have been to move test
>>> code out into a separate module but I'm NOT going there!
>> That makes sense.
>>
>>> Similarly, where a module manifest exports a package only to satisfy
>>> somebody else's test code, it is done with a mandatory attribute to show
>>> why it is being imported.
>> :/
>>
>> What's the downside?
> 
> Clutter in the manifests.
> 
>> It doesn't matter now, but in the future, should
>> we consider having the manifests assembled as part of the build based on
>> target?  Talking out of my hat, it sounds like each breaks into two
>> parts, a 'manifest base' and 'manifest test' or -ish...
> 
> Component-based tools work on whole manifests, so unless we wanted to do
> it all manually or roll our own then having bona fide manifests makes sense.

?

I was thinking we'd just assemble them at build time.  IOW, when doing a 
test build, combine the base and test fragments into the manifest, and 
when doing a build for dist, leave off the test.

Downside is that you can't build/test/package in one shot, which I'll 
admit is a biggie, and one I wouldn't accept either...

> As above, breaking it into two parts can be done by making the impl and
> tests separate components with separate manifests.

But as you noted, that sounds yecchy anyway.... or is it?  it's actually 
cleaner, and there is no need to re-modularize -  just have a 
<module>test.jar manifest along with the <module>.jar manifest?


geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib] metadata-fest

[Tim Ellison <t....@gmail.com>]

Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> [ If you don't know/care about either OSGi manifests or Eclipse, then
>> don't worry, you can ignore this note -- just continue as you are. ]
>>
>>
>> I'm going through the module manifests and putting in some explicit
>> imports to satisfy the requirements of the tests within a module.
>>
>> Since this means that a module will now 'import' (depend upon) a package
>> only because a test case uses it, I'm marking such imports in the
>> manifest as 'optional' -- this means that the same manifest can be used
>> in development and in the JARs that we deploy at runtime (which don't
>> contain the test code).  The alternative would have been to move test
>> code out into a separate module but I'm NOT going there!
> 
> That makes sense.
> 
>>
>> Similarly, where a module manifest exports a package only to satisfy
>> somebody else's test code, it is done with a mandatory attribute to show
>> why it is being imported.
> 
> :/
> 
> What's the downside?

Clutter in the manifests.

> It doesn't matter now, but in the future, should
> we consider having the manifests assembled as part of the build based on
> target?  Talking out of my hat, it sounds like each breaks into two
> parts, a 'manifest base' and 'manifest test' or -ish...

Component-based tools work on whole manifests, so unless we wanted to do
it all manually or roll our own then having bona fide manifests makes sense.
As above, breaking it into two parts can be done by making the impl and
tests separate components with separate manifests.

>> I'll also commit updates Eclipse metadata (.project and .classpath
>> files) for our modules, for those people who want to follow along.
> 
> Common custom is to keep that kind of thing out of SVN but I realize
> that as Eclipse is such a bear to set up....  ;)

Ack, the saving grace is that this data is kept out of the way (i.e.
there are no mark-ups in the .java files etc. that people will regularly
see).

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib] metadata-fest

[Geir Magnusson Jr <ge...@pobox.com>]

Tim Ellison wrote:
> [ If you don't know/care about either OSGi manifests or Eclipse, then
> don't worry, you can ignore this note -- just continue as you are. ]
> 
> 
> I'm going through the module manifests and putting in some explicit
> imports to satisfy the requirements of the tests within a module.
> 
> Since this means that a module will now 'import' (depend upon) a package
> only because a test case uses it, I'm marking such imports in the
> manifest as 'optional' -- this means that the same manifest can be used
> in development and in the JARs that we deploy at runtime (which don't
> contain the test code).  The alternative would have been to move test
> code out into a separate module but I'm NOT going there!

That makes sense.

> 
> Similarly, where a module manifest exports a package only to satisfy
> somebody else's test code, it is done with a mandatory attribute to show
> why it is being imported.

:/

What's the downside?  It doesn't matter now, but in the future, should 
we consider having the manifests assembled as part of the build based on 
target?  Talking out of my hat, it sounds like each breaks into two 
parts, a 'manifest base' and 'manifest test' or -ish...

> 
> I'll also commit updates Eclipse metadata (.project and .classpath
> files) for our modules, for those people who want to follow along.

Common custom is to keep that kind of thing out of SVN but I realize 
that as Eclipse is such a bear to set up....  ;)

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org