Re: [RANT] Maven is both heaven and hell

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.

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...