So would Maven replace Eclipse and NetBeans? Does git/github require
> Maven, is Maven free?
Yes, Maven is open source. As long as you have a Maven POM, you can import
the project into NetBeans, Eclipse, or IntelliJ IDEA without needing to
commit those IDEs' metadata files to the VCS. All three support Maven
really well (NetBeans & IDEA out of the box, and Eclipse via the m2e
Of course, as an API most people will simply need to put visad.jar in their
> Am I right?
Yes, because VisAD currently bundles all the dependencies in the same JAR
file. However, if you want more flexible handling of dependencies, it
becomes more difficult.
Maven's biggest strength is in dependency management. You can compile a JAR
without needing to compile all the dependent JARs, or even have them
committed to your VCS.
The ant build process works very well, and we spent about a month
> VisAD from CVS/make to SVN/ant.
You wouldn't have to get rid of Ant. For another project I work on
(Bio-Formats), we kept the Ant build system and also added Maven POMs. So
you can choose which way to build. We have the option of removing the
Ant-based build system in the future, if/when it is no longer being used.
You have to accept the way Maven does things and not fight the tool. In
> practice, this means adopting the sometimes awkward directory structure.
> Otherwise, Maven is just an exercise in frustration. "Convention over
> configuration" is the motto.
> I'm sorry, but this statement really concerns me personally.
This is the one place where I disagree with Julien. There is a meme in the
Maven community: "Don't fight against Maven; you'll lose." I think it is
repeated far too often, and often inappropriately.
In the case Julien listed—adopting Maven's directory structure—you don't
have to, and we didn't, for the Bio-Formats project. In fact, we did not
have to reorganize the file system at all when adding the POMs.
There *are* cases where certain directory structures will not work with
Maven, but the current VisAD directory structure is probably fine.
As Julien said, Maven is about *convention over configuration*. The
"configuration" part is still *possible*. It's all about sensible defaults,
and the "big green button" (
A migration git/github would also carry many advantages as that technology
> excels in promoting collaborative development. THREDDS is already seeing
> the benefits of git. See https://github.com/Unidata/thredds/network
> We've had excellent collaborative development to date with Unidata,
> ABoM, VisBIO, more recently ISRO/SAIC (India). If git/github is superior
> and easier to use than SVN, I'd be certainly willing to have a more formal
> discussion on this list of making the transition.
Git is not easier to use than SVN. It is a PITA to learn. But once you
learn it, it *rules*.
GitHub is easy to learn and use, and the most effective collaboration tool
I have ever used. Rather than having to email someone patches, or give
someone SVN commit rights, they can simply fork your repository and go to
town on their copy. Then, when they have something working well, they
submit a "pull request" to the upstream (i.e., official) repository. It
makes submitting changes for official inclusion a breeze!
Maven is imperfect, but the benefits outweigh the disadvantages. The same
> is true for git/github.
I agree completely about Maven and Git being imperfect, but definitely
worth it. Of the top of my head I can't think of any downsides to GitHub
though—it's pretty fabulous. :-)
I'll just mention again, that McIDAS-V is still using CVS.
There is certainly pain involved in any technical migration or transition,
so doing so should always be carefully considered. But I think if you
migrated the system to Git, within 1-2 years you would look back and wonder
why you waited so long to do it. Git really is amazing for collaboration,
particularly among larger teams.