On 07/15/11 08:44, Stefan Bodewig wrote: <snip>
> I don't really see how Maven or Ant would fit if the only integration to > their flagships is by spawning a new process (or maybe run the scripts > in VM using Jython, I don't know). > > To me it sounds as if you are looking for a home for "a bunch of scripts > we use around the release process". Something we don't really have, so > a new TLP seems more appropriate - if we have and keep the momentum. > This new TLP would likely be more focussed on users that are expected to > use trunk versions of the scripts than to have releases - no realy end > users at all, this is quite similar to Gump. Yes, quite similar to Gump to some ways but let me explain my thinking a little more... Some use cases (I think distinct) [1] [Release Review] * Comprehension - discovering and understanding what's there * Audit - account for contents [Build accounting for exceptions to general rules] * Verification - check that new exceptions are intentional * Documentation - describe exceptions To take a recent example (from over in James-land) I discovered (assisted by comprehension tooling) that some jars were missing OSGi bindings. To ensure this issue was fixed, I needed to determine every jar with this problem and conform that they were fixed when the release was re-rolled. Going forward, adding verification rules to the build would catch this problem before release. Reviewers of releases are under time pressure and care only about a special case. For build time verification tools, releases are essential and regression is high impact. Adding overly specific rules to verification tools causes maintenance problems. It's become clear to me that trying to resolve these competing needs within a single code base is difficult. IMHO the right way forward is to flow new rules down: comprehension -> audit -> verification -> documentation (-> generation), and that's why I'm very keen on building a single, language agnostic community. To continue the example I recently added comprehension scripting for META-INF to eye, reporting on the contents of the META-INF in each jar. But checking this report manually is time consuming and error prone. So, next I'll add an audit report to print violations of a couple of suitable rules. These rules might need some refinement iterations. Once they work well for me, I'll set some time aside to talk to the community about the best way to support them in build-time verification. Robert [1] leaving out smart generation use cases eg license application and legal document generation
