You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/10/05 00:37:36 UTC
[classlib] manifest information
Can we consider making the final manifest that goes into our jars to be
created/updated dynamically?
I just went through all manifests and added Specification-Version,
Implementation-Version, etc and they will change, at least the last one.
I know the Eclipse people depend on them, so maybe can we used ant's
filtering to set the Impl-Version dynamically? Or something like that?
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] manifest information
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> :-( Implementation-Version is (or maybe 'was' now) being set
> dynamically. I don;t expect the impl version to be the same as the spec
> version.
Was it? Whoops :) I'll undo. Ah - I went through and added them
because I wasn't getting it in a test, and now that I think about it, it
was because of kernel.jar not having it... which I fixed in DRLVM
>
> See the build-jar target in each module's build.xml that sets it to the
> ${svn.info}.
Ok
>
> The Specification-Version: can be a property too.
>
> Regards,
> Tim
>
> Geir Magnusson Jr. wrote:
>> Can we consider making the final manifest that goes into our jars to be
>> created/updated dynamically?
>>
>> I just went through all manifests and added Specification-Version,
>> Implementation-Version, etc and they will change, at least the last one.
>>
>> I know the Eclipse people depend on them, so maybe can we used ant's
>> filtering to set the Impl-Version dynamically? Or something like that?
>>
>> 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
>>
>>
>
---------------------------------------------------------------------
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] manifest information
Posted by Tim Ellison <t....@gmail.com>.
:-( Implementation-Version is (or maybe 'was' now) being set
dynamically. I don;t expect the impl version to be the same as the spec
version.
See the build-jar target in each module's build.xml that sets it to the
${svn.info}.
The Specification-Version: can be a property too.
Regards,
Tim
Geir Magnusson Jr. wrote:
> Can we consider making the final manifest that goes into our jars to be
> created/updated dynamically?
>
> I just went through all manifests and added Specification-Version,
> Implementation-Version, etc and they will change, at least the last one.
>
> I know the Eclipse people depend on them, so maybe can we used ant's
> filtering to set the Impl-Version dynamically? Or something like that?
>
> 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
>
>
--
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] manifest information
Posted by Tim Ellison <t....@gmail.com>.
Alexey Petrenko wrote:
> Tim,
>
> I got your point and mostly agree with you.
Which bit do you disagree with <g> ?
> But in this case we really need some dependency checking routine
> because now nobody checks them.
Well the Eclipse-based people will be checking them (since we get
compiler errors for references outside the module definition).
I agree with a general purpose dependency check, and will investigate it.
Regards,
Tim
> 2006/10/5, Tim Ellison <t....@gmail.com>:
>> Alexey Petrenko wrote:
>> > We also need to keep Import-Package section up to date...
>>
>> For sure, and (just to be clear to all) these are not just for Eclipse's
>> benefit, they are for our benefit as they are the definition of our
>> class library modularity. When you add a new Import or Export you are
>> changing the module's interface and potentially adding new coupling. It
>> should not be undertaken lightly.
>>
>> I appreciate that it is hard to maintain the module boundaries if you
>> don't use a tool like Eclipse that warns you if you reach outside the
>> module definition; and we should consider adding such a check into the
>> automated build.
>>
>> Therefore, I'd not be in favour of automatically updating the Imports
>> and Exports in the manifest -- it would hide any widening of the
>> inter-module dependencies and we could end up with the spaghetti code
>> evident in 'other popular implementations of the spec'.
>>
>> Regards,
>> Tim
>>
>> > 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
>> >> Can we consider making the final manifest that goes into our jars
>> to be
>> >> created/updated dynamically?
>> >>
>> >> I just went through all manifests and added Specification-Version,
>> >> Implementation-Version, etc and they will change, at least the last
>> one.
>> >>
>> >> I know the Eclipse people depend on them, so maybe can we used ant's
>> >> filtering to set the Impl-Version dynamically? Or something like
>> that?
>> >>
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> 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
>>
>>
>
>
--
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] manifest information
Posted by Alexey Petrenko <al...@gmail.com>.
Tim,
I got your point and mostly agree with you.
But in this case we really need some dependency checking routine
because now nobody checks them.
SY, Alexey
2006/10/5, Tim Ellison <t....@gmail.com>:
> Alexey Petrenko wrote:
> > We also need to keep Import-Package section up to date...
>
> For sure, and (just to be clear to all) these are not just for Eclipse's
> benefit, they are for our benefit as they are the definition of our
> class library modularity. When you add a new Import or Export you are
> changing the module's interface and potentially adding new coupling. It
> should not be undertaken lightly.
>
> I appreciate that it is hard to maintain the module boundaries if you
> don't use a tool like Eclipse that warns you if you reach outside the
> module definition; and we should consider adding such a check into the
> automated build.
>
> Therefore, I'd not be in favour of automatically updating the Imports
> and Exports in the manifest -- it would hide any widening of the
> inter-module dependencies and we could end up with the spaghetti code
> evident in 'other popular implementations of the spec'.
>
> Regards,
> Tim
>
> > 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
> >> Can we consider making the final manifest that goes into our jars to be
> >> created/updated dynamically?
> >>
> >> I just went through all manifests and added Specification-Version,
> >> Implementation-Version, etc and they will change, at least the last one.
> >>
> >> I know the Eclipse people depend on them, so maybe can we used ant's
> >> filtering to set the Impl-Version dynamically? Or something like that?
> >>
> >> 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
> >>
> >>
> >
> >
>
> --
>
> 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
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
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] manifest information
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stepan Mishura wrote:
> On 10/5/06, Tim Ellison wrote:
>>
>> Alexey Petrenko wrote:
>> > We also need to keep Import-Package section up to date...
>>
>> For sure, and (just to be clear to all) these are not just for Eclipse's
>> benefit, they are for our benefit as they are the definition of our
>> class library modularity. When you add a new Import or Export you are
>> changing the module's interface and potentially adding new coupling. It
>> should not be undertaken lightly.
>
>
>
> Hi Tim,
>
> I've just realized that I don't really understand why we should add tests'
> dependencies to manifest. I guess that I missed something. I've looked
> through harmony-dev mail archive but I haven't find answer. Could you give
> me a hint where to look at?
I asked that a while ago, and it's still an outstanding question. I
really don't mind them there, but seems it would be cleaner if we had a
second manifest for the test jars or something...
>
> Thanks,
> Stepan.
>
> I appreciate that it is hard to maintain the module boundaries if you
>> don't use a tool like Eclipse that warns you if you reach outside the
>> module definition; and we should consider adding such a check into the
>> automated build.
>>
>> Therefore, I'd not be in favour of automatically updating the Imports
>> and Exports in the manifest -- it would hide any widening of the
>> inter-module dependencies and we could end up with the spaghetti code
>> evident in 'other popular implementations of the spec'.
>>
>> Regards,
>> Tim
>>
>> > 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
>> >> Can we consider making the final manifest that goes into our jars
>> to be
>> >> created/updated dynamically?
>> >>
>> >> I just went through all manifests and added Specification-Version,
>> >> Implementation-Version, etc and they will change, at least the last
>> one.
>> >>
>> >> I know the Eclipse people depend on them, so maybe can we used ant's
>> >> filtering to set the Impl-Version dynamically? Or something like
>> that?
>> >>
>> >> 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
>
---------------------------------------------------------------------
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] manifest information
Posted by Stepan Mishura <st...@gmail.com>.
On 10/5/06, Tim Ellison wrote:
>
> Alexey Petrenko wrote:
> > We also need to keep Import-Package section up to date...
>
> For sure, and (just to be clear to all) these are not just for Eclipse's
> benefit, they are for our benefit as they are the definition of our
> class library modularity. When you add a new Import or Export you are
> changing the module's interface and potentially adding new coupling. It
> should not be undertaken lightly.
Hi Tim,
I've just realized that I don't really understand why we should add tests'
dependencies to manifest. I guess that I missed something. I've looked
through harmony-dev mail archive but I haven't find answer. Could you give
me a hint where to look at?
Thanks,
Stepan.
I appreciate that it is hard to maintain the module boundaries if you
> don't use a tool like Eclipse that warns you if you reach outside the
> module definition; and we should consider adding such a check into the
> automated build.
>
> Therefore, I'd not be in favour of automatically updating the Imports
> and Exports in the manifest -- it would hide any widening of the
> inter-module dependencies and we could end up with the spaghetti code
> evident in 'other popular implementations of the spec'.
>
> Regards,
> Tim
>
> > 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
> >> Can we consider making the final manifest that goes into our jars to be
> >> created/updated dynamically?
> >>
> >> I just went through all manifests and added Specification-Version,
> >> Implementation-Version, etc and they will change, at least the last
> one.
> >>
> >> I know the Eclipse people depend on them, so maybe can we used ant's
> >> filtering to set the Impl-Version dynamically? Or something like that?
> >>
> >> 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] manifest information
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Alexey Petrenko wrote:
>> We also need to keep Import-Package section up to date...
>
> For sure, and (just to be clear to all) these are not just for Eclipse's
> benefit, they are for our benefit as they are the definition of our
> class library modularity. When you add a new Import or Export you are
> changing the module's interface and potentially adding new coupling. It
> should not be undertaken lightly.
>
> I appreciate that it is hard to maintain the module boundaries if you
> don't use a tool like Eclipse that warns you if you reach outside the
> module definition; and we should consider adding such a check into the
> automated build.
>
> Therefore, I'd not be in favour of automatically updating the Imports
> and Exports in the manifest -- it would hide any widening of the
> inter-module dependencies and we could end up with the spaghetti code
> evident in 'other popular implementations of the spec'.
Right - I was going to say similar. I think that the import/export
should be changed by deliberate decisions by humans... The data is
unique to that manifest too.
geir
>
> Regards,
> Tim
>
>> 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
>>> Can we consider making the final manifest that goes into our jars to be
>>> created/updated dynamically?
>>>
>>> I just went through all manifests and added Specification-Version,
>>> Implementation-Version, etc and they will change, at least the last one.
>>>
>>> I know the Eclipse people depend on them, so maybe can we used ant's
>>> filtering to set the Impl-Version dynamically? Or something like that?
>>>
>>> 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
>>>
>>>
>>
>
---------------------------------------------------------------------
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] manifest information
Posted by Tim Ellison <t....@gmail.com>.
Alexey Petrenko wrote:
> We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library modularity. When you add a new Import or Export you are
changing the module's interface and potentially adding new coupling. It
should not be undertaken lightly.
I appreciate that it is hard to maintain the module boundaries if you
don't use a tool like Eclipse that warns you if you reach outside the
module definition; and we should consider adding such a check into the
automated build.
Therefore, I'd not be in favour of automatically updating the Imports
and Exports in the manifest -- it would hide any widening of the
inter-module dependencies and we could end up with the spaghetti code
evident in 'other popular implementations of the spec'.
Regards,
Tim
> 2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
>> Can we consider making the final manifest that goes into our jars to be
>> created/updated dynamically?
>>
>> I just went through all manifests and added Specification-Version,
>> Implementation-Version, etc and they will change, at least the last one.
>>
>> I know the Eclipse people depend on them, so maybe can we used ant's
>> filtering to set the Impl-Version dynamically? Or something like that?
>>
>> 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
>>
>>
>
>
--
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] manifest information
Posted by Alexey Petrenko <al...@gmail.com>.
We also need to keep Import-Package section up to date...
SY, Alexey
2006/10/5, Geir Magnusson Jr. <ge...@pobox.com>:
> Can we consider making the final manifest that goes into our jars to be
> created/updated dynamically?
>
> I just went through all manifests and added Specification-Version,
> Implementation-Version, etc and they will change, at least the last one.
>
> I know the Eclipse people depend on them, so maybe can we used ant's
> filtering to set the Impl-Version dynamically? Or something like that?
>
> 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
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
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