<div>Hi everyone,</div><div><br></div><div>FYI, the VisAD developers are currently discussing migrating VisAD to GitHub and/or a Maven-based build system.</div><div><br></div><div>I have mentioned VisAD a few times in the past; it is a really nice general-purpose scientific visualization library for numerical data, which could complement ImgLib, ImageJ2, Fiji, 3D Viewer, etc., well. It was the driving library behind VisBio [1] and I definitely plan to develop some VisAD-based plugins for ImageJ2 in the future! (And actually there is one already [2].)<br>
</div><div><div><br></div><div><div>I didn't forward the whole thread because people did not top post, and some replies deleted parts of the thread, so it was too fragmented. And unfortunately the visad-developer archives are not public. But nonetheless I figured some of you might be interested.<br>
</div></div><div><br></div><div>Regards,</div><div>Curtis<br><br>[1] <a href="http://loci.wisc.edu/software/visbio">http://loci.wisc.edu/software/visbio</a></div><div>[2] <a href="http://loci.wisc.edu/software/visbio-fiji-plugins">http://loci.wisc.edu/software/visbio-fiji-plugins</a></div>
<div><br></div><div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Tom Whittaker</b> <span dir="ltr"><<a href="mailto:whittaker@wisc.edu">whittaker@wisc.edu</a>></span><br>
Date: Mon, Nov 5, 2012 at 12:33 PM<br>Subject: [visad-developer] Moving VisAD repository to github<br>To: <a href="mailto:visad-developer@unidata.ucar.edu">visad-developer@unidata.ucar.edu</a><br><br><br>We are exploring moving the VisAD source code repository to GitHub.<br>
Presently, we at SSEC are having to (try to) cope with 3 different<br>SMS's and really want to move to just one. The IDV has already moved<br>to GitHug, McIDAS-V will be moving soon...so I thought I'd send this<br>
note around to solicit input from ya'll who are still active<br>developers. The idea would be that although it would be at GitHub, we<br>would still review any community-submitted changes before merging them<br>into the core...just like now.<br>
<br>Please let me know if you have any comments...<br><br>Thanks.<br><br>tom<br><br>--<br>Tom Whittaker<br>University of Wisconsin-Madison<br>Space Science & Engineering Center (SSEC)<br>Cooperative Institute for Meteorological Satellite Studies (CIMSS)<br>
1225 W. Dayton Street<br>Madison, WI 53706 USA<br>ph: <a href="tel:%2B1%20608%20262%202759" value="+16082622759">+1 608 262 2759</a><br><br>_______________________________________________<br>visad-developer mailing list<br>
<a href="mailto:visad-developer@unidata.ucar.edu">visad-developer@unidata.ucar.edu</a><br>For list information, to unsubscribe, visit: <a href="http://www.unidata.ucar.edu/mailing_lists/" target="_blank">http://www.unidata.ucar.edu/mailing_lists/</a><br>
</div></div></div><div><br></div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Curtis Rueden</b> <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span><br>
Date: Tue, Nov 6, 2012 at 1:23 PM<br>Subject: Re: [visad-developer] Moving VisAD repository to github<br>To: VisAD Developers <<a href="mailto:visad-developer@unidata.ucar.edu" target="_blank">visad-developer@unidata.ucar.edu</a>><br>
<br><br>Hi everyone,<div><div><br></div><div>Tom Whittaker wrote:</div><div><div>> Please let me know if you have any comments.</div></div><div><br></div></div><div>I think moving VisAD to GitHub would be fantastic!</div>
<div><div><br></div><div>
> The idea would be that although it would be at GitHub, we would still<br></div><div><div>> review any community-submitted changes before merging them into the</div><div>> core...just like now.</div></div><div>
<br>
</div></div><div>GitHub makes it much easier for the community to submit such changes, and for the VisAD core developers to review them, via the Pull Request (PR) mechanism. I actually just gave a talk where I highlighted this fact [1]. In the talk, I walked people through how a PR works, and even went so far as to say: "GitHub is so good, that any project which seriously wants to enable contributions from the community should be using it." I usually try to avoid making such sweeping statements, but GitHub really is that good.</div>
<div><br></div><div>Julien Chastang wrote:</div><div><div><div>> We could also take this opportunity to explore transitioning VisAD to</div><div>> Maven. I word this comment cautiously because I am not a 100%</div>
</div><div>
> convinced this would be a good idea.</div></div><div><br></div><div>Personally I *am* convinced it is a good idea. I know there are many developers who disagree, but I find Maven to be vastly superior to Ant for most Java projects. I have used Ant for more than 6 years, and Maven for ~2 1/2, and designed numerous build systems from the ground up in both, and will say that Maven makes everything much better.</div>
<div>
<div><br></div><div>Steve Emmerson wrote:<br></div><div><div>> Gradle is better than Maven in that it does what Maven does, is easier</div><div>> to understand, and is more concise.</div></div><div><br></div></div>
<div>I agree that Gradle conciseness is nice. Gradle is also much more flexible—but in ways that can sometimes be detrimental. For projects that need it, this flexibility can be important, but the fact is that most projects don't need it (and I definitely don't think VisAD does). With Maven there is generally one standard way to go about doing something. The advantage is that you get a build system that others can understand much more immediately.</div>
<div><br></div><div>To be fair, I have not used Gradle extensively, and have heard many good things. There was a recent discussion about Gradle vs. Maven on the Maven users list [2], with some people coming out in favor of Gradle. But here is one message which I think summarizes the dangers well:</div>
<div><br></div><div><div>> Gradle allows to hack something much quicker. In Maven you would need</div><div>> to write a plugin.</div><div>></div><div>> Otoh I've seen a Gradle project which went from great to barely</div>
<div>> maintainable in almost under a year. Just let a few juniors touch the</div><div>> build and you are doomed pretty quickly.</div><div>></div><div>> The approach of gradle is not new. Check buildr which does almost the</div>
<div>> same but in ruby instead of groovy. And I think it even predates</div><div>> gradle. That was great too in the beginning, but after 3 years the</div><div>> projects were insanely broken and we moved them back to maven again.</div>
<div>><br></div><div>> "With great power comes great responsibility"</div></div><div><div><br></div><div><div>Jeff McWhirter wrote:</div><div>> I'm just curious why someone would use Maven in the first place. What</div>
<div>> does it do (or do better) than the current VisAD or IDV Ant based</div><div>> builds?</div></div><div><br></div></div><div>The list is extensive:</div><div><br></div><div>- Transitive dependency management. VisAD currently has a "deps" folder with source code of dependent packages. This would no longer be necessary.</div>
<div><br></div><div>- Automatic support for any IDE with Maven integration. You could develop VisAD in Eclipse, NetBeans, IntelliJ IDEA, and likely others. Development on the command line (mvn, vim, etc.) is still just as feasible too.</div>
<div><br></div><div class="gmail_extra">- Standard build system. Every Ant-based build system is hacked together, reinventing the wheel. Maven provides a standard framework, which you fill in with your project's details. Other Maven-aware developers can immediately understand and build your project.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- The benefits of the standard build system are really paramount, and deserve a second bullet point. One of many advantages: many people have extended Maven with plugins that you can immediately plug in to your build. For example, the Maven graph plugin lets you generate a Graphviz plot of your project dependencies. This plugin can be easily hooked into any Maven-based project. Yes, Ant has plugins too, but they are more complex to hook into your project build, and require management of third-party JARs. Conversely, Maven plugins are easy to leverage from the Maven Central repository, just like dependencies.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- VisAD has lots of dependencies (Java3D, JAMA, Bio-Formats, NetCDF, DODS...), but is currently still pretending it doesn't. But practically speaking, the current structure with the deps folder causes some problems. It is difficult to keep VisAD up to date with the latest netCDF Java work, or the latest Bio-Formats work, because it simply ships an ancient fork of those codebases. And anyone who wants to use VisAD with newer versions of those libraries will run into trouble, since VisAD's versions of those codebases do not rename any packages. Using Maven to manage the dependencies properly would render most of these issues moot.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- Publishing VisAD as one or more Maven artifacts would make it much more usable as a dependency of other projects. Right now, I have a "visad-lite" artifact that I published to the ImageJ Maven repository, which we use for some things, but it is woefully out of date. It would be much better if VisAD were formally Mavenized, so that downstream projects could maintain an easier coupling (to either a snapshot version or to a specific release version which can be easily upgraded later).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- If VisAD were a Maven project it would also make development in IDEs such as Eclipse much easier. You can link to dependent projects' source code, debug into it, even change the code, all transparently. With Eclipse's M2E plugin there is no more juggling of "project dependencies" versus "library/JAR dependencies" because M2E automatically does the right thing based on which projects you currently have open in the IDE.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- Publishing VisAD in Maven Central would also make it more visible. I think it is a tragedy that more people do not know about VisAD and its amazing feature set and power. Migrating to GitHub and Maven would be a major step toward publicizing the library as a real contender for use with other tools. (The web site also needs a major overhaul, but that is a separate issue. The main point is that right now, from both the web site and choice of development tools, VisAD simply does not appear to be actively maintained.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">OK, I am getting short on time now, so if you guys still need more convincing, let me know and I can spout off ten more bullet points. ;-)</div><div><br></div><div>
</div><div class="gmail_extra"><div>Julien Chastang wrote:<br><span style="font-family:arial,sans-serif;font-size:13px">> But my effort is missing proper handling of dependencies.</span><div style="font-family:arial,sans-serif;font-size:13px">
</div><br></div>I would be more than happy to help complete it, especially if most others are on board with trying out a Maven-based build.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">
Curtis</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://developer.imagej.net/2012/10/30/imagej2-presentation-imagejconf-2012" target="_blank">http://developer.imagej.net/2012/10/30/imagej2-presentation-imagejconf-2012</a> (slides 44-53)</div>
<div class="gmail_extra">[2] <a href="http://maven.40175.n5.nabble.com/Arguments-for-Maven-vs-Gradle-td5720939.html" target="_blank">http://maven.40175.n5.nabble.com/Arguments-for-Maven-vs-Gradle-td5720939.html</a><br><br>
P.S. GitHub and Maven are awesome!<br></div></div></div><div><br></div>
</div>