Re: No source for 2.3.14 in Maven repository
Daniel Dekany <[email protected]>
| Newsgroups | gmane.comp.web.freemarker.user |
|---|---|
| Message-ID | <[email protected]> |
Friday, November 28, 2008, 5:48:08 AM, Jeff Ramsdale wrote: > Daniel Dekany wrote: >> Wednesday, November 26, 2008, 6:31:37 PM, Jeff Ramsdale wrote: >> >>> Ah, I assumed it was a slip since 2.3.13 has source (separate jar): >>> >>> http://repo2.maven.org/maven2/org/freemarker/freemarker/2.3.13/ >>> I'm quite handy with Ant and mean no disdain when saying Maven (once >>> the learning curve is conquered) dramatically simplifies the build >>> management for more complex projects. In our case we're using >>> FreeMarker with Restlet, the latest release of which is hard-coded >>> to depend on 2.3.14. >> >> BTW, I think they should depend on "[2.3.14,2.4)". >> See: http://freemarker.org/freemarkerdownload.html >> Do I suggest a bad practice there? I hope not. > > My first inclination was to agree, but on second thought I think that > would be a mistake. The Restlet devs would be reliant on the FreeMarker > devs not releasing an incompatible change. We say on the download page that releases where only the 3rd version number is changing are backward compatible. But of course we do mistakes sometimes... so on a deadly serious place (typically, where bugs can cause real-world catastrophes) automatic upgrade is not acceptable, but now honestly, how much of the FM users are working on a such place? With such high standards the whole Java world, by which I mean the 95% of widely used Java libraries, is a bad joke. So, I think that in practice, whenever a new FM release is out, everyone just replaces his 2.3.x with a 2.3.(x+1) without doing any research. Like, when the Restlet developers notice that 2.3.15 is out, I bet some of them just blindly replaces the dependency in the POM with 2.3.15... so it might as well can happen automatically. > Neither community should have to bear the risk of a breaking change > when they (the Restlet devs) can safely declare a dependency on a > specific FreeMarker version (which they've presumably tested). Maven > provides the ability to override that dependency if necessary (which > we did to look at FreeMarker source code). > > On the other hand, direct consumers of FreeMarker (i.e. anyone not > getting it as a transitive dependency) may choose to identify a version > range in their dependency. If they run into a compatibility problem all > they have to do is identify the last functioning version and specify it > explicitly. Still, I almost never see version ranges used in Maven-land. > Usually a version upgrade should be somewhat intentional, IMHO. At least for projects that doesn't have a clear version policy... which is most of the Java projects anyway, so, yeah. >>> We use the m2eclipse plugin to provide Maven integration with Eclipse. >>> Thus, by adding Restlet with the FreeMarker extension to our pom >>> FreeMarker 2.3.14 is downloaded automatically. A context menu provides >>> the option to automatically download and attach source (no need to go to >>> a provider's website, find the download, unzip, and configure project to >>> attach source). Since no FreeMarker source jar is posted this step >>> fails. But it's a beautiful thing when it works! >> >> So, you need this for looking into the source code with ctrl+click and >> for the JavaDoc "hints", and that's all. Right? > > Correct. > > <snip /> > > -jeff -- Best regards, Daniel Dekany ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/