Re: Unifying maven-nar-plugin implementations
Hi, Benson Margulies wrote: Adding plugins to the core is not so much a matter of 'strategy'. The nar plugin is a non-trivial amount of code. So, for it to come to Apache, it would have to pass IP clearance. That means understanding the provenance of all of the code and that the people contributing it have sufficient rights to grant a license to the ASF. That having been said, the existing Maven community is rather thinly spread across the many org.apache.maven.plugins. Adding another big, complex, plugin should, at least, lead to a pause for reflection. Nonetheless, If the authors are interested in contributing it, please join the dev list and start a discussion. another option is mojo.codehaus.org, especially since the devs discuss about moving the SCM for individual plugins to git. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unifying maven-nar-plugin implementations
Do we actually need the agreement of all authors to become a maven core project? The sources are already licensed under terms of ASF. The original authors seem not respond for months or the email addresses are no longer valid. Would it be fine if there is a new (active) project group filling up the CLA? http://www.apache.org/licenses/#clas Actually duns code is not the original code. There was some other author (freehep). For me personally I do not care if this is becoming a maven-ocre component or not. I am fine with codehaus and other variants too. My personal interest is to remove all the forks and having an active project roup I can discuss and commit my work :) On Sun, Oct 7, 2012 at 12:23 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi, Benson Margulies wrote: Adding plugins to the core is not so much a matter of 'strategy'. The nar plugin is a non-trivial amount of code. So, for it to come to Apache, it would have to pass IP clearance. That means understanding the provenance of all of the code and that the people contributing it have sufficient rights to grant a license to the ASF. That having been said, the existing Maven community is rather thinly spread across the many org.apache.maven.plugins. Adding another big, complex, plugin should, at least, lead to a pause for reflection. Nonetheless, If the authors are interested in contributing it, please join the dev list and start a discussion. another option is mojo.codehaus.org, especially since the devs discuss about moving the SCM for individual plugins to git. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unifying maven-nar-plugin implementations
Hi I am the author of the maven-nar-plugin. Let me start by apologizing that I have not kept track of, neither have worked on it in recent years. I moved on to other things, but may come back using / working on it later on. The nar plugin was created by me when I was working at Stanford Linear Accelerator Center (SLAC) for Maven 1. When Maven 2 came out I rewrote it, and that is the code that is still there. Inside SLAC we maintained Open Source code by High Energy Physicists under the name FreeHEP, available to anyone. A thing such as git or github did not exist at the time, so we needed a way to distribute out code, and a name for it. I think it would be a good idea if you guys pick up the parts and continue with it. I have no real time to work on it, but could answer questions if you have any. You have my agreement, and SLAC already gave its agreement for me to take the code away from them. I guess officially Sonatype owns the code, as I dropped it with them, but they seem to have little interest in it (as far as I could see from the mailings). Keep me posted. Regards Mark Donszelmann On Oct 7, 2012, at 12:35 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Do we actually need the agreement of all authors to become a maven core project? The sources are already licensed under terms of ASF. The original authors seem not respond for months or the email addresses are no longer valid. Would it be fine if there is a new (active) project group filling up the CLA? http://www.apache.org/licenses/#clas Actually duns code is not the original code. There was some other author (freehep). For me personally I do not care if this is becoming a maven-ocre component or not. I am fine with codehaus and other variants too. My personal interest is to remove all the forks and having an active project roup I can discuss and commit my work :) On Sun, Oct 7, 2012 at 12:23 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi, Benson Margulies wrote: Adding plugins to the core is not so much a matter of 'strategy'. The nar plugin is a non-trivial amount of code. So, for it to come to Apache, it would have to pass IP clearance. That means understanding the provenance of all of the code and that the people contributing it have sufficient rights to grant a license to the ASF. That having been said, the existing Maven community is rather thinly spread across the many org.apache.maven.plugins. Adding another big, complex, plugin should, at least, lead to a pause for reflection. Nonetheless, If the authors are interested in contributing it, please join the dev list and start a discussion. another option is mojo.codehaus.org, especially since the devs discuss about moving the SCM for individual plugins to git. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: noob confusion about dependencies and repositories
On Sun, Oct 7, 2012 at 9:34 AM, Rob Withers reefed...@gmail.com wrote: I am guilty for being lazy. I really hate all this build config stuff and with maven, git and Jenkins, plus FindBugs and PMD in all three environments, it gets to me. I am totally up and running, minus some issues as I split my project apart that I am working on. If I do go for the public maven repos, I will be sure to read the books. You have given me a crash course on it and I can us it effectively now. Now, back to coding, which is what I really like to do (minus a trip back into JBoss land). You sound like you can get the stuff done, so I beg you to spend a small amount of time reading those docs. Instead of this stuff bugging you, you will understand how to quickly and easily get it fixed. Otherwise next time you run into these problems you will have that mental barrier that says this stuff is hard and annoying. It is only that way because you need to know the basics. You wont regret it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: noob confusion about dependencies and repositories
-Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] On Sun, Oct 7, 2012 at 9:34 AM, Rob Withers reefed...@gmail.com wrote: I am guilty for being lazy. I really hate all this build config stuff and with maven, git and Jenkins, plus FindBugs and PMD in all three environments, it gets to me. I am totally up and running, minus some issues as I split my project apart that I am working on. If I do go for the public maven repos, I will be sure to read the books. You have given me a crash course on it and I can us it effectively now. Now, back to coding, which is what I really like to do (minus a trip back into JBoss land). You sound like you can get the stuff done, so I beg you to spend a small amount of time reading those docs. Instead of this stuff bugging you, you will understand how to quickly and easily get it fixed. Otherwise next time you run into these problems you will have that mental barrier that says this stuff is hard and annoying. It is only that way because you need to know the basics. You wont regret it. Thank you. I can do it, for sure. I tend to read the docs and ask questions at the same time, until I get my problem solved. The issue is that these problems are peripheral to the problems I want to solve, which is a secure promise-based distributed object messaging system. Much more interesting and difficult in its own right. This stuff, while very powerful when done right, and necessary, is like keeping my apartment clean or cooking dinner! It is a chore. ;-) That said, I do like maven a lot. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unifying maven-nar-plugin implementations
I was waiting for you to respond as its your baby :-) While Sonatype helped pay for some of the work in the last stage of NARs development, our focus has really been on Java so we really haven't had much time in the last few years. That said with all the work Sonatype has been doing with Insight we get questions about native code and mobile development for the iPhone quite a bit. I am happy if there are users contributing and you want to coalesce the fragmented implementations. I think that Github is the perfect place to do that right now, low barrier to working together and it's very easy to get a project into Central regardless of where it is. That you as users, who became developers, have come together to put NAR back together is the only key element required to make the project successful. No organization will make your project popular, usable or help it improve. It is the work of small interested individuals that make the difference. That said if you were going to take it to a foundation, in the long run I would take it to the Eclipse Foundation. They have just converted the whole platform build to Maven and there is a large native component to that for SWT and the launchers. Redhat has done a lot of the work there lately and I'm sure they would be interested as they do their own builds of the Eclipse Platform for their users and customers. I happy to talk any of the groups as Sonatype would have to make a donation of code to move it to a foundation, but honestly I really think Github is the best place for you to spark up the project again. On Oct 7, 2012, at 6:58 AM, Mark Donszelmann mark.donszelm...@gmail.com wrote: Hi I am the author of the maven-nar-plugin. Let me start by apologizing that I have not kept track of, neither have worked on it in recent years. I moved on to other things, but may come back using / working on it later on. The nar plugin was created by me when I was working at Stanford Linear Accelerator Center (SLAC) for Maven 1. When Maven 2 came out I rewrote it, and that is the code that is still there. Inside SLAC we maintained Open Source code by High Energy Physicists under the name FreeHEP, available to anyone. A thing such as git or github did not exist at the time, so we needed a way to distribute out code, and a name for it. I think it would be a good idea if you guys pick up the parts and continue with it. I have no real time to work on it, but could answer questions if you have any. You have my agreement, and SLAC already gave its agreement for me to take the code away from them. I guess officially Sonatype owns the code, as I dropped it with them, but they seem to have little interest in it (as far as I could see from the mailings). Keep me posted. Regards Mark Donszelmann On Oct 7, 2012, at 12:35 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Do we actually need the agreement of all authors to become a maven core project? The sources are already licensed under terms of ASF. The original authors seem not respond for months or the email addresses are no longer valid. Would it be fine if there is a new (active) project group filling up the CLA? http://www.apache.org/licenses/#clas Actually duns code is not the original code. There was some other author (freehep). For me personally I do not care if this is becoming a maven-ocre component or not. I am fine with codehaus and other variants too. My personal interest is to remove all the forks and having an active project roup I can discuss and commit my work :) On Sun, Oct 7, 2012 at 12:23 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi, Benson Margulies wrote: Adding plugins to the core is not so much a matter of 'strategy'. The nar plugin is a non-trivial amount of code. So, for it to come to Apache, it would have to pass IP clearance. That means understanding the provenance of all of the code and that the people contributing it have sufficient rights to grant a license to the ASF. That having been said, the existing Maven community is rather thinly spread across the many org.apache.maven.plugins. Adding another big, complex, plugin should, at least, lead to a pause for reflection. Nonetheless, If the authors are interested in contributing it, please join the dev list and start a discussion. another option is mojo.codehaus.org, especially since the devs discuss about moving the SCM for individual plugins to git. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason
Re: Unifying maven-nar-plugin implementations
Jason will, I'm sure, correct me if I'm wrong, but I believe the IP provenance issues to be comparable at Eclipse and Apache. The Apache Foundation only accepts code that is *voluntarily* contributed. That amounts to two tests: a) is there clear provenance? b) is there clear evidence of the voluntary contribution? These two add up to, at least, a requirement that the author(s) of the vast majority of the code be identified and participate. This can make it challenging to bring a loosely-managed existing codebase into Apache. It's not impossible, but, as Jason says, github avoids this. Unless you are really hankering for the legal protections offered by one of the Foundations, it's the simplest solution. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Archiva 1.4-M3 Released
Hi, The Apache Archiva team would like to announce the release of Archiva 1.4-M3. Archiva is available for download from the web site. [1] Archiva is an application for managing one or more remote repositories, including administration, artifact handling, browsing and searching. If you have any questions, please consult: * the web site: http://archiva.apache.org/ * the archiva-user mailing list: http://archiva.apache.org/mail-lists.html There is now a new webapp UI based on javascript (legacy webapp is still distributed). NOTE: most of the UI issues has been fixed in the new UI only. For a more detailed release note you can consult: http://archiva.apache.org/docs/1.4-M3/release-notes.html Have Fun ! -- The Apache Archiva Team [1]http://archiva.apache.org/download.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unifying maven-nar-plugin implementations
OK. Thanks four your responses, Mark and Jason. Lets sum up. We have the agreement of the authors to build up a new working group. I recently created a new organization at github: https://github.com/maven-nar (just to give this a kickstart) Please tell me who wants to become a project owner. I have added the three active fork users (richardkerr, grogdomjahn and 1spatial). I suggest to now vote on one fork to be moved to the organization and merging all the pull requests, solving issues etc. Unperiodical users can always create pull requests on the project. New regular users are welcome :) Technical features can be discussed in the github wiki at the moment. I will create website and other things too, the website and repository can be hosted by github. After doing this homework with merging all the forks we can discuss the future of this project. As long as there is no organization selected I will use my jenkins to push the website to a github repository. That said if you were going to take it to a foundation, in the long run I would take it to the Eclipse Foundation. They have just converted the whole platform build to Maven and there is a large native component to that for SWT and the launchers. Redhat has done a lot of the work there lately and I'm sure they would be interested as they do their own builds of the Eclipse Platform for their users and customers. I happy to talk any of the groups as Sonatype would have to make a donation of code to move it to a foundation, but honestly I really think Github is the best place for you to spark up the project again. I do not preferr any of the codehaus, mavens core or eclipse foundation. All three solutions are fine for me as well as having a lonesome project group using github and publishing to maven central. For eclipse: This should be discussed with an eclipse foundation guru and with an eclipse cdt guru. As soon as we are ready with the project team and voted for an active project lead I would be happy to contact them. I am already involved in eclipse pdt (commiting patches) and already had some contact to some of the gurus.
Re: Unifying maven-nar-plugin implementations
I think the github organization is a great start. On Oct 7, 2012, at 11:36 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: OK. Thanks four your responses, Mark and Jason. Lets sum up. We have the agreement of the authors to build up a new working group. I recently created a new organization at github: https://github.com/maven-nar (just to give this a kickstart) Please tell me who wants to become a project owner. I have added the three active fork users (richardkerr, grogdomjahn and 1spatial). I suggest to now vote on one fork to be moved to the organization and merging all the pull requests, solving issues etc. Unperiodical users can always create pull requests on the project. New regular users are welcome :) Technical features can be discussed in the github wiki at the moment. I will create website and other things too, the website and repository can be hosted by github. After doing this homework with merging all the forks we can discuss the future of this project. As long as there is no organization selected I will use my jenkins to push the website to a github repository. That said if you were going to take it to a foundation, in the long run I would take it to the Eclipse Foundation. They have just converted the whole platform build to Maven and there is a large native component to that for SWT and the launchers. Redhat has done a lot of the work there lately and I'm sure they would be interested as they do their own builds of the Eclipse Platform for their users and customers. I happy to talk any of the groups as Sonatype would have to make a donation of code to move it to a foundation, but honestly I really think Github is the best place for you to spark up the project again. I do not preferr any of the codehaus, mavens core or eclipse foundation. All three solutions are fine for me as well as having a lonesome project group using github and publishing to maven central. For eclipse: This should be discussed with an eclipse foundation guru and with an eclipse cdt guru. As soon as we are ready with the project team and voted for an active project lead I would be happy to contact them. I am already involved in eclipse pdt (commiting patches) and already had some contact to some of the gurus. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: noob confusion about dependencies and repositories
Rob Withers reefed...@gmail.com: I am guilty for being lazy. I really hate all this build config stuff... [snip!] FWIW, in my experience embracing maven patterns allows you to reduce build config to a minimum. On the recommended book list mentioned earlier, I will in particular mention Maven by example http://www.sonatype.com/Support/Books/Maven-By-Example - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
