[ImageJ-devel] Fwd: [visad-developer] Moving VisAD repository to github

Tue Nov 6 13:35:52 CST 2012

Hi everyone,

FYI, the VisAD developers are currently discussing migrating VisAD to
GitHub and/or a Maven-based build system.

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].)

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.

Regards,
Curtis

[1] http://loci.wisc.edu/software/visbio
[2] http://loci.wisc.edu/software/visbio-fiji-plugins

---------- Forwarded message ----------
From: Tom Whittaker <whittaker at wisc.edu>
Date: Mon, Nov 5, 2012 at 12:33 PM
Subject: [visad-developer] Moving VisAD repository to github
To: visad-developer at unidata.ucar.edu

We are exploring moving the VisAD source code repository to GitHub.
Presently, we at SSEC are having to (try to) cope with 3 different
SMS's and really want to move to just one.  The IDV has already moved
to GitHug, McIDAS-V will be moving soon...so I thought I'd send this
note around to solicit input from ya'll who are still active
developers.  The idea would be that although it would be at GitHub, we
would still review any community-submitted changes before merging them
into the core...just like now.

Please let me know if you have any comments...

Thanks.

tom

--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI  53706  USA
ph: +1 608 262 2759

_______________________________________________
visad-developer mailing list
visad-developer at unidata.ucar.edu
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/

---------- Forwarded message ----------
From: Curtis Rueden <ctrueden at wisc.edu>
Date: Tue, Nov 6, 2012 at 1:23 PM
Subject: Re: [visad-developer] Moving VisAD repository to github
To: VisAD Developers <visad-developer at unidata.ucar.edu>

Hi everyone,

Tom Whittaker wrote:
> Please let me know if you have any comments.

I think moving VisAD to GitHub would be fantastic!

> The idea would be that although it would be at GitHub, we would still
> review any community-submitted changes before merging them into the
> core...just like now.

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.

Julien Chastang wrote:
> We could also take this opportunity to explore transitioning VisAD to
> Maven. I word this comment cautiously because I am not a 100%
 > convinced this would be a good idea.

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.

Steve Emmerson wrote:
> Gradle is better than Maven in that it does what Maven does, is easier
> to understand, and is more concise.

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.

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:

> Gradle allows to hack something much quicker. In Maven you would need
> to write a plugin.
>
> Otoh I've seen a Gradle project which went from great to barely
> maintainable in almost under a year. Just let a few juniors touch the
> build and you are doomed pretty quickly.
>
> The approach of gradle is not new. Check buildr which does almost the
> same but in ruby instead of groovy. And I think it even predates
> gradle. That was great too in the beginning, but after 3 years the
> projects were insanely broken and we moved them back to maven again.
>
> "With great power comes great responsibility"

Jeff McWhirter wrote:
> I'm just curious why someone would use Maven in the first place. What
> does it do (or do better) than the current VisAD or IDV Ant based
> builds?

The list is extensive:

- Transitive dependency management. VisAD currently has a "deps" folder
with source code of dependent packages. This would no longer be necessary.

- 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.

- 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.

- 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.

- 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.

- 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).

- 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.

- 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.)

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. ;-)

Julien Chastang wrote:
> But my effort is missing proper handling of dependencies.

I would be more than happy to help complete it, especially if most others
are on board with trying out a Maven-based build.

Regards,
Curtis

[1]
http://developer.imagej.net/2012/10/30/imagej2-presentation-imagejconf-2012(slides
44-53)
[2]
http://maven.40175.n5.nabble.com/Arguments-for-Maven-vs-Gradle-td5720939.html

P.S. GitHub and Maven are awesome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20121106/33d849f6/attachment.html>