Re: [RANT] Maven is both heaven and hell
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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Here's the issue I am speaking about : http://jira.codehaus.org/browse/MNG-2289 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Oops wrong one, forget the last email. On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Here's the issue I am speaking about : http://jira.codehaus.org/browse/MNG-2289 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
That's the real one : http://jira.codehaus.org/browse/MNG-1908 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Oops wrong one, forget the last email. On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Here's the issue I am speaking about : http://jira.codehaus.org/browse/MNG-2289 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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 [EMAIL PROTECTED] wrote: Oops wrong one, forget the last email. On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Here's the issue I am speaking about : http://jira.codehaus.org/browse/MNG-2289 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Oh sorry I was sure it was when you have a timestamp in your filename. Maybe I should test it again. Anyway, I just think there should a big note on the web site about this issue somewhere until the new version is released because it's really confusing at first. I spent a lot of time figuring out why Maven wasn't downloading the newer snapshots. On 9/18/06, Brett Porter [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] wrote: Oops wrong one, forget the last email. On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Here's the issue I am speaking about : http://jira.codehaus.org/browse/MNG-2289 On 9/18/06, Alexandre Poitras [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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. Did you set up the repo as a snapshotsenabled/snapshots one? On 9/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Yup it works now but I remember it took me a lot of time to make it happen. On 9/18/06, David J. M. Karlsen [EMAIL PROTECTED] wrote: 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. Did you set up the repo as a snapshotsenabled/snapshots one? On 9/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
On 9/17/06, Alexandre Poitras [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
On 9/4/06, Brett Porter [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RANT] Maven is both heaven and hell
(Since you didn't mention it) CruiseControl works really well for us, if you need something now. -Original Message- From: Wendell Beckwith [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Sorry, I did walk away there for a little bit. On 8/27/06, Brett Porter [EMAIL PROTECTED] 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 groupIdorg.apache.maven.plugin/groupId artifactIddependency-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
Re: [RANT] Maven is both heaven and hell
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RANT] Maven is both heaven and hell
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 groupIdorg.apache.maven.plugin/groupId artifactIddependency-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 [EMAIL PROTECTED] 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
Re: [RANT] Maven is both heaven and hell
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 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [RANT] Maven is both heaven and hell
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
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 -- smime.p7s Description: S/MIME Cryptographic Signature
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 groupIdorg.apache.maven.plugin/groupId artifactIddependency-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]
