commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [all] Maven, help or hinderance?
Date Sun, 18 Dec 2005 19:02:30 GMT
On 12/18/05, Henri Yandell <> wrote:


> > 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
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message