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 Valerio, I think you're right - as I said I'm not a maven expert so I think I misunderstood some things. The situation with nj4 is somewhat complex since there are "plugins" that not everybody will use - but I think your mechanism of using optional dependencies is the easiest solution. One other solution might be to create some virtual packages (are these "pom-only" projects?) that bundle up nj4 with dependencies for different situations. E.g. you could have a "nj4-opendap" project that includes nj4, opendap.jar, httpclient.jar etc. You could also have a "nj4-bufr" project that includes nj4, bufr and jpeg2000, and so on. However, this would be extra work for the mavenizer (i.e. you!) but might be a way to avoid optional dependencies. > By the way, which benefits you will get using "runtime" scopes? I guess the benefits are not great - I was simply thinking that one could avoid downloading the dependencies when compiling against nj4, but in most cases you'd need to download them anyway when running. Thanks again for your efforts, Jon On Mon, May 11, 2009 at 11:40 AM, Valerio Angelini <angelini@xxxxxxxxxxx> wrote: >>> The netcdf-java pom contains the list of the dependencies needed by the >>> netcdf-java library and the dependency scopes should relate to the build >>> of >>> the library itself. >> >> I might be wrong (I'm not a maven expert) but this isn't my >> understanding of how the scopes work. Sure, when you are building >> netcdf-java from source using maven, you'll need a POM that includes >> the compile-time dependencies correctly. But when you're *using* >> netcdf-java you're not compiling it, so you need a POM that marks >> run-time dependencies. The POM that you provide is for people who are >> using netcdf-java, not compiling it. Please correct me if I'm wrong! > > In my understanding maven is a build system and the pom is the file that, > describing the all the projects peculiarities, permits the automatic build. > > Writing the pom for an already build library is a "trick" to be able to > depend upon a non-mavenized library, so why in this case should I write a > pom in a different way? > > If I follow the standard way of writing a pom and the netcdf-java lib > developers want to mavenize their own the lib, they can start from the > alredy written pom. In this case all the developers that use the library > will no even notice the difference. > > By the way, which benefits you will get using "runtime" scopes? > > Regards > > Valerio > > -- > Valerio Angelini > Institute of Methodologies for Environmental Analysis > Italian National Research Council > phone: +39 0574 602535 > e-mail: angelini@xxxxxxxxxxx > > > > -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blower@xxxxxxxxxxxxx http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
netcdf-java
archives: