On 27 September 2011 16:13, Jody Garnett <[email protected]> wrote: > I had a look; there is no obvious way to get it to stop. > Leaving us with: > a) turn off javadoc formatting (sigh) > b) leave it turned on but set the line wrap to 150 (would that do it?) > Can you give me a good example I could test the formatting on?
A typical case was: coverage/src/main/java/org/geotools/coverage/grid/io/imageio/geotiff/CRS2GeoTiffMetadataAdapter.java If you checkout a revision < 38089 (my update) you'll see in that the @source tag is on one line with its associated file path on the subsequent line. But before we chase it further or hassling Simone and co unnecessarily it occurs to me that we might be able to cheat. I always preferred cheating when it's an option - and even more so as I age. When the taglet is processed during javadoc creation there must be a way of getting at the source path: e.g. from the taglet API or via maven or even by reflection we have to. In other words, let's try dispensing with the requirements for the path to be in the source file at all. The only reason I've been doing that is because that's how the taglet was written originally and I've been too lazy to think of better ways. As well as side-stepping the formatting problem this would also deal with git being too dumb to work with svn:keywords. What do you think ? Michael ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
