On 12/18/05, Henri Yandell <[EMAIL PROTECTED]> wrote: <snip/>
> > 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. Sorry, but have to disagree with that. Of course, there is no "technical tradeoff" here - i.e., if we get the right tools in place we can have both, or at least have component code quality the only thing that we need to worry about. > > 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. > I would not use the term "yelling" since my experience has been that the maven community is pretty responsive. > > 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). > See other response. We need to think through the options carefully: 1) patch maven 1 site, jar, dist plugins to do everything we need 2) patch above plugins to do most of what we need and tie together with a pair of lightweight commons plugins (say commons-site and commons-dist) 3) = 2) - 1) 4) = 1) recast in maven 2 setup (different base plugin structure) 5) = 3) recast in maven 2 I agree with Hen that time delay getting maven plugin releases cranked should not be a big consideration. As I said above, the maven team is pretty responsive. What I think *is* a big consideration is the size and complexity of the plugin code that we will be taking on. I think we definitiely need something, but we need to KISS. The custom site jsl and nav stuff in commons-build is already a pain to maintain and lets face it, we would all rather spend our hacking time on the "real code" in the components. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
