[RANT] Maven is both heaven and hell

[Wendell]

I primarily deal with 2 open source organizations, Apache and Eclipse.  To a
lesser degree, I also interact with tigris.org for subversion and subclipse,
springframework.org for more and more each week it seems and a few other
".org" organizations.  I like to think I grok open source software and how
the communities functions.  I know no one owes me anything and that if I
find a bug or realize a good enhancement then its part of my community
commitment to create a reproducible bug report or even better a well thought
out patch to the current code.  In the long run, this will benefit me as
well as others, leading to a win-win for everyone involved.  To a large
extent the ASF helped start the open source community gig.  You're like
original band members, but it hurts to say that you all are getting your
asses handed to you by orgs like Spring and Eclipse.  There just doing a far
better job on the dcomentation and website.  This all my opinion, with the
collective opinions of a few others thrown in, but the truth is that it is
becoming flat out painful to deal with some ASF projects, Log4j and Maven in
particular.  Log4j has been circle jerking on how to releae the 1.3 version
of the code and maintain backwards compatibility.  It may be impractical to
impossible to do so, then rev the version to 2.0, jump to java 5 as a
minimum and completely do away with backwards compatibility.  But that's a
logging project issue now a maven one.  To paraphrase, the problem with
Maven is that there are "lies, damn lies and the maven documentation".

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>

That doesn't look right because most maven plugins are in the "
org.apache.maven.plugins" groupId.  You decide to follow the source repo
link and it takes you to the maven-dependency-plugin project.  Looking at
the project's pom confirms that the groupId is "org.apache.maven.plugins"
and that the artifactId is really "maven-dependency-plugin".  Well we solved
that, let's try and use it.  Unfortunately it is not available from any repo
I currently know of.  Damn this is inconvenient, but we'll just have to
build it from source.  Oh, wait after checking the project out it won't
build because it requires an unreleased
org.apache.maven.plugins:maven-plugins:pom:2-SNAPSHOT, SON OF A #!@!$!! I
just about wanted to bloody slot myself to stop the pain.

Now some things that I think would improve things is the adoption of some of
the things that I think make the Eclipse Foundation great.

1.) Publish a project plan and commit to periodic milestones.
A lot of plugins still are attached to beta APIs even when there are 2 or
more released versions of the artifact available.  For each milestone
release all code should be compiled with the latest as the rule rather than
the exception.  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.

2.) Produce nightly and weekly integration builds.
For eclipse, devs have to move up to integration builds and if the builds
fail then work is done to fix and verify before moving on. It should be
simple for us (the community) to download a build at anytime from a standard
location.  We should also be able to view a report on the tests so that we
can detrmine if it is worth our time to pick it up or not.  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>

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.

I realize that there my be bylaw rules, etc. differences between the ASF and
EF.  Take voting for example.  I'm on the mailing list and there are votes
called for this plugin and that one from time to time.  However, could it
not be more efficient to release them in mass, especially if they have been
continuously updated to current API's/fixes.  Just call for a vote now that
in  weeks time we will release all core maven plugins for Maven 2.1 M3.
This has 2 immediate effects, 1.) the community knows exactly  (give or take
a day or two for last minute issues)  when the next milestone is and 2.)
other maven community plugin devs can plan their releases to sync with
yours.

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.


Wb

[Graham Leggett]

Wendell Beckwith wrote:

 > You're like
> original band members, but it hurts to say that you all are getting your
> asses handed to you by orgs like Spring and Eclipse.  There just doing a
> far
> better job on the dcomentation and website.

Having used maven1 for a long time (and having been blown away by the
concept of a build system that "already knew how to do stuff in a
mutually agreed way", replacing "yet another half written custom ant
script"), I decided that it was time to sell the current project team on
the idea of maven2.

The conclusion of the attempt to use maven2 is that it is simply not
finished yet. Some features taken for granted in maven1 are
missing/incomplete, and the documentation is missing/incomplete.

I think the maven2 project is showing signs of the second system effect
- maven1 was carefully and thoughtfully constructed, documentation
carefully and thoughtfully created. And - it helped that maven1 was
largely complete before people discovered the concept of an intelligent
build system.

maven2 seems to have been built with enthusiasm - but crucial elements
(like key maven1 features, and documentation) have not been completed.

Luckily, there is no evidence of the second system effect in the design
of maven2 (IMHO of course), the problems are in the finish of the
software, meaning that fixing this means altering the focus from new
features to finishing existing ones, and completing the documentation
(as opposed to revisiting a design, or rewriting code).

The reason this is important is this:

maven1 was a complete no brainer to sell to projects. Once I had shown
people that there was no need to construct ant scripts to do everyday
tasks, maven1 "just knew" how to do things, and this was a huge win,
case closed.

On the particular project I am on now, maven1 was considered and
rejected for not supporting transitive dependencies (fair enough) so
they cooked up their own half working ant scripts, using ivy to handle
dependencies. maven2 does support transitive dependencies, so in theory
it should have been a no brainer sell, as before. But in reality my
testing the waters has uncovered a miriad of problems, leading us to
suggest that maven2 initially just be used to generate documentation
(mvn site).

I agree with comments that the documentation needs urgent work, and I as
a new user of maven2, have been trying to add what I consider missing
information from a new user point of view to JIRA (ie, what information
would have helped me use maven2, that was missing or incomplete).

If users could channel issues causing them frustration with the docs
into concise JIRA reports "I am trying to perform task X but the docs
don't tell me how" (which needs to be done at the time, because after
you finally figured out the problem, suddenly that JIRA report doesn't
seem so urgent any more), it will go a long way to indicate to
developers where there are gaps that need filling.

Regards,
Graham
--

[Jason Dillon]

I'm curious... what "key maven1 features" are you referring to that  
have not been completed in maven2?

--jason


On Aug 27, 2006, at 2:52 PM, Graham Leggett wrote:

> Wendell Beckwith wrote:
>
> > You're like
>> original band members, but it hurts to say that you all are  
>> getting your
>> asses handed to you by orgs like Spring and Eclipse.  There just  
>> doing a far
>> better job on the dcomentation and website.
>
> Having used maven1 for a long time (and having been blown away by  
> the concept of a build system that "already knew how to do stuff in  
> a mutually agreed way", replacing "yet another half written custom  
> ant script"), I decided that it was time to sell the current  
> project team on the idea of maven2.
>
> The conclusion of the attempt to use maven2 is that it is simply  
> not finished yet. Some features taken for granted in maven1 are  
> missing/incomplete, and the documentation is missing/incomplete.
>
> I think the maven2 project is showing signs of the second system  
> effect - maven1 was carefully and thoughtfully constructed,  
> documentation carefully and thoughtfully created. And - it helped  
> that maven1 was largely complete before people discovered the  
> concept of an intelligent build system.
>
> maven2 seems to have been built with enthusiasm - but crucial  
> elements (like key maven1 features, and documentation) have not  
> been completed.
>
> Luckily, there is no evidence of the second system effect in the  
> design of maven2 (IMHO of course), the problems are in the finish  
> of the software, meaning that fixing this means altering the focus  
> from new features to finishing existing ones, and completing the  
> documentation (as opposed to revisiting a design, or rewriting code).
>
> The reason this is important is this:
>
> maven1 was a complete no brainer to sell to projects. Once I had  
> shown people that there was no need to construct ant scripts to do  
> everyday tasks, maven1 "just knew" how to do things, and this was a  
> huge win, case closed.
>
> On the particular project I am on now, maven1 was considered and  
> rejected for not supporting transitive dependencies (fair enough)  
> so they cooked up their own half working ant scripts, using ivy to  
> handle dependencies. maven2 does support transitive dependencies,  
> so in theory it should have been a no brainer sell, as before. But  
> in reality my testing the waters has uncovered a miriad of  
> problems, leading us to suggest that maven2 initially just be used  
> to generate documentation (mvn site).
>
> I agree with comments that the documentation needs urgent work, and  
> I as a new user of maven2, have been trying to add what I consider  
> missing information from a new user point of view to JIRA (ie, what  
> information would have helped me use maven2, that was missing or  
> incomplete).
>
> If users could channel issues causing them frustration with the  
> docs into concise JIRA reports "I am trying to perform task X but  
> the docs don't tell me how" (which needs to be done at the time,  
> because after you finally figured out the problem, suddenly that  
> JIRA report doesn't seem so urgent any more), it will go a long way  
> to indicate to developers where there are gaps that need filling.
>
> Regards,
> Graham
> --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Graham Leggett]

Jason Dillon wrote:

> I'm curious... what "key maven1 features" are you referring to that have
> not been completed in maven2?

Some specific ones that bit us were the inability to embed dependencies
into EJBs, and the EAR plugin's inability to handle Jboss specific
artifacts, like HAR files. We also had problems with the VSS SCM plugin,
which is present, but doesn't work. These are specific examples that
spring to mind, there were others as well.

Regards,
Graham
--

[brettporter]

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

[Wendell]

Sorry, I did walk away there for a little bit.

On 8/27/06, Brett Porter <brett@... > wrote:

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

Done. http://jira.codehaus.org/browse/MDEP-34

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

I suppose this depends on where you draw the line between maven core
(whatever that is) and its plugins.  In all honesty I don't know where that
line lies. So some of what I see may be related to the plugins and not maven
itsself.  At present I can't think of where I saw a maven plugin using a
beta api but I do remember that while tracking something done in the repo I
noticed that there were 2 full versions ( x.0 and x.0.1) already available
and that the code was calling for an 2.0-beta version.  I recently wiped and
rebuild my local repo, and ran a search across all poms in the
org.apache.maven group and didn't turn up anything, so perhaps it's all
better now.  Until I can produce some reliable evidence I would mark this as
unreproducible.

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


For my team, I have been using, with minor adaptations, the eclipse dev
process and in general I think it has the right amount of "agility".  We
post our plan early with our commited, proposed, deferred and rejected items
for the next release and we revise it through out the release process.  We
use confluence for posting so that people interested in it can subscribe
just to that page to cut down on unwanted emails.  Therefore, when we make
updated everyone who wants to be notified is notified and they can either
comment on the issues we have attached to each plan item or start a forum
discussion.  I've create a template that maybe of use to you all if you
wanted to go this way.

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


I'm not on that list but I guess I will have to be to get a better picture
of what's going on.

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

Done. http://jira.codehaus.org/browse/MNG-2535

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

I'm not asking that you abandon releases when you think there is merit or
for critical fixes.  Instead I'm suggesting that you publish ahead of time
that you are going to roll a milestone/release at a certain periodic time in
the future.  For the most part, no one on any eclipse list requests a
build/release because we (community and devs) know from reviewing the plan
when they will be.  Because the community knows, the community waits.
Because the devs know the community is going to pounce on the milestone like
the slowest Zebra ,they work to get it in shape slightyl ahead of time.  In
no way should this prevent you from release maven-foo-plugin between
milestones/releases.

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?

I'm open to working with either or both.  I do believe that production of
the roadmap can help guide how to prioritize what documentation will be
needed and when though.

- Brett
>

Wb

[franz see]

Good day,

About a couple of months ago, the documentation site of the maven 2
plugins have been revised [1]. Though most have already been reviewed,
they are still not yet out for release.

However, now that the documentation issue have been raised again, I am
wondering of how we are going to go about this? Are new documentation
issues be applied to

(a) the current documentation in the maven site,
(b) the latest documentation though they're not yet released,
(c) both a & b, or
(d) ?

Thanks,
Franz

[1] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 30/08/2006, at 6:10 AM, Wendell Beckwith wrote:

> For my team, I have been using, with minor adaptations, the eclipse  
> dev
> process and in general I think it has the right amount of  
> "agility".  We
> post our plan early with our commited, proposed, deferred and  
> rejected items
> for the next release and we revise it through out the release  
> process.  We
> use confluence for posting so that people interested in it can  
> subscribe
> just to that page to cut down on unwanted emails.  Therefore, when  
> we make
> updated everyone who wants to be notified is notified and they can  
> either
> comment on the issues we have attached to each plan item or start a  
> forum
> discussion.  I've create a template that maybe of use to you all if  
> you
> wanted to go this way.

We use the JIRA roadmap. I'd be surprised if this is far different  
from what you are doing, with the exception that:
- we are currently stalled. There is no trunk activity because our  
focus is elsewhere (if anyone has time to pick things up and run with  
them, great! No need to wait for the rest of us :)
- we only really start putting dates to things once there is some  
momentum, and that's when the feature cull happens and it gets  
constantly reviewed to try and get things happening regularly.

But I'm not adverse to having more visible documentation of what we  
have to do and when we think we might be able to do it. It will help  
getting people focused on things, and introduce a way in for  
contributors.

>
>>
>> > 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.
>
>
> I'm not on that list but I guess I will have to be to get a better  
> picture
> of what's going on.

I expect this to become much more prevalent soon as Continuum is  
getting the features we need to support it.

>>
>> 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?
>
>
> I'm open to working with either or both.  I do believe that  
> production of
> the roadmap can help guide how to prioritize what documentation  
> will be
> needed and when though.

Ok, how can we help get you started?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

Yes, there are some open tasks (That I forwarded to the dev list last  
week) to start stitching things together. Once this is done we should  
do a big push of all the plugin documentation.

Any fixes that are made now should go on the plugin trunk - there's  
no other place for it, the stuff on the website is just what it was  
at for the last release.

- Brett

On 30/08/2006, at 11:46 AM, Franz Allan Valencia See wrote:

> Good day,
>
> About a couple of months ago, the documentation site of the maven 2
> plugins have been revised [1]. Though most have already been reviewed,
> they are still not yet out for release.
>
> However, now that the documentation issue have been raised again, I am
> wondering of how we are going to go about this? Are new documentation
> issues be applied to
>
> (a) the current documentation in the maven site,
> (b) the latest documentation though they're not yet released,
> (c) both a & b, or
> (d) ?
>
> Thanks,
> Franz
>
> [1] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wendell]

On 9/4/06, Brett Porter <brett@...> wrote:

>
>
> On 30/08/2006, at 6:10 AM, Wendell Beckwith wrote:
> > For my team, I have been using, with minor adaptations, the eclipse
> > dev
> > process and in general I think it has the right amount of
> > "agility".  We
> > post our plan early with our commited, proposed, deferred and
> > rejected items
> > for the next release and we revise it through out the release
> > process.  We
> > use confluence for posting so that people interested in it can
> > subscribe
> > just to that page to cut down on unwanted emails.  Therefore, when
> > we make
> > updated everyone who wants to be notified is notified and they can
> > either
> > comment on the issues we have attached to each plan item or start a
> > forum
> > discussion.  I've create a template that maybe of use to you all if
> > you
> > wanted to go this way.
>
> We use the JIRA roadmap. I'd be surprised if this is far different
> from what you are doing, with the exception that:
> - we are currently stalled. There is no trunk activity because our
> focus is elsewhere (if anyone has time to pick things up and run with
> them, great! No need to wait for the rest of us :)
> - we only really start putting dates to things once there is some
> momentum, and that's when the feature cull happens and it gets
> constantly reviewed to try and get things happening regularly.
>
> But I'm not adverse to having more visible documentation of what we
> have to do and when we think we might be able to do it. It will help
> getting people focused on things, and introduce a way in for
> contributors.

We use Jira too.  It's actually because I use Jira from so many open source
projects that  I introduced Jira into my  own  company and it caught on
like wildfire.   That's a surprising admission sense I never would have
thought of maven development as being stalled.  Thank goodness Google gives
me a couple gigs for email otherwise I would have to dump email every other
day it seems.  I just looked at the roadmap and there are 578 issues
combined between maven 2.0.5 and 2.1, approx. 41.2 issues per listed dev
assignee.  For 2 releases that's not an insane #.  So from your standpoint
we should just checkout the trunk and go to town submitting patches?

>
> >>
> >> > 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.
> >
> >
> > I'm not on that list but I guess I will have to be to get a better
> > picture
> > of what's going on.
>
> I expect this to become much more prevalent soon as Continuum is
> getting the features we need to support it.

Yes, I understand .  We're watching Continuum's development too because we
would like to use it once it's feature set is improved.  We currently have
Anthill Pro, but http://www.zutubi.com/ Pulse looks to be a good contender
also since I only care about subv repos now.

>>
> >> 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?
> >
> >
> > I'm open to working with either or both.  I do believe that
> > production of
> > the roadmap can help guide how to prioritize what documentation
> > will be
> > needed and when though.
>
> Ok, how can we help get you started?

I was really spinning my wheels last week, but I've gotten past that now and
opened the Jira issues.  However, if I just blow off  the docs now, then I'm
repeating history.  So, I'll  start submitting patches for issues that are
all ready in  Jira.  It can  help me get better acclimated to how you all
function.

- Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Jeff Jensen]

(Since you didn't mention it) CruiseControl works really well for us, if you
need something now.


-----Original Message-----
From: Wendell Beckwith [mailto:wbeckwith@...]
Sent: Monday, September 04, 2006 11:41 AM
To: Maven Developers List
Subject: Re: [RANT] Maven is both heaven and hell

[snip]

> >> > 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.
> >
> >
> > I'm not on that list but I guess I will have to be to get a better
> > picture of what's going on.
>
> I expect this to become much more prevalent soon as Continuum is
> getting the features we need to support it.

Yes, I understand .  We're watching Continuum's development too because we
would like to use it once it's feature set is improved.  We currently have
Anthill Pro, but http://www.zutubi.com/ Pulse looks to be a good contender
also since I only care about subv repos now.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 05/09/2006, at 2:41 AM, Wendell Beckwith wrote:
> That's a surprising admission sense I never would have
> thought of maven development as being stalled.  Thank goodness  
> Google gives
> me a couple gigs for email otherwise I would have to dump email  
> every other
> day it seems.

Well, the project is certainly moving along, but the work on the core  
itself has been pushed down the list a little while we sorted out a  
plan for documentation and getting some more stability from the plugins.

> I just looked at the roadmap and there are 578 issues
> combined between maven 2.0.5 and 2.1, approx. 41.2 issues per  
> listed dev
> assignee.  For 2 releases that's not an insane #.  So from your  
> standpoint
> we should just checkout the trunk and go to town submitting patches?

Sure! Just keep in touch with the list about what you are working on  
it and ping us for feedback regularly. If there are eyeballs on it,  
patches can get applied faster.

An important thing, even if it slows down the rate of progress, is to  
improve the tests and docs along with each piece of work. It's  
something we are definitely going to have to attend to as we pick up  
work on it.

> I was really spinning my wheels last week, but I've gotten past  
> that now and
> opened the Jira issues.  However, if I just blow off  the docs now,  
> then I'm
> repeating history.  So, I'll  start submitting patches for issues  
> that are
> all ready in  Jira.  It can  help me get better acclimated to how  
> you all
> function.

Ok, great. Let us know if there's anything we can do to help you dive  
in, and thanks for doing so!

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

Another thing I would like to see fixed is the snapshot apache
repository. Nighlty builds are still deployed using a unique version
identifier. This feature doesn't work and this is why a lot of people
have trouble when it's come to snapshot dependencies. It should be
written very big somewhere on the web site because it was THE major
source of bugs in my case and from what I have seen on the users list,
I am not the only one. At the moment, I think it is one of the major
pain of using Maven. It took me more than a day to figure out why
those snapshot dependencies weren't downloaded (my internal repository
was set up the same way). I found out the solution in the users
mailing list but a lot of people would have given up before I did if
tehy were just trying out Maven to see how it compares to Ant.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 18/09/2006, at 12:40 AM, Alexandre Poitras wrote:

> Another thing I would like to see fixed is the snapshot apache
> repository. Nighlty builds are still deployed using a unique version
> identifier. This feature doesn't work and this is why a lot of people
> have trouble when it's come to snapshot dependencies.

Can you explain what the problem was? Saying "this feature doesn't  
work" is way too broad - it may have problems, but it obviously does  
work in many circumstances (as we're using it for all the projects  
here).

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wendy Smoak-3]

On 9/17/06, Alexandre Poitras <alexandre.poitras@...> wrote:

> Another thing I would like to see fixed is the snapshot apache
> repository. Nighlty builds are still deployed using a unique version
> identifier. This feature doesn't work and this is why a lot of people
> have trouble when it's come to snapshot dependencies.

Do you mean *without* a unique version identifier here?

This is the 'Maven 2.0.4 will not download a x.x-SNAPSHOT.jar if one
is already present in the local repository' problem, correct?

It would be nice if it would deploy both a uniquely named version
_and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with have
uniqueVersion set to false for that reason.

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

I think this is the issue I was referring too. I just know that I
can't use a snapshot dependency that has a timestamp in its filename
or I won't get the last version. I remember Brett couple of months ago
saying this feature wasn't implemented yet. I'll try to find the JIRA
issue.

This is definitely a showstopper when you don't know about it.

On 9/17/06, Wendy Smoak <wsmoak@...> wrote:

> On 9/17/06, Alexandre Poitras <alexandre.poitras@...> wrote:
>
> > Another thing I would like to see fixed is the snapshot apache
> > repository. Nighlty builds are still deployed using a unique version
> > identifier. This feature doesn't work and this is why a lot of people
> > have trouble when it's come to snapshot dependencies.
>
> Do you mean *without* a unique version identifier here?
>
> This is the 'Maven 2.0.4 will not download a x.x-SNAPSHOT.jar if one
> is already present in the local repository' problem, correct?
>
> It would be nice if it would deploy both a uniquely named version
> _and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with have
> uniqueVersion set to false for that reason.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

Here's the issue I am speaking about :
http://jira.codehaus.org/browse/MNG-2289

On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:

> I think this is the issue I was referring too. I just know that I
> can't use a snapshot dependency that has a timestamp in its filename
> or I won't get the last version. I remember Brett couple of months ago
> saying this feature wasn't implemented yet. I'll try to find the JIRA
> issue.
>
> This is definitely a showstopper when you don't know about it.
>
> On 9/17/06, Wendy Smoak <wsmoak@...> wrote:
> > On 9/17/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> >
> > > Another thing I would like to see fixed is the snapshot apache
> > > repository. Nighlty builds are still deployed using a unique version
> > > identifier. This feature doesn't work and this is why a lot of people
> > > have trouble when it's come to snapshot dependencies.
> >
> > Do you mean *without* a unique version identifier here?
> >
> > This is the 'Maven 2.0.4 will not download a x.x-SNAPSHOT.jar if one
> > is already present in the local repository' problem, correct?
> >
> > It would be nice if it would deploy both a uniquely named version
> > _and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with have
> > uniqueVersion set to false for that reason.
> >
> > --
> > Wendy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

Oops wrong one, forget the last email.

On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:

> Here's the issue I am speaking about :
> http://jira.codehaus.org/browse/MNG-2289
>
> On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> > I think this is the issue I was referring too. I just know that I
> > can't use a snapshot dependency that has a timestamp in its filename
> > or I won't get the last version. I remember Brett couple of months ago
> > saying this feature wasn't implemented yet. I'll try to find the JIRA
> > issue.
> >
> > This is definitely a showstopper when you don't know about it.
> >
> > On 9/17/06, Wendy Smoak <wsmoak@...> wrote:
> > > On 9/17/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> > >
> > > > Another thing I would like to see fixed is the snapshot apache
> > > > repository. Nighlty builds are still deployed using a unique version
> > > > identifier. This feature doesn't work and this is why a lot of people
> > > > have trouble when it's come to snapshot dependencies.
> > >
> > > Do you mean *without* a unique version identifier here?
> > >
> > > This is the 'Maven 2.0.4 will not download a x.x-SNAPSHOT.jar if one
> > > is already present in the local repository' problem, correct?
> > >
> > > It would be nice if it would deploy both a uniquely named version
> > > _and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with have
> > > uniqueVersion set to false for that reason.
> > >
> > > --
> > > Wendy
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

That's the real one :
http://jira.codehaus.org/browse/MNG-1908

On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:

> Oops wrong one, forget the last email.
>
> On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> > Here's the issue I am speaking about :
> > http://jira.codehaus.org/browse/MNG-2289
> >
> > On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> > > I think this is the issue I was referring too. I just know that I
> > > can't use a snapshot dependency that has a timestamp in its filename
> > > or I won't get the last version. I remember Brett couple of months ago
> > > saying this feature wasn't implemented yet. I'll try to find the JIRA
> > > issue.
> > >
> > > This is definitely a showstopper when you don't know about it.
> > >
> > > On 9/17/06, Wendy Smoak <wsmoak@...> wrote:
> > > > On 9/17/06, Alexandre Poitras <alexandre.poitras@...> wrote:
> > > >
> > > > > Another thing I would like to see fixed is the snapshot apache
> > > > > repository. Nighlty builds are still deployed using a unique version
> > > > > identifier. This feature doesn't work and this is why a lot of people
> > > > > have trouble when it's come to snapshot dependencies.
> > > >
> > > > Do you mean *without* a unique version identifier here?
> > > >
> > > > This is the 'Maven 2.0.4 will not download a x.x-SNAPSHOT.jar if one
> > > > is already present in the local repository' problem, correct?
> > > >
> > > > It would be nice if it would deploy both a uniquely named version
> > > > _and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with have
> > > > uniqueVersion set to false for that reason.
> > > >
> > > > --
> > > > Wendy
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > > For additional commands, e-mail: dev-help@...
> > > >
> > > >
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

That's the opposite to what you keep saying. It's when you *don't*  
have a timestamp in the version number.

I could have sworn John fixed this recently, though...

On 19/09/2006, at 1:16 AM, Alexandre Poitras wrote:

> That's the real one :
> http://jira.codehaus.org/browse/MNG-1908
>
> On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
>> Oops wrong one, forget the last email.
>>
>> On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
>> > Here's the issue I am speaking about :
>> > http://jira.codehaus.org/browse/MNG-2289
>> >
>> > On 9/18/06, Alexandre Poitras <alexandre.poitras@...> wrote:
>> > > I think this is the issue I was referring too. I just know that I
>> > > can't use a snapshot dependency that has a timestamp in its  
>> filename
>> > > or I won't get the last version. I remember Brett couple of  
>> months ago
>> > > saying this feature wasn't implemented yet. I'll try to find  
>> the JIRA
>> > > issue.
>> > >
>> > > This is definitely a showstopper when you don't know about it.
>> > >
>> > > On 9/17/06, Wendy Smoak <wsmoak@...> wrote:
>> > > > On 9/17/06, Alexandre Poitras <alexandre.poitras@...>  
>> wrote:
>> > > >
>> > > > > Another thing I would like to see fixed is the snapshot  
>> apache
>> > > > > repository. Nighlty builds are still deployed using a  
>> unique version
>> > > > > identifier. This feature doesn't work and this is why a  
>> lot of people
>> > > > > have trouble when it's come to snapshot dependencies.
>> > > >
>> > > > Do you mean *without* a unique version identifier here?
>> > > >
>> > > > This is the 'Maven 2.0.4 will not download a x.x-
>> SNAPSHOT.jar if one
>> > > > is already present in the local repository' problem, correct?
>> > > >
>> > > > It would be nice if it would deploy both a uniquely named  
>> version
>> > > > _and_ the x.x.x-SNAPSHOT.jar. The projects I'm involved with  
>> have
>> > > > uniqueVersion set to false for that reason.
>> > > >
>> > > > --
>> > > > Wendy
>> > > >
>> > > >  
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@...
>> > > > For additional commands, e-mail: dev-help@...
>> > > >
>> > > >
>> > >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...