On 28/08/2006, at 7:14 AM, Wendell Beckwith wrote:
Take toady's latest example, say you want to remove an ant build
file and do
things the maven way, so you decide to use the dependency plugin.
The web
site examples have the group and artifactId being
<groupId>org.apache.maven.plugin</groupId>
<artifactId>dependency-maven-plugin</artifactId>
The dependency plugin was accepted to this project, but hasn't yet
been released here. IMO, we should remove it from the plugin list or
put it in a separate section as it shouldn't be considered ready for
use here yet.
Still, please do file bugs against it where there are documentation
issues.
1.) Publish a project plan and commit to periodic milestones.
Yes, we need a roadmap. Development on the Maven core has been on the
backkburner as we fix peoples pressing issues and work on the plugins
and, funnily enough, the documentation. As you'll have seen on this
list recently, John has been putting a lot of topics together for
discussion and they come up from time to time and get recorded. At
some point in the near future we'll have a roadmap for 2.1 out.
A lot of plugins still are attached to beta APIs even when there
are 2 or
more released versions of the artifact available.
Specific examples? I don't see this in any plugins that aren't
themselves beta plugins.
For each milestone
release all code should be compiled with the latest as the rule
rather than
the exception.
I'm not really sure what this achieves for the end user, and whether
you are talking about just maven, or all its plugins too. I assume
you are referring to us learning from Callisto here, which I've
already ranted about on my blog, but I'd be interested to hear from
someone who is closer to that community that knows the tangible
benefits it brough.
The plan will let the community know what's coming and when
we can expect every milestone build between now and the release.
The plan
is not static as you can updated whenever you want.
Yes, that's a good idea.
2.) Produce nightly and weekly integration builds.
We already do. We could do it better. I've brought this topic up a
couple of times on the Continuum list.
Maybe this is
happening, but how would I know? Both the Maven 2 and Continuum
websites
have a dead link to the Continuous Integration server,
http://maven.zones.apache.org:8080/continuum.<http://
maven.zones.apache.org:8080/continuum>
This seems to be the problem. Our nightly builds are produced from an
old system that we were intending to move to Continuum so hadn't
published links to. On the Continuum side, we had to move the server
"temporarily" due to resource constraints and the links haven't been
updated yet. Please file an issue for these.
3. Update the website regularly.
Just split the thing down the middle into released info (doc,
tutorials,
examples, etc) and development current info which at a minimum
would be the
last stable milestone.
There's been significant discussion on this on the list already which
I can give you pointers to if you need them, but I'm not rehashing
them again. I'm happy with the plan we have.
Unfortunately, when people have put forward proposals recently
they've been met with silence. We need more participation to get this
moving.
However, could it
not be more efficient to release them in mass, especially if they
have been
continuously updated to current API's/fixes.
Our experience is the opposite. We did this in Maven 1 and plugin
releases were always stuck behind a core release. It takes a lot more
effort to release every plugin at once.
The APIs are not a moving target. I like that we can push out a
single plugin when it has fixes, and that old plugins continue to
work with new releases of Maven.
On the other hand, it means we need a greater eye over everything to
make sure plugins do get released regularly. This needs work.
Now I don't get to bitch, hit send and walk away, so what areas of the
website/documentation are available for a person who has some free
time.
I'm hesitant to signup for something big due to day job and night time
commitments, but I do have some time and I'd like guidance on what
areas I
can invest it with respect to making maven better. I just want the
pain to
stop. Maven's a great tool and we receive a lot of benefits from
its use.
However, we likely could do more, faster if some serious sharp
edges were
child proofed.
I'm happy to guide you into any area where you are interested to help
out. So, is it documentation that you want to help with? We have a
list of outstanding tasks which I can put in one place.
Or would you like to help pull together the roadmap for external
consumption?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
