Re: Where did NMaven go?
NMaven has moved to http://www.codeplex.com/nmaven/ Thanks James On 06/03/2009, at 9:04 AM, Dennis Lundberg wrote: Hi We're trying to find the best version of NMaven to start to use at work. I didn't follow the discussions at the time, but it clear to me that NMaven didn't graduate from incubation. According to this page: http://incubator.apache.org/nmaven/ there seems to be three different alternatives. Can someone shed some light on which ones are alive and kicking? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: use Modello 1.0 in Maven 2.1.x
I upgraded Archiva trunk to Modello 1.0. We use it extensively for defining our database model and I've seen no problems with 1.0. James On 16/02/2009, at 10:46 AM, Brett Porter wrote: I'm fine with that, I'd say go ahead and merge the changes across. It's easy enough to roll back if there are any problems. - Brett On 16/02/2009, at 12:15 AM, Hervé BOUTEMY wrote: Maven 3.x recently upgraded Modello to 1.0 in r743174, and Benjamin used it to integrate generics in r744572 (thank you). With Modello 1.0, there are a lot of little improvements that can be done on models. Before doing so, I'd like to upgrade Modello version for 2.1.x branch: I'm pretty confident this won't cause any regression. Any objection? Or any preference on when to do it to avoid risks on Maven 2.1 release plan? Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Notes from Build Tools BOF at ApacheCon US 2008
On Fri, 2008-11-07 at 14:38 -0600, Wendy Smoak wrote: Surefire fills up /tmp with directories Cargo is notorious for doing this also. It downloads application servers to /tmp/cargo which means it suffers from race conditions with multiple processes starting app servers. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury status and roadmap
You might be able to knock up a quick one using Milton [1]. http://milton.ettrema.com/index.html Archiva also supports level 2 webdav - so you might be able to bring it up inside of cargo. Cheers James On Tue, 2008-11-11 at 20:40 -0600, Jesse McConnell wrote: aw yes...the world needs a good open source dav server thats easy to setup...I haven't ever found one :/ if anyone knows of one that is easy to deploy as a test case please chime in jesse -- jesse mcconnell [EMAIL PROTECTED] On Tue, Nov 11, 2008 at 8:37 PM, Oleg Gusakov [EMAIL PROTECTED]wrote: Jesse McConnell wrote: oleg, I used the codehaus dav to test against, it worked quite wellif you have a codehaus account you have a dav drive you can work with for it dav.codehaus.org/user/oleg I believe Jesse, I also tested against codehaus and mercury does work well. But I want test to be self-contained, so start server inside. Any external server can go out and fail otherwise healthy build. And having my name/password in the code is not too cool. So I use the only embeddable DAV-like server I know - Nexus. Thanks, Oleg - 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: Mercury wagon progress
Oleg, On Fri, 2008-10-03 at 08:41 -0700, Oleg Gusakov wrote: Yes - Mercury replaces a dav protocol wagon handler if this is the question. It does not claim to handle entire DAV protocol, including versioning, etc. It implements a subset that allows to PUT resources to the server: see http://www.mail-archive.com/dev@maven.apache.org/msg77266.html from Jesse. So Mercury transport handles two-way (PUT and GET) transactions over http and https. Very cool :) - Can't wait to try this out. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury wagon progress
Hey Oleg, Curious, will the Mecury wagon provider be the new handler for the dav: protocol extension? Cheers James On Thu, 2008-10-02 at 22:34 -0700, Oleg Gusakov wrote: I have been testing Mercury wagon provider with 2.2.x and 2.1.x branches and successfully pass all the ITs but one, please see the tracking comments in http://jira.codehaus.org/browse/MERCURY-8 and it's subtasks The missing test - it0031 - deals with plugin alias remapping, which happens well above wagon provider. Plus it also fails with the old providers in place, so I don't think it's an obstacle. I will stage Mercury wagon tomorrow and post notification on this list. I think it's ready for 2.1.0-M2 consumption. Thanks, Oleg - 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: WebDAV deploying bug with Maven 2.1.0-M1
I'm happy with that :) James On Fri, 2008-09-26 at 22:15 +0200, Jason van Zyl wrote: If we are just tossing in brand new technology into 2.1 I think we should just put Mercury into 2.1. It has a _lot_ of tests and is actively being worked on by 5 people in the community. It also covers all the PGP concerns people have and the WebDAV client is also built in. I'll bring this up on a separate thread. I've made branches for trunk and 2.2, but if we're going to be debugging and fixing things we might as well do it with what's going to be used in the future. On 26-Sep-08, at 2:12 AM, James William Dumay wrote: Sorry, that bug is my fault. Ill try to get this fixed for milestone 2. James On Thu, 2008-09-25 at 12:54 -0400, John Casey wrote: Ugh. I guess we knew this was a risk when we decided to go with wagon beta-4...it's a good thing this was just a milestone release, eh? :-) I posted a comment, but it's probably more procedural than anything, since many of the same people are involved between the wagon project and the deploy-plugin project... -john Mark Hobson wrote: Hi there, Thought I'd best highlight a regression I've found with 2.1.0-M1 after all the hard work John put in to mitigate them: http://jira.codehaus.org/browse/MDEPLOY-85 Cheers, Mark - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - 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: WebDAV deploying bug with Maven 2.1.0-M1
Sorry, that bug is my fault. Ill try to get this fixed for milestone 2. James On Thu, 2008-09-25 at 12:54 -0400, John Casey wrote: Ugh. I guess we knew this was a risk when we decided to go with wagon beta-4...it's a good thing this was just a milestone release, eh? :-) I posted a comment, but it's probably more procedural than anything, since many of the same people are involved between the wagon project and the deploy-plugin project... -john Mark Hobson wrote: Hi there, Thought I'd best highlight a regression I've found with 2.1.0-M1 after all the hard work John put in to mitigate them: http://jira.codehaus.org/browse/MDEPLOY-85 Cheers, Mark - 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: [vote] Release Maven 2.1.0-M1
I agree - I ran into this last night trying to test some internal tooling... James On Fri, 2008-09-19 at 10:19 +1000, Brett Porter wrote: On 19/09/2008, at 1:31 AM, John Casey wrote: What are you trying to accomplish? Maybe I can help you out more if I know that? I was just wondering if we were only voting on the release of the tarballs, or if we were voting on the stage repository contents as well. On 19/09/2008, at 1:30 AM, John Casey wrote: I've only been running 'mvn clean release:prepare release:perform', and using a staging location that separates artifacts by artifactId and version directories, to keep from messing up the stage:copy plugin eventually. So, no, I don't think that will produce a staging repository where all of the artifacts are together, though it will produce a _series_ of staged repositories of the form: http://people.apache.org/~jdcasey/stage/artifact-id/2.1.0-M1/ where each one contains that single artifact. If we're to vote on it, I'd prefer they be kept in one repository in future (just delete it each time). This allows easy testing by adding it as a remote repo and building projects that use the Maven libraries. Thanks, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: [PLEASE TEST] Maven 2.1.0-M1-RC17
John, Looking great over here - I've been able to build a few of Atlassian's larger maven projects without any headache. James On Wed, 2008-09-10 at 17:34 +0100, Mauro Talevi wrote: John, no problems encountered. Great work! John Casey wrote: Hi, I've fixed MNG-3748, where illegal elements in the settings.xml were not triggering build failure. Anyway, this release candidate includes a fix for that issue: http://people.apache.org/~jdcasey/stage/current-maven-RC/ Enjoy, and let me know if you have problems. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - 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: Wagon problems, maybe somebody has answers?
Hey Oleg, On Thu, 2008-09-04 at 14:00 -0700, Oleg Gusakov wrote: I tried to create mercury-based wagon provider and got overwhelmed with Wagon's strange architecture decisions and APIs. First of all - inheriting from AbstractWagon and implementing required methods took 20 min - excellent! The rest two days (are still being) spent trying to understand: - wagon-tests - I assume it's integration tests every provider has to pass? - why do tests requite provider to fire events, especially TRANSFER event? What happens when provider has much higher up APIs and does not control the transfer process? What if provider does not want to share events - why mandate them by the tests ?? Because these are used to track download progress - if you are using a Stream based protocol then the StreamWagon abstract class will take care of this for you. What protocol are you trying to implement? - why tests rely on the Resource object, while it's not manipulated anywhere in the APIs? Necessity to create on per each put or get represents an object leak for me. Especially highly artificial sequence of populating this object with data - set content length before Initiated event and tests fail. - what is the exact combination of Resource manipulation in the get operation? I tried several and am still missing what should be filled in when: resource (local file, I assume?) is empty when firing getInitialized(), but tests fail, saying they expected resource with a content length and timestamp. ... any help is greatly appreciated! - where did getFileList() come from?? HTTP provider, for example, cannot do it without scrapping a page, and if repository has different indexing formats/options - it will not work. And tests fail I don't implement one. After all - this is why maven-metadata.xml exists! I've never been a fan of the scraping myself either - thats one of the reasons I recommend webdav. - where did resourceExists() come from? In HTTP provider it is not possible without a try-and-fail cycle, which slows everything down - bad choice. This is why maven-metadata.xml exists! - why such fascination with getIfNewer() in the APIs? This notion is external to a dumb http server and the suggested unix-like timestamp may yield wrong results by as much as 24 hours, depending on the server and client locations. This is why we use UTC timestamps in the metadata files .. and that is why metadata files exist :) Oleg - HTTP 1.1 RFC2616 Section 3.3.1 specifies that the HTTP-Date type MUST be represented in GMT - so a servers last-modified header should reflect this. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 getIfNewer() is used to short circuit the fetching of metadata files - if the file is reported older than the one you have locally then there is no need to download it. Overall impression is not too favorable. I am trying to jump the hoops in order to pass the tests. If somebody has any insights, please help! Maybe some write ups somewhere: how to satisfy wagon-provider-tests? One thing you will learn when working with Wagon is this: its not designed - it grew with Maven. Projects like Mercury (being used in trunk soon?) are going to simply this by having a rethink about what operations work best for accessing data from repositories. Until that eventuates we are stuck with Wagon. Cheers James Thanks, Oleg - 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: Wagon problems, maybe somebody has answers?
Hey Oleg, On Thu, 2008-09-04 at 18:11 -0700, Oleg Gusakov wrote: James - thanks a lot for the reply! No problems :) James William Dumay wrote: Because these are used to track download progress - if you are using a Stream based protocol then the StreamWagon abstract class will take care of this for you. My transport layer operates on files, so I cannot do streaming wagon without saving a stream into a file first - big inefficiency :( Thats a bit crappy - does mercury force you to work with Files instead of streams? Im always reminded of this blog post when it comes to those sorts of API's http://fishbowl.pastiche.org/2004/06/11/minipattern_the_file_stream_duality/ What protocol are you trying to implement? http/https/webdav - jetty folks were kind to help with multi-threaded client, so I hope to improve the speed characteristics. And learn wagon a little bit. Neat - the jetty folks have a nice client :) James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Central repository index
Jason, I'm cool sticking with the Nexus index format - it works and there has been a successful uptake with different tool vendors - so it seems to be the defacto standard. We will certainly be using it in a future version of Archiva. What I would like to see would be that the index code becomes part of the Maven project itself and be the index standard for Maven repositories. This is good for the simple reason that other repository projects will not have to play constant catchup with Nexus if that index format changes - changes to the format can be discussed and worked on with the Maven community. On another note, if any fundamental changes are made to Maven in the future it ensures that the index format can grow with those changes. Thoughts? Thanks, James On 28/08/2008, at 10:14 AM, Jason van Zyl wrote: On 27-Aug-08, at 4:58 PM, Wendy Smoak wrote: [moved from [EMAIL PROTECTED] On Wed, Aug 27, 2008 at 2:39 PM, Jason van Zyl [EMAIL PROTECTED] wrote: For any tool you see saying they support Nexus indexes make sure they are using our APIs. We guarantee nothing in the way of the format, but we have gone to excruciating lengths to make sure the API we have provided is super stable. Anything that tries to read the indices directly will ultimately get burned so just make sure you know how the tools you choose are producing a Nexus index. We can certainly protect the API, we can't really promise no format changes in the index format. Is this referring to the index files that live in the central repository [1] ? I think if we're going to provide an official index, it should be one that comes from the Maven project, not from any particular repository manager. It's integrated in m2e, Netbeans, IDEA, and a whole slew of open source organizations so I'm not sure how much more of a defacto standard in real life you're going to get. But, I agree and I'm not at all suggesting the Nexus index is the official index from Maven. I don't think we even need to say there is an official index. Happy to move into another directory, and anyone else can publish whatever indices they like. Let users choose what they want to use. [1] http://repo1.maven.org/maven2/.index/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - 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: Donation of Maven plugins to the Maven Project.
I didn't even see the commit until after my first reply (for some reason it appeared in my mailbox late), and I've had no discussion with James about this that you haven't seen. I was kind of surprised too, and I think it was just a miscommunication. I would like to apologise for the miscommunication - I will see that this is correctly sorted out. James I didn't even see the commit until after my first reply (for some reason it appeared in my mailbox late), and I've had no discussion with James about this that you haven't seen. I was kind of surprised too, and I think it was just a miscommunication. I would like to apologise for the miscommunication - I will see that this is correctly sorted out. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Donation of Maven plugins to the Maven Project.
Hey guys, Atlassian would like to donate two plugins to the Maven project: * maven-wagon-plugin (formerly maven-upload-plugin) - Allows you to upload and download resources during the build lifecycle and list remote resources. * maven-licenses-plugin - This plugin lists, downloads and packages license files for your projects transitive dependencies. Useful for creating assemblies that contain licenses. Both plugins are licensed under the Apache 2 license and have received recent attention of the mailing list which has prompted the idea of donation. We are happy to change the names of these plugins if there is anyone has better suggestions for their names. You can find both plugins on our svn: https://svn.atlassian.com/svn/public/atlassian/maven-plugins/ I'm sorting out the legal now with Atlassian. So, how can we get the ball rolling? :) Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Donation of Maven plugins to the Maven Project.
Brett, So this is resource based, instead of artifact based? If so, I think it makes sense as an addition to the wagon project. That's correct and I agree that it would make a good addition to Wagon. How does this differ from the remote-resources plugin? Could it be combined with that? Remote resources plugin simply bundles resources together as a different artifact to allow other builds to depend on the same set of resources. The licenses plugin on the other hand uses the license information specified in the pom to find, list, download and deploy licenses. The deploy goal is something that needs a little more thought. At the moment it allows you to download licenses found in a POM and deploy them as a classified license artifact to a specified repository for archiving. So I would say they are different enough not to warrant merging. I would suggest as a starting point you can put them in the Maven sandbox (or branch the remote resources plugin there and incorporate), if there is support for it here, since all Apache committers have access there. Awesome, Ill prepare and put both of these plugins into sandbox now. Thanks James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN checkout/update fails
Perhaps we could get a windows vm build? James On Tue, 2008-04-22 at 16:01 +1200, Rahul Thakur wrote: Hi, SVN update for maven-archiva fails on the XP. Joakim kindly looked at the SVN error log (attached below) and noted that the path exceeded the length imposed by Windows. Can we please review the modules/packages so people can continue checkouts on Windows? Thanks, Rahul snipped C:\oss\maven-archivasvn up svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'archiva-modules\archiva-base\archiva-repository-layer\src\test\repositories\metadata-repository\or g\apache\archiva\metadata\tests\snap_shots_a\1.0-alpha-11-SNAPSHOT\.svn\tmp\text-base\snap_shots_a-1.0-alpha-11-20070302 ..212723-3.war.svn-base': The system cannot find the path specified. /snipped
Re: Archiva Mailing list
Its coming - just waiting on apache infran :-) James On 19/04/2008, at 6:56 AM, Edwin Punzalan [EMAIL PROTECTED] wrote: When Continuum got to TLP, the mailing lists changed from [EMAIL PROTECTED] to [EMAIL PROTECTED] Any plans to upgrade archiva's too? Or is it a work in progress? ^_^
Re: browsing repository the Archiva way
Making these index pages is not difficult.
Marc, if this is something you want to work on please go ahead :)
James
On Thu, 2008-04-17 at 08:32 -0700, Wendy Smoak wrote:
On Thu, Apr 17, 2008 at 7:23 AM, Lustig, Marc (Allianz Deutschland AG)
[EMAIL PROTECTED] wrote:
The idea now is to implement a differentiation between file-requests and
directory-requests:
- file-requests should not be touched
- directory-requests should be redirected
from [app-url]/repository/[reponame]/{suffix}
to [app-url]/browse/{suffix}
The /browse/ url is a consolidated view of all the content. I'm not
opposed to making the directory listings prettier, but I still need to
be able to click around a _single_ repository with the
/repository/repo-id/ path.
Re: Tests broken on trunk
Err how did I stuff that up? On 15/04/2008, at 11:13 PM, James William Dumay wrote: Hey guys, Appears trunk's test are broken. Could someone have a look? Thanks James PS Run your tests :PHey guys, Appears trunk's test are broken. Could someone have a look? Thanks James PS Run your tests :P Err how did I stuff that up? On 15/04/2008, at 11:13 PM, James William Dumay wrote: Hey guys, Appears trunk's test are broken. Could someone have a look? Thanks James PS Run your tests :PHey guys, Appears trunk's test are broken. Could someone have a look? Thanks James PS Run your tests :P
Re: [Proposal] Replacing Archiva-webdav with Apache Jackrabbits WebDav Servlet
No CLA on file yet. Ill talk to Atlassian about signing one today. James On Tue, 2008-04-15 at 17:53 -0700, Joakim Erdfelt wrote: James William Dumay wrote: Hey all, I've opened MRM-781 which removes the plexus based archiva-webdav module in favour of a smaller implementation based on Apache Jackrabbits webdav servlet. This implementation is significantly smaller. This change will allow us to address MRM-684 without much complexity. Currently, HTTP GET and PUT work correctly but more work needs to be done on providing the correct Webdav resource properties needed for a full webdav implementation (not to mention a lot more unit tests). It would be excellent if I could get this into a branch soon as the change set is getting unwieldy. I would appreciate your thoughts and comments. Thanks James (I know this has been discussed in irc, just wanted to let everyone else know too) This seems like a pretty big patch/change, do you have a CLA on file at apache yet? - Joakim
Re: [Proposal] Replacing Archiva-webdav with Apache Jackrabbits WebDav Servlet
I've sent one off to the foundation. James On Wed, 2008-04-16 at 10:59 +1000, James William Dumay wrote: No CLA on file yet. Ill talk to Atlassian about signing one today. James On Tue, 2008-04-15 at 17:53 -0700, Joakim Erdfelt wrote: James William Dumay wrote: Hey all, I've opened MRM-781 which removes the plexus based archiva-webdav module in favour of a smaller implementation based on Apache Jackrabbits webdav servlet. This implementation is significantly smaller. This change will allow us to address MRM-684 without much complexity. Currently, HTTP GET and PUT work correctly but more work needs to be done on providing the correct Webdav resource properties needed for a full webdav implementation (not to mention a lot more unit tests). It would be excellent if I could get this into a branch soon as the change set is getting unwieldy. I would appreciate your thoughts and comments. Thanks James (I know this has been discussed in irc, just wanted to let everyone else know too) This seems like a pretty big patch/change, do you have a CLA on file at apache yet? - Joakim
Re: Java Service Wrappers unfortunate license change
I've also had to patch it once - if there is a fork of it I may also use or contribute. James On Mon, 2008-04-14 at 06:02 +1000, Brett Porter wrote: On 14/04/2008, at 12:20 AM, Jason van Zyl wrote: Anyone interested in forking it and maintaining the version that was not GPL? I'm continuing to use 3.2.3. I've had to patch it once [1], but I'm not sure how much I'll need to work on a fork of it since that version has been pretty stable. So if a fork arises I may contribute and use it. Cheers, Brett [1] http://svn.codehaus.org/mojo/trunk/mojo/appassembler/appassembler-maven-plugin/src/main/patches/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
2.0.9 Javadoc has not been published
Hey guys, Seems the 2.0.9 javadoc is not up - could we get this published? Any reason why this is not part of the release process? Cheers James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.9 Javadoc has not been published
The current symlink? James On 11/04/2008, at 2:51 PM, Jason van Zyl [EMAIL PROTECTED] wrote: Sure it has: http://repo1.maven.org/maven2/org/apache/maven/maven-core/2.0.9/ All the javadoc appears to have been deployed as per the normal process. Where are you looking? On 10-Apr-08, at 9:34 PM, James William Dumay wrote: Hey guys, Seems the 2.0.9 javadoc is not up - could we get this published? Any reason why this is not part of the release process? Cheers James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot 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: 2.0.9 Javadoc has not been published
http://maven.apache.org/ref/current/maven-core/apidocs/index.html this still shows the version as 2.0.8 On Fri, 2008-04-11 at 14:52 +1000, James William Dumay wrote: The current symlink? James On 11/04/2008, at 2:51 PM, Jason van Zyl [EMAIL PROTECTED] wrote: Sure it has: http://repo1.maven.org/maven2/org/apache/maven/maven-core/2.0.9/ All the javadoc appears to have been deployed as per the normal process. Where are you looking? On 10-Apr-08, at 9:34 PM, James William Dumay wrote: Hey guys, Seems the 2.0.9 javadoc is not up - could we get this published? Any reason why this is not part of the release process? Cheers James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.9 Javadoc has not been published
Thanks Jason On Thu, 2008-04-10 at 22:12 -0700, Jason van Zyl wrote: Sorry I always use the IDE so that's what I was thinking. The site should be corrected. On 10-Apr-08, at 9:52 PM, James William Dumay wrote: The current symlink? James On 11/04/2008, at 2:51 PM, Jason van Zyl [EMAIL PROTECTED] wrote: Sure it has: http://repo1.maven.org/maven2/org/apache/maven/maven-core/2.0.9/ All the javadoc appears to have been deployed as per the normal process. Where are you looking? On 10-Apr-08, at 9:34 PM, James William Dumay wrote: Hey guys, Seems the 2.0.9 javadoc is not up - could we get this published? Any reason why this is not part of the release process? Cheers James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - 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: [plexus work] archiva-checksums
Joakim, Is this based on any work from commons or have you implemented this stuff from whats provided in the JDK? James On Tue, 2008-04-08 at 21:54 -0700, Joakim Erdfelt wrote: Joakim Erdfelt wrote: I've been taking a stab and removing some of our dependencies on various plexus components. First up, plexus-digest. I've taken the varied code from many locations and come up with a stand alone archiva-checksum lib/component that I hope to be able to integrate into archiva/trunk. So ... uhm ... consider this a call for discussion. ;-) - Joakim Some more details... These are 4 classes present in archiva-checksum 1) org/apache/archiva/checksum/Hash.java 2) org/apache/archiva/checksum/Hasher.java 3) org/apache/archiva/checksum/Hex.java 4) org/apache/archiva/checksum/ChecksumFile.java This is how the replacements work ... Hash.class is an enum identifying the types of Hash functions (currently only SHA1 and MD5), with a few details on ids that the hash techniques expose. This is similar in scope, but not a 100% replacement for ... org/codehaus/plexus/digest/Sha1Digester.java org/codehaus/plexus/digest/Md5Digester.java org/codehaus/plexus/digest/StreamingSha1Digester.java Hasher.class is the main hashing routines, stream based, and has a few optimizations for performing bulk or group hashing based on a single stream, without processing the stream multiple times (one for each hash). Hasher.class replaces the following classes in plexus-digest org/codehaus/plexus/digest/Digester.java org/codehaus/plexus/digest/StreamingDigester.java Hex.class is just a simple utility class to convert a byte array to a Hex string. It is a suitable replacement for plexus-digest org/codehaus/plexus/digest/Hex.java ChecksumFile.class is the file specific implementation, for dealing with the .md5 and .sha1 files (parsing, validating, creating, etc..) It is a replacement for plexus-digest org/codehaus/plexus/digest/ChecksumFile.java org/codehaus/plexus/digest/DigestUtils.java And also covers the logic present in archiva-common too org/apache/maven/archiva/common/utils/Checksums.java - Joakim
Re: [VOTE] Maven 2.0.9
+1
This release is looking really good - thanks to everyone who made this
release possible.
James
On Mon, 2008-04-07 at 12:42 -0400, Brian E. Fox wrote:
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
Release is staged at:
http://people.apache.org/~brianf/stage-2.0.9
Binaries are here:
http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/
List of issues fixed:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
* [MNG-3111] - Classpath order incorrect
* [MNG-3156] - NullPointerException with mvn dependency:sources
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
* [MNG-3286] - execution.inherited field is ignored
* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
* [MNG-3316] - Barfs at attribues named .*encoding
* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
* [MNG-3394] - Plugin versions inherited via pluginManagement
cannot be overriden by build.plugins section of sub modules
* [MNG-3396] - Managed versions dont affect over constrained ranges
* [MNG-3400] - MavenProject is not extensible
* [MNG-3405] - Checking for updates from repository logging should
not display if WagonManager is offline
* [MNG-3410] - Managed versions in plugins are not considered when
using them
* [MNG-3415] - Transfer errors cause junk metadata in the local repo
* [MNG-3426] - regression : dependency in plugin configuration
doesn't override plugin classpath
* [MNG-3430] - Toolchain doesn't match Toolchain extensions
* [MNG-3431] - Pom Extensions not supported for Toolchains
* [MNG-3439] - incorrect child dependency selected when parent is
not selected
* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository
* [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo
* [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly
* [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken
* [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells
* [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions
* [MNG-3494] - local pom dependencies should get injected before
inherited dependencies
* [MNG-3495] - NPE at
org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24
1)
** Improvement
* [MNG-428] - Japanese message resource
* [MNG-2881] - Improve logging when downloading snapshots in offline
mode
* [MNG-3279] - Support Exception Chaining for MojoFailureException
* [MNG-3318] - ActiveProjectArtifact
Re: ANSI color logging in Maven
Rahul, Something like this library might help you in your quest... http://sourceforge.net/projects/javacurses/ James On Tue, 2008-04-08 at 10:40 +1200, Rahul Thakur wrote: Hello, I have opened an enhancement request for ANSI color logging for Maven here. http://jira.codehaus.org/browse/MNG-3507 I believe it would be a neat usability enhancement to Maven and make it much easier to skim through logging output on the console. Thoughts? Cheers, Rahul - 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: [2.0.9 RC4]
Brian, We ran most of Confluences builds live on that teams build server - I'm happy to report that no new issues have cropped up. From my perspective, sans webdav, I think this release is a go. James On Thu, 2008-03-27 at 21:35 -0400, Brian E. Fox wrote: RC4 corrects the version issue identified by Olivier and the Duplicate artifacts exception identified by several testers. It's staged at: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC4/ We'll let this one simmer for a bit while discussion occurs on the webdav issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pre vote take 3] 2.0.9-RC3
I've been testing the Wagon Webdav module in the current release candidate - there are a few glitches to do with the graceful handling of redirects. See WAGON-103 for more details. I recommend that we should retract this from core for the 2.0.9 release. James On Thu, 2008-03-27 at 11:48 +0100, Fabrice Bellingard wrote: Tested on my projects, works fine. Here's my +1 for RC4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wagon changes and WebDAV
+1 On Thu, 2008-03-27 at 20:11 -0400, Brian E. Fox wrote: The other problem with dropping it into the distribution is that when we find out there is a bug in it you can't simply specify a new version of the provider, you would have to go replace the provider and all its deps, or make your own shaded JAR which would be a pain in the ass. (see full thread here: http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html) So the above captures exactly the problem we are seeing now. James has an issue with webdav that may require a fix. This is probably an existing issue and is not core so it shouldn't hold up the 2.0.9 release. The issue is that even if he finds and fixes it, there's no way to upgrade the extension until we do 2.0.10. This seems like it could be a bigger issue than what we've tried to solve, which is make deploy:deploy-file slightly easier to use for one specific protocol. Reading back over the thread, there seemed to be general consensus that this isn't the direction we wanted to go with the trunk, but that 2.0.x wasn't as much of a concern. I think it should be still a concern given the potential to really lock people in. Furthermore this has a big potential to cause regressions because now we just forced everyone to upgrade their webdav even if they didn't want to...and there's nothing they can do about it. That's not cool and I vote we take this out before minting 2.0.9. (I'm leaving it in for RC4 to allow time for discussion and time for more testing of the RC) --Brian - 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: [pre vote take 3] 2.0.9-RC3
Ill also build all of Atlassians products with the RC3 today and post
some results to the list
James
On Wed, 2008-03-26 at 19:55 -0400, Brian E. Fox wrote:
Sejal, thanks...that's exactly the kind of tests we'll need.
-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3
+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.
I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).
On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]
wrote:
+1 the bundle worked fine to build
the archetype plugin.
Raphaël
2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
not yet tested the bundle.
Raphaël
2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
We fixed the regressions identified last week with the plugin tools
and
reporting impl. The new 2.0.9 is staged at
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
che-maven/2.0.9-RC3/
You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official vote, it
makes more sense to have actual deterministic numbers on them
instead of
continuously rolling back and forth between .10 and .9.
The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the
maven
release is no more regressions. To that end, what I intend to do
is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email the
user list to solicit feedback. Naturally we'll probably get a slew
of
can you fix xyz but the only thing that we will consider at this
point
would be a regression from 2.0.8 to the current RC. If something is
identified then we should consider fixing it and re-releasing RC4. I
think that having the users more involved in testing the RCs is the
only
way to really identify and eliminate regressions. If someone
identifies
a regression after the fact and didn't speak up or try it, well
that's
unfortunate but it'll have to wait.
The RC can sit with the users for 3 days. If nothing turns up, then
I'll
restage with a final release tag and we can do a formal vote.
Assuming
this is all successful, then I'll document a more formal Core
release
procedure that we can follow going forward.
Here's the list of issues fixed in the latest RC:
Release Notes - Maven 2 - Version 2.0.9
** Bug
* [MNG-1412] - dependency sorting in classpath
* [MNG-1914] - Wrong url in error message when using a mirror
* [MNG-2123] - NullPointerException when a dependency uses
version
range and another uses an actual version incompatible with that
range
* [MNG-2145] - Plugins' dependencies are not always checked
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
when
profiles section is missing or empty
* [MNG-2339] - ${project.*} are interpreted in the wrong place
* [MNG-2744] - checksum comparison should be case-insensitive
* [MNG-2809] - Can't activate a profile by checking for the
presence
of a file in ${user.home}
* [MNG-2848] - Environment variables in profile activation not
working
* [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
relocated resolvedArtifacts with different version ranges and
available
versions.
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
if
there's no mojo in pom.xml
* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
* [MNG-2972] - Ignores version of plugin dependency specified in
my
pom
* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
* [MNG-3099] - Profiles ignored when working with non-projects
(such
as archetype:create)
*
Re: Why no sources published for plexus-container-default 1.0-alpha-44 release?
Curious - why the special profile that generates them? On Tue, 2008-03-25 at 11:10 -0400, John Casey wrote: I think that was my fault. I guess I didn't include the profile that generates them. I'll be more careful next time. -john On Mar 25, 2008, at 8:08 AM, Brian E. Fox wrote: Plexus utils too...it drives me up the wall. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Tuesday, March 25, 2008 7:46 AM To: Maven Developers List Subject: Why no sources published for plexus-container-default 1.0-alpha-44 release? :-( --jason - 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] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why no sources published for plexus-container-default 1.0-alpha-44 release?
Then perhaps the source plugin should be executed on the release profile? On Tue, 2008-03-25 at 19:30 -0400, John Casey wrote: Probably so development builds don't need to incur that overhead when they're built. I suppose this implicitly assumes that we're doing more development builds than releases...but this is probably logical. -john On Mar 25, 2008, at 6:45 PM, James William Dumay wrote: Curious - why the special profile that generates them? On Tue, 2008-03-25 at 11:10 -0400, John Casey wrote: I think that was my fault. I guess I didn't include the profile that generates them. I'll be more careful next time. -john On Mar 25, 2008, at 8:08 AM, Brian E. Fox wrote: Plexus utils too...it drives me up the wall. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Tuesday, March 25, 2008 7:46 AM To: Maven Developers List Subject: Why no sources published for plexus-container-default 1.0-alpha-44 release? :-( --jason - 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] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lunce 2.1 for trunk
Hey guys, Just looking over the change log for Lucene 2.1 - might be worth an upgrade. http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_1_0/CHANGES.txt Any objections? James
Re: Lunce 2.1 for trunk
After a few words on IRC with Joakim we should jump straight to 2.3.1 James On Thu, 2008-02-28 at 12:08 +1100, James William Dumay wrote: Hey guys, Just looking over the change log for Lucene 2.1 - might be worth an upgrade. http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_1_0/CHANGES.txt Any objections? James
Re: Lunce 2.1 for trunk
Issue and patch can be found here: http://jira.codehaus.org/browse/MRM-720 Ive tested this functionally and it appears to work great. James On Thu, 2008-02-28 at 12:15 +1100, James William Dumay wrote: After a few words on IRC with Joakim we should jump straight to 2.3.1 James On Thu, 2008-02-28 at 12:08 +1100, James William Dumay wrote: Hey guys, Just looking over the change log for Lucene 2.1 - might be worth an upgrade. http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_1_0/CHANGES.txt Any objections? James
Re: Lunce 2.1 for trunk
This upgrade also works for the 1.0.x branch. Thanks James On Thu, 2008-02-28 at 12:40 +1100, James William Dumay wrote: Issue and patch can be found here: http://jira.codehaus.org/browse/MRM-720 Ive tested this functionally and it appears to work great. James On Thu, 2008-02-28 at 12:15 +1100, James William Dumay wrote: After a few words on IRC with Joakim we should jump straight to 2.3.1 James On Thu, 2008-02-28 at 12:08 +1100, James William Dumay wrote: Hey guys, Just looking over the change log for Lucene 2.1 - might be worth an upgrade. http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_1_0/CHANGES.txt Any objections? James
Re: Resources plugin issues
Id also like to see these patches merged in. Thanks James On Wed, 2008-02-27 at 10:04 -0600, Paul Gier wrote: Hi Everyone, The resources plugin seems be a bit neglected lately ;), so I took a look through the current open issues. These issues have relatively simple patches attached: http://jira.codehaus.org/browse/MRESOURCES-39 http://jira.codehaus.org/browse/MRESOURCES-20 http://jira.codehaus.org/browse/MRESOURCES-35 http://jira.codehaus.org/browse/MRESOURCES-28 I think this one is already fixed an can be closed: http://jira.codehaus.org/browse/MRESOURCES-49 Does anyone have access and time to apply the patches and schedule them for the 2.3 release in the roadmap? This one might require a bit more work to verify the patch: http://jira.codehaus.org/browse/MRESOURCES-37 So maybe it can be scheduled for a 2.4 release? Thanks! - 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: [discuss] Archiva TLP proposal
+1 Thanks for starting this discussion Brett. Not being tied to Maven also presents us with the option to grow beyond the scope of a Maven repository manager so what we can support other similar tools if the niche presents itself. On Mon, 2008-02-25 at 13:04 +1100, Brett Porter wrote: Ok, seems there is some interest in putting together a proposal. I'm going to follow the same format we used at Continuum last month. Before we continue to vote on a proposal to send to the board, we need to: 1) Decide on a charter for the project. the creation and maintenance of open-source software related to ... The Apache Archiva project is the creation and maintenance of open-source software relating to the storage, retrieval and management of build system artifacts. I think this sums up the scope of the project well enough. Any thoughts on this? 2) Nominate a chair to put in the proposal I would like to nominate Deng as the chair of the project. I think the work she has done in making sure releases happened consistently, answering users questions, and following up contributions has contributed a lot to the growth of the project recently. +1 I believe Deng is probably the most involved person across all areas of the project, as Brett has mentioned. This makes her more than competent to chair the proposal. Are there any other nominations or seconds? 3) Agree on the initial committers and PMC list I have the current committers list as: Maria Odea Ching ([EMAIL PROTECTED]) Fabrice Bellingard ([EMAIL PROTECTED]) Nicolas de Loof ([EMAIL PROTECTED]) Joakim Erdfelt ([EMAIL PROTECTED]) Arnaud Heritier ([EMAIL PROTECTED]) Dennis Lundberg ([EMAIL PROTECTED]) Jesse McConnell ([EMAIL PROTECTED]) Brett Porter ([EMAIL PROTECTED]) Edwin Punzalan ([EMAIL PROTECTED]) Carlos Sanchez ([EMAIL PROTECTED]) Wendy Smoak ([EMAIL PROTECTED]) John Tolentino ([EMAIL PROTECTED]) Emmanuel Venisse ([EMAIL PROTECTED]) (removed Henri Yandell as he went emeritus already from Maven) Anyone on that list that doesn't feel they should be a committer? Did I miss anyone? +1 Cheers, Brett
Re: Recent contributions
There are some good patches here - could we get them integrated any time soon? James On Thu, 2008-02-14 at 08:06 -0800, Dário Oliveros wrote: Hi there, I've recently created and commented out a couple of issues, provided fixes for some of them and would like anyone (if possible, of course) to check whether any of these changes is acceptable and also if there is anything else I could help with. I'll be glad to do so. Here they are: - MRM-687 (patch that may also fix MRM-608) - MRM-692 (patch) - MRM-617 (workaround for javascript validation) - MRM-622 (patch) - MRM-206 (zip containing xmlrpc functionality) Thanks
Re: MRM-684 - Solving Archiva Blocking
Hey Brett, On Thu, 2008-02-07 at 15:20 +1100, Brett Porter wrote: I don't have any objection to using commons-vfs, since I think it covers much of what Wagon does anyway - as long as it does have all the features needed. Looks like we only use Http/Https, ssh and file Wagon's in archiva - commons-vfs so far looks like it hits the spot. That said - I don't really see any reason this is difficult in Wagon - and do believe Wagon should be usable outside Maven. I think streaming is a perfectly sensible thing to add... I have a copy of Wagon checked out at the moment that works purely with streams but I ran into a few of issues: * Wagon's transfer even model relies on being able to pass the File object that is being transfered to the listener - if its a streaming the transfer events don't make any sense seeing that the consumer of Wagon would be doing all the reading/writing * There are about three different ssh/scp Wagon implementations that can only deal with files. For example, there is a Wagon provider that will use the systems scp executable to upload/download files I really don't see the value in having to ditch Wagon implementations. Regardless, I certainly don't want to see *another* transport layer, or lose something like remote file:// repositories :) I understand your concern - I don't want to add yet another framework to Archiva. All we need is a simple module to allow us to get files from remote locations (http and ssh) and from the local file system. Does that make sense? Perfectly :) James
MRM-684 - Solving Archiva Blocking
Hey guys, I've been investigating the problem described in MRM-684 for the last week or so and so far I have come up with the following. * Data from a remote repository should be streamed back to the client as it is being received. * Both Wagon and Plexus webdav handle resources only as valid file objects. * Fixing Plexus Webdav is a relatively simple change. * Wagon makes a lot of sense in Maven in its current state - its a library built for the needs of Maven and Maven only. * Changing Wagon to support streams instead of files is difficult without taking away what makes Wagon great for Maven (A simple resource transport layer) What I'm want to propose is the removal of Wagon and replacing it with a more flexible library (perhaps we could cook something up with commons-vfs?) So what do you think? Suggestions? Thanks James Dumay
Archiva 1.1 Roadmap
Hey guys, Just wanted to help kick off our way to a 1.1 release Here have been a few things that have been at the back of my mind. I think this is a list we should pick and choose from: * Reduce memory consumption * Preemptive artifact synchronisation * Eliminate client side blocking when artifacts are being downloaded from remote repositories. * Ability to take repositories (both managed and remote) offline (See MRM-541) * Communication with remote repositories should be done asynchronously * Web UI for deploying artifacts * Plugin subsystem. We already have this for consumers but we really should have features like search, dependency graphing and browsing as plugins so we can turn bad behaving features and also give a way for users to create their own functionality. One item I wanted to single out is the separation between managed repositories used for publishing and those used for caching artifacts from remote repositories. I don't think it makes much sense to have a managed repository that can do both. This separation would allow us to have: * Provide indexing, browsing and search only for publishing (See foot note) * RSS feeds for new artifacts in published repositories. Foot note: Allowing to search proxied data is a broken idea - its an incomplete view of a remote repositories and when your dealing with tens of gigabytes of metadata and artifacts this becomes painful and slow. Anyway, I look forward to your comments. Thanks, James Dumay
Re: Bad artifacts in Atlassian's Maven repository
Hey Brian, I recently came across a concerning issue regarding the Atlassian repository used now to house the clover tools and clover maven plugin. This repository contains many artifacts that are duplicated on the central repository but are not authored (that I can tell) by Atlassian. Even more concerning, I have found snapshots of certain artifacts, specifically org.apache.maven.plugins are hosted here. This is also concerning to us. We have been working on an internal project to clean up our build system and our repositories - so currently a work in progress. I think some developers here have ended up publishing some maven plugins to the Atlassian public repository because they were not aware of the Maven Snapshot repository. This can cause lots of grief to users of the Atlassian tools by introducing incorrect artifacts into their build. I personally observed this today and spent some time tracing it back to this repository. We have had a lot of issues with this ourselves. Before I was hired Atlassian did not have someone who really looked after this at all. So in the next few months you should see these sorts of issues go away. Duplicated artifacts after a quick compare of Atlassian and http://repo1.maven.org/maven2 Org/tmatesoft/svnkit Org/openxri/ Org/openid4java Org/jfree (jfree on repo1) Org/codehaus/cargo snapshots Org/codehaus/xfire Org/apache/* Snapshots of plugins among others Some of these may have been patched along the way. Ill add this to my list of artifacts to review. The best practice is not to mix snapshots and releases together in the same repository. Even though maven can be told which repos to use for snapshots and releases, the metadata from a merged repository such as Atlassian can contain information about snapshots that causes build problems. As a service to your users, my strong suggestion is to remove all artifacts that already exist on central, most importantly org/apache and org/codehaus. I would also suggest that snapshots of all artifacts be removed from this repo and placed in a separate snapshot repository. The split has been made some months back - all of our builds now deploy to either release or snapshot repositories but we have not yet separated the existing artifacts from their released and snapshot counterparts. Thanks for your concerns and advice. Ill the list posted on how we progress. Cheers James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Archiva 1.0-beta-3
Not sure if I can vote or not but heres my +1. James On Mon, 2007-10-22 at 13:31 +0800, Maria Odea Ching wrote: Hi All, Archiva 1.0-beta-3 is now ready for release. The highlights of this release are: - major fixes in path resolution of artifacts (for proxying and consumers) - fixes in updating of metadata files - fixes in proxy connectors configuration - tomcat deployment issues - additional fixes in proxying - form validations in webapp The release notes for Archiva 1.0-beta-3 is available here: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13660styleName=TextprojectId=10980Create=Createhttp://jira.codehaus.org/secure/ReleaseNote.jspa?version=13660styleName=TextprojectId=10980Create=Create While the binaries including the sources, checksums and signatures can be found in: http://people.apache.org/builds/maven/archiva/1.0-beta-3/http://people.apache.org/builds/maven/archiva/1.0-beta-2/ Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Deng
Re: Modifying deploy plugin to prevent deployment of existing versions
This is an extremely welcome change. As much as I try to educate developers that releases are immutable I still get a few people who try to do it anyway and fail because the artifact is in the local repo or in a proxy. James On Thu, 2007-10-18 at 22:28 -0700, Jason van Zyl wrote: I've been working on some release/deployment tools lately for a client and I modified their deployments so that you could not accidentally release the same version of an artifact more then once. I can stop this on the server side only when running a repository manager, but we have some simple Apache servers that are DAV enables and someone release an artifact with the same version by mistake and wreaked havoc for 4 hours. I think this one is pretty obvious, I'm not going to write a proposal I'm just going to fix it because it's not very bright that we allow the re-release of something that already has been. I'll leave a option to redeploy if you so choose in the event the driver knows what he's doing. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot 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: Maven 2.0.8 - any updates?
Hello, http://jira.codehaus.org/browse/MSITE-144 is a bit of a blocker for me. At the moment this bug seems to be filed under the wrong project. If I could produce a patch with some testcases, could this please be part of the 2.0.8 release? Thanks, James On Tue, 2007-10-16 at 10:01 +0200, Jörg Schaible wrote: Folks, are there any updates for Maven 2.0.8? What's left to finalize the release? We're still stuck at M205 due to regressions in M206+M207. All of this has been solved months ago. I face meanwhile quite daily people dropping by in my office with Maven problems where I have to say, it is solved in M208 - please wait. I know we Apache people are all volunteers, therefore I'd like to know what's still missing? - Jörg - 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: Maven 2.0.8 - any updates?
http://jira.codehaus.org/browse/MNG-3244 Updated the issue with the fix and the test cases. Thanks James On Wed, 2007-10-17 at 21:12 -0400, Brian E. Fox wrote: With an IT and some unit tests, I think the chances are good. -Original Message- From: James William Dumay [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 8:23 PM To: Maven Developers List Subject: Re: Maven 2.0.8 - any updates? Hello, http://jira.codehaus.org/browse/MSITE-144 is a bit of a blocker for me. At the moment this bug seems to be filed under the wrong project. If I could produce a patch with some testcases, could this please be part of the 2.0.8 release? Thanks, James On Tue, 2007-10-16 at 10:01 +0200, Jörg Schaible wrote: Folks, are there any updates for Maven 2.0.8? What's left to finalize the release? We're still stuck at M205 due to regressions in M206+M207. All of this has been solved months ago. I face meanwhile quite daily people dropping by in my office with Maven problems where I have to say, it is solved in M208 - please wait. I know we Apache people are all volunteers, therefore I'd like to know what's still missing? - Jörg - 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: Maven 2.0.8 - any updates?
I discovered a binary compatibility issue with the Reporting API. http://jira.codehaus.org/browse/MNG-3245 Patch included. James On Tue, 2007-10-16 at 10:01 +0200, Jörg Schaible wrote: Folks, are there any updates for Maven 2.0.8? What's left to finalize the release? We're still stuck at M205 due to regressions in M206+M207. All of this has been solved months ago. I face meanwhile quite daily people dropping by in my office with Maven problems where I have to say, it is solved in M208 - please wait. I know we Apache people are all volunteers, therefore I'd like to know what's still missing? - Jörg - 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: [vote] bring shade-maven-plugin to apache
What does the shade plugin do?
James
On Mon, 2007-09-03 at 02:53 +, Jason Dillon wrote:
Why does it need to move? Why not move it out of the sandbox and use it asis?
--jason
-Original Message-
From: Brian E. Fox [EMAIL PROTECTED]
Date: Sun, 2 Sep 2007 22:37:12
To:Maven Developers List dev@maven.apache.org
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
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: http://jira.codehaus.org/browse/MNG-3151
Sorry if I'm missing something but why they can't just publish everything to their private repo and just mirror things they want share to the public repository afterwards? Sure, that could be done, however, this is yet more infrastructure that needs to be written and maintained in the build environment. As being Maven user (I'm from Apache Cocoon) I support Jason's opinion here. If you have very specific requirements that could be fulfilled by existing tools (few lines of script) just use them and don't pollute other tools with your specific needs. Why use yet another external tool? From the maven website itself: Maven can manage a project's build, reporting and documentation from a central piece of information. So, is the information for the control of artifact deployment not within the scope of the projects mission? Isn't maven supposed to manage my projects build? As you know, Maven already does this in a limited sense - you can deploy whole projects to one repository or another via specifying a distribution management information in your pom. The real use case here is giving developers the flexibility to control what kinds of artifacts go where and subsequently who has access to specific artifact types. For example, at Atlassian, we have a model where customers pay for a license and receive our source code. Customers can then use Maven to resolve dependant artifacts from our public maven repository and build the entire product. For IP reasons, we cannot publish the source and javadoc artifacts publicly along with the jar artifact of which our internal development staff and contractors need to use. I think this would be a fairly common use case among other companies with similar models and if maven is a build management tool - why can't it manage the needs of commercial products too? Thanks -- James William Dumay [EMAIL PROTECTED] Atlassian Software Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://jira.codehaus.org/browse/MNG-3151
Jason, So why can't it all be in one repository? You have people who buy your products with a non-source license and you give them access to binaries from a Maven repository instead of an installer? Or you have updaters that use a Maven repository so you only need the binaries for this? This last case I could understand. We cannot have just one repository and give access to paying customers because we also have a community of plugin developers which rely on various artifacts that are part of our products. This would mean for every developer that would like to write a plugin we would have to give them access to the repository - this would include our private sources. For your own artifacts that you are producing why do they need to be public at all? I ask because I do something similar and I don't understand what it is you're actually trying to accomplish. This aside it still doesn't change the fact Maven wasn't designed to have the primary artifact separated from the secondaries and simply causes a discontinuity in tooling. This is currently how it works. For anyone trying to debug their copy of an Atlassian product the Maven IDE integration wouldn't work. The jars that are released to public without their sources and javadocs are not something the developers building and modifying the products would be wanting source and javadocs for anyway. They are there simply deployed so that they can build the source code that they are licensed to modify. Internally, our developers would be able to access the primary artifacts, sources, javadocs and assemblies. In your case would it not be easier to give people read-only access to the SCM, they build it as you build it and have access to a password protected repository that contains everything required for building. I don't understand your need to separate it the binaries from javadoc and sources. Customers currently download the sources from the website, not checking them out from the repository. Having a password protected repository would mean we would have to add more admin overhead to the Developer Network team. I believe a user should be able to configure their maven builds to allow the deployment of attached artifacts to a specified repository. Users who would use this feature would have to be aware of the consequences of splitting these artifacts away from their primary artifacts. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Continuum giving incorrect validation url
Hey there, I signed up to Maven's Continumm instance at maven.zones.apache.org and got the validation email. Seems that the validation url is pointing to localhost instead of maven.zones.apache.org. I sorted out my validation easily by replacing the hostname with maven.zones.apache.org. Is this a known problem? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Functional tests for maven-assembly-plugin
Brett, I'm running it here on JDK 1.4. Seems maven-site-plugin 2.0-beta-6-SNAPSHOT is JDK 1.5 only? ~James [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:attach-descriptor': Unable to find t he mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:attach-descriptor' in the plugin 'org.apache.maven.plugins:maven-site-plugin' org/apache/maven/plugins/site/SiteDescriptorAttachMojo (Unsupported major.minor version 49.0) On Mon, 2007-08-20 at 16:44 +1000, Brett Porter wrote: They all passed for me locally. John - how often do you want these running in CI? every commit, or a forced nightly build? - Brett On 20/08/2007, at 4:41 PM, James William Dumay wrote: Hey guys, As far as I can tell the integration tests are failing for the maven-assembly-plugin Can the IT's please get a build in ci soon? Thanks James On Fri, 2007-08-17 at 13:38 +1000, Brett Porter wrote: Correct. Given they take about 20 minutes, I think we'd want this on a less frequent schedule, though. John? wdyt? - Brett On 17/08/2007, at 1:25 PM, James William Dumay wrote: Hey Stéphane, That worked for me! Thanks heaps :) Are they being actively ran in Continuum ? I checked yesterday and that build seemed only to run the goals clean install Thanks James On Thu, 2007-08-16 at 09:29 +0200, Stephane Nicoll wrote: Howdy Atlassian folks, On 8/16/07, James William Dumay [EMAIL PROTECTED] wrote: Hey guys, It seems that the functional tests for the maven-assembly-plugin are not being used. There is nothing in the pom file that gets them to run and they are not being compiled. Have you double checked ;-) mvn -Pintegration-tests integration-test HTH, Stéphane Just like to know whats happening so I can test my additional functionality. Cheers -- James William Dumay [EMAIL PROTECTED] Atlassian Software Systems -- -- - 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] - 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: The Maven PMC welcomes Deng Ching
I'm new here - but welcome! James On Mon, 2007-08-20 at 16:19 -0700, Wendy Smoak wrote: I'm pleased to announce that the Maven PMC has voted to add Deng Ching to the PMC. Please join me in welcoming her! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Functional tests for maven-assembly-plugin
Hey Stéphane, That worked for me! Thanks heaps :) Are they being actively ran in Continuum ? I checked yesterday and that build seemed only to run the goals clean install Thanks James On Thu, 2007-08-16 at 09:29 +0200, Stephane Nicoll wrote: Howdy Atlassian folks, On 8/16/07, James William Dumay [EMAIL PROTECTED] wrote: Hey guys, It seems that the functional tests for the maven-assembly-plugin are not being used. There is nothing in the pom file that gets them to run and they are not being compiled. Have you double checked ;-) mvn -Pintegration-tests integration-test HTH, Stéphane Just like to know whats happening so I can test my additional functionality. Cheers -- James William Dumay [EMAIL PROTECTED] Atlassian Software Systems - 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]
Functional tests for maven-assembly-plugin
Hey guys, It seems that the functional tests for the maven-assembly-plugin are not being used. There is nothing in the pom file that gets them to run and they are not being compiled. Just like to know whats happening so I can test my additional functionality. Cheers -- James William Dumay [EMAIL PROTECTED] Atlassian Software Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
