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]
