On 12/18/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > i think that there are two different kinds of specific need here. IMO > both are not negotiable (for different reasons). > > the ASF has a few specific needs which maven either does not provide at > the moment (for example, NOTICE.xml) or which maven should not provide > since they are too specific to the ASF (for example, the symlink build > structure). these needs are non-negotiable. > > i think that these needs are best satisfied by the creation of a jakarta > or apache plug-in as suggested by brett.
Somewhat. Things like being on a weird set of plugin versions just needs to be rolled back to the known version, unless it's transparent to the user due to the commons-plugin dependencies. > there are another set of needs which fall under best practise. over the > last year (or two), the commons has started to come under intense > scrutiny. we are now the establishment and any times that we fall short > of the highest standards, we can expect to be held up as examples of bad > practise throughout the java community. i agree with stephen that our > releases now need to be of the highest possible standard. i'm no longer > to willing to accept lower quality releases as a result of using maven. > so again, these are not negotiable. Depends. Highest possible standard makes it harder for development momentum to happen. That's a given. If the level of quality is damaging to the momentum of the community, then I'm +1 for releasing a lower quality, keeping developer momentum is more important than code quality. The plugin should solve this, along with scripts etc. Basically we need to keep a focus on developer simplicity. The lower the barrier to entry/momentum, the easier it'll be for us to develop. > in the past, we haven't been very effective (as we might) at feeding > through these emerging best practises to maven. it's pretty much been +1. We need to start yelling at maven to fix/add them and dealing with the lower quality in the meantime instead of hacking them ourselves. Increasingly this'll mean being on maven2, so we should be trying to get there soon. > only phil. i'm going to try to be more active (and hope others will do > the same). however, it is clear that one problem we have is that the > feedback cycle is too inefficient: we can't afford to wait a month or > two for new plugin releases and we're finding it hard to ensure everyone > has the required versions. perhaps managing our plugin would made this > easier. Perhaps, though I think we can afford to wait a month or two. Years maybe not, but it's not the end of the world if we knowlingly distribute a few more jars without the Vendor-Distribution-Id for example (or whatever that property name was). Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
