NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Tom, 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 plugin). Of course, as an API most people will simply need to put visad.jar in their > classpath. > 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 > transitioning > 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" ( http://athinkingperson.com/2010/06/02/where-the-big-green-copier-button-came-from/ ). 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. Regards, Curtis
visad archives: