Re: Unifying maven-nar-plugin implementations
Hi Stephen everyone, Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins Thanks, I filed an issue for it on GitHub: https://github.com/maven-nar/maven-nar-plugin/issues/9 Regards, Curtis On Tue, Oct 9, 2012 at 12:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com javascript:; wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com javascript:; wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
RE: Unifying maven-nar-plugin implementations
Hi All, Apologies for the late reply, this is a work email and I have been on leave for the past few days. Many of the changes that I have made are in reaction to issues found during our somewhat unusual (a mix of multi-module, cross-compile and static) builds. It would be nice to see this work being of value to others and as such am in favour of the unification of the project. I would be interested in having some input into the future development of the plugin. I haven't spent much time looking at other forks, as mentioned previously any work was purely reactionary to immediate issues, so unlike the others I do not have any grand plans for the future of the project at this stage. Regards, Richard From: Martin Eisengardt [mailto:martin.eisenga...@gmail.com] Sent: 08 October 2012 23:40 To: Curtis Rueden Cc: Maven Users List; Johannes Schindelin; Greg Domjan; Richard Kerr; Mark Donszelmann; Mark Donszelmann; Elliot Metsger; sthelen; Peter Janes; Claudio Bantaloukas; Mirko Jahn; sugree Subject: Re: Unifying maven-nar-plugin implementations Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
What I understood was that Marks aim in loading to github, and what I think our aim now is to have it available for general use and progress to it being an apache.org plugin. Would that mean we should change the name until it is ready, or is having the apache naming part of being ready. Mark Donszelmann mark.donszelm...@cern.ch 9/10/2012 4:12 PM Hi On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... Regards Duns - 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 On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.commailto:stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.orghttp://maven.apache.org/ owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... Regards Duns On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.comjavascript:; wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
On 9 October 2012 21:12, Mark Donszelmann mark.donszelm...@cern.ch wrote: Hi On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... That guidance has changed. Regards Duns On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
felix uses maven-bundle-plugin. Not sure why plugin name is important here. -D On Tue, Oct 9, 2012 at 2:38 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 9 October 2012 21:12, Mark Donszelmann mark.donszelm...@cern.ch wrote: Hi On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... That guidance has changed. Regards Duns On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy. - 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
Newer versions of the plugin-plugin enforce the standard so you have to switch to nar-maven-plugin or whatever unless you use the org.apache.maven groupId... imho I would just change and keep the momentum going on github and not really worry about moving it to apache.. manfred On Tue, October 9, 2012 3:11 pm, Dan Tran wrote: felix uses maven-bundle-plugin. Not sure why plugin name is important here. -D On Tue, Oct 9, 2012 at 2:38 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 9 October 2012 21:12, Mark Donszelmann mark.donszelm...@cern.ch wrote: Hi On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... That guidance has changed. Regards Duns On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy. - 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: Unifying maven-nar-plugin implementations
felix will have to change On 9 October 2012 23:11, Dan Tran dant...@gmail.com wrote: felix uses maven-bundle-plugin. Not sure why plugin name is important here. -D On Tue, Oct 9, 2012 at 2:38 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 9 October 2012 21:12, Mark Donszelmann mark.donszelm...@cern.ch wrote: Hi On Oct 9, 2012, at 7:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Don't forget to change the artifactId to nar-maven-plugin or such as maven-___-plugin is reserved for maven.apache.org owned plugins I guess that is correct, however Jason (van Zyl) at the time told me to use maven-nar-plugin... That guidance has changed. Regards Duns On Tuesday, 9 October 2012, Curtis Rueden wrote: Hi all, Feel free to create it an invite the people :) Done: https://groups.google.com/forum/?fromgroups#!forum/maven-nar Let's continue this thread there! Regards, Curtis On Mon, Oct 8, 2012 at 5:40 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy. - 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
On 7 October 2012 16:36, Martin Eisengardt martin.eisenga...@gmail.comwrote: 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. My employers (CloudBees) will give free jenkins instance to any Open Source project that asks for one. And the (separate, but also free) BuildHive feature we provide will even validate pull requests and add the results to the pull request for you. If you want a cloud based Jenkins to do the pushing to the github repo, it doesn't take long to get one. -Stephen 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
Hello, am new to working with Maven, but I would also like to be a project owner. I would like to teach myself to use maven, jenkins, and eclipse. Ishmael Mosby From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org Cc: joerg.schai...@gmx.de; Donszelmann Mark d...@cern.ch Sent: Monday, October 8, 2012 10:06 AM Subject: Re: Unifying maven-nar-plugin implementations On 7 October 2012 16:36, Martin Eisengardt martin.eisenga...@gmail.comwrote: 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. My employers (CloudBees) will give free jenkins instance to any Open Source project that asks for one. And the (separate, but also free) BuildHive feature we provide will even validate pull requests and add the results to the pull request for you. If you want a cloud based Jenkins to do the pushing to the github repo, it doesn't take long to get one. -Stephen 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
My employers (CloudBees) will give free jenkins instance to any Open Source project that asks for one. Thanks for your support. Is your jenkins aware of native builds for win, linux, sunosx, macosx and aware of doing cross-compiles? However please let us talk directly. Maybe we need more than one jenkins to ensure the tests will work on various platforms.
Re: Unifying maven-nar-plugin implementations
On 8 October 2012 13:30, Martin Eisengardt martin.eisenga...@gmail.comwrote: My employers (CloudBees) will give free jenkins instance to any Open Source project that asks for one. Thanks for your support. Is your jenkins aware of native builds for win, linux, sunosx, macosx and aware of doing cross-compiles? However please let us talk directly. Maybe we need more than one jenkins to ensure the tests will work on various platforms. At present our cloud of slaves is Linux only. There is http://developer.cloudbees.com/bin/view/DEV/Customer%2BProvided%2BSlaves%2BWindowsif you have volunteers willing to lend you other build targets
Re: Unifying maven-nar-plugin implementations
Also, rather than migrating a fork directly, perhaps (if Mark agrees) we could migrate the @duns repo, then push all of Greg's changes back on top? That way, existing GitHub forks will all state forked from maven-nar/maven-nar-plugin afterward, which would be ideal. And to preserve old links Mark could fork it back into @duns again and update the README to state what happened. Thoughts? Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. Presumably we would also want to similarly migrate cpptasks-parallel? I think so. It isn't maintained too (correct me if I am wrong). Technical features can be discussed in the github wiki at the moment. Martin, shall we create a mailing list for the project? Perhaps a Google group? Then we can migrate this discussion there instead. Feel free to create it an invite the people :) Regarding cross-compilation: I know it is of interest (wouldn't it be great to build for multiple target platforms all from the CloudBees Jenkins on Linux?). My colleague has done quite a lot of work in that area, but there are some substantial obstacles. Shall we discuss further on our shiny new maven-nar-plugin mailing list, once it exists? Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
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: 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
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: Unifying maven-nar-plugin implementations
Hi, I was going to reply earlier but it slipped. I'd also like to hear more on Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? In the meantime I'm in favour of merging the branches, though for the moment I'm not sure how much time I will have to progress the work mostly it seemed done for all the smaller changes, haven't kept up recently with other 2 active branches. Using my branch or another I'll continue to contribute. I'll merge in changes or grant others access to commit directly on the branch I started to allow this to get moving forward. What I would really need help with is getting the meta setup - I haven't setup a location for the site info before, or worked on publishing to maven central or the other major stores - I'm certainly open to using Martin's offered locations for this. Also the issue log at sonatype is sort of locked up right now, we can add to it, but nobody seems to be able to take on being a developer or own a task assign next milestone etc. --- Sorry about missing cherry pick notes, there where a few changes that overlapped and git got the best of me. --- I actually have another currently private branch that is a mangled mess that does multi builds libtype x linker x arch. I'm going to upload it as another fork for reference, but in the end I think it is a dead end. --- Thoughts on changes that might break with maven 2? The changes I'd really like to make now are in line with making NAR a first class group of plugins for maven3 that would even integrate with other tools such as eclipse or msvc. Thats things like separating the packaging/lifecycle, dependency, compilation into separate plugins, adding a nar-plugin api for plugins to share nar info like sources, layout etc. - having a vague hand wavy idea, but no concrete statement to guide others with yet. I have plugins but then I found need to make special config to share info * xsd-mapping-maven that generates source from an xsd code generator, but have to make config changes currently to tell nar where to get the source. * signing that zips up items to sign and sends them to a web service to sign - at the moment it just grabs all the dll, exe, jar and sends, it needs instruction from nar config on what was built. richardkerr work on additonal compile / post processing seems like a candidate for a seperate plugin 1spatial work on NuGet seems like a candidate for a seperate plugin as alternate archiving Greg Curtis Rueden ctrue...@wisc.edu 10/05/12 12:14 PM Hi all, Replying back with defunct email addresses purged, so that any future replies don't keep receiving bounces. -Curtis On Fri, Oct 5, 2012 at 11:09 AM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the
Re: Unifying maven-nar-plugin implementations
Great news for the project, it looks very promising, especially for working on jni libs. I have no personal interest in the project anymore as it has served its purpose for me (building a legacy jni lib on windows AIX and linux) I had only made two commits https://github.com/rockdreamer/maven-nar-plugin/commit/e52517f42777b870121e87155aa589ed783fdb58 and both had errors as I was still completely unaware of git's idiosyncrasies.. https://github.com/rockdreamer/maven-nar-plugin/commit/e0947a3381a78ab97061686a861b52569bc51a0a These allow building with gcc on AIX, which is a generally unsupported platform. So if you want to commit these, please be careful, especially with the second one as there is also a change in the repos inside the pom. Let me know if there's some way I can help. Regards to all Claudio Bantaloukas On Fri, Oct 5, 2012 at 6:28 PM, Martin Eisengardt martin.eisenga...@gmail.com wrote: Hi. However the first topic is to group a team that will be well active and that will be adoting all forks. I suggest to choose one github project and declare it to be the new main project. One fork by one should be merged and than deleted. Maybe we should choose richards or gregs project (that one that is the most recent) and create a wiki. Within the wiki we should dicuss some things because we all have experiences and want to customize maven-nar-plugin. Deploying to maven central or even becoming a core plugin could be the second topic after having an established project group. Let us say we have to do some homework. :) Greg, Richard? Fine for you to choose one of your forks being the official one? So I suggest to sum up the topics for our homeworks. However I do not know the current merge status. But I would like to work on the following three topics: 1) multiple compiles on one invocation (f.e. win-32 plus win-64) 2) cross compilation with gcc 3) adding new platforms after already having a release. Greetings On Fri, Oct 5, 2012 at 6:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.eduwrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have
Re: Unifying maven-nar-plugin implementations
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. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Unifying maven-nar-plugin implementations
Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
Re: Unifying maven-nar-plugin implementations
Hi all, Replying back with defunct email addresses purged, so that any future replies don't keep receiving bounces. -Curtis On Fri, Oct 5, 2012 at 11:09 AM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
Re: Unifying maven-nar-plugin implementations
Hi. However the first topic is to group a team that will be well active and that will be adoting all forks. I suggest to choose one github project and declare it to be the new main project. One fork by one should be merged and than deleted. Maybe we should choose richards or gregs project (that one that is the most recent) and create a wiki. Within the wiki we should dicuss some things because we all have experiences and want to customize maven-nar-plugin. Deploying to maven central or even becoming a core plugin could be the second topic after having an established project group. Let us say we have to do some homework. :) Greg, Richard? Fine for you to choose one of your forks being the official one? So I suggest to sum up the topics for our homeworks. However I do not know the current merge status. But I would like to work on the following three topics: 1) multiple compiles on one invocation (f.e. win-32 plus win-64) 2) cross compilation with gcc 3) adding new platforms after already having a release. Greetings On Fri, Oct 5, 2012 at 6:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
