Re: [classlib] manifest information
:-( 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] manifest information
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. [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] manifest information
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 [EMAIL PROTECTED]: 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. [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] manifest information
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 [EMAIL PROTECTED]: 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. [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] manifest information
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. [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] manifest information
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. [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
