[Patch] Enhance JMapViewer release system

[h.goebel@…]

Hi,

the release files (zip archives) do not contain the source. This is very obstructive for build release packages for Linux distributions. :-( Please provide packages containing the source, too.

Thanks!

[Don-vip]

The last release (​http://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/2013-03-22/JMapViewer_2013-03-22.zip) does contain a JMapViewer_src.jar in which sources can be found.

[h.goebel@…]

To be frank, this is not what I expect to be a "source release". Nobody is looking for source in a JAR-file, which again is packaged into a release-zip-file.

Enclosed please find a patch for generating a release-zip as packages would expect. It even includes the version (which is the data) in the filename and prefixes all files in the zip by a versioned sub-dir.

[h.goebel@…]

fixed version - first one did use wrong timestamp

[h.goebel@…]

Based on this you could even ease creating releases: Just create the .zips directly in directory "release/$version/".

[Felix Natter <fnatter@…>]

hi,

if you could in addition to using this script use a proper version property (like "0.1", "1.0", "0.9.1" or similar),
then this would also fix #8650 :-)

Thank you!

Best Regards,
Felix

[The111]

I incorporated the patch above and also did some other changes to the build.xml. Now all releases (jars and zips) get the SVN revision number incorporated to the filename as a version number, and they also go straight into the releases folder rather than cluttering up the root and needing to be manually deleted.

See [o29618].

The only small problem is that SVN revision that gets put in the filenames is the current revision, which means when everything gets committed, it will be the previous version. I am not sure of a way around this. Any suggestions? Basically it just means that the people who use release zips only will always be one version number behind (though they'll be using the latest code, just with the previous SVN revision as the version number). I'm not sure it will cause any problems in practice, though it is slightly annoying.

[Felix Natter <fnatter@…>]

patch against build.xml from jmapviewer-29618

[Felix Natter <fnatter@…>]

hello,

the patch was not 100% correct. I have attached a patch (against the previously patched build.xml)
that actually puts the source in src/ and that creates bin/ if it doesn't exist.
This also fixes the clean target such that the jars are removed.

=> Could you still consider making real versioned releases? Currently our only option (Debian package)
is to name it "jmapviewer-svn29618", "jmapviewer-0.0+svn29618" or even "jmapviewer-29618"...
Further, with proper versions you could express incompatibility with version gaps (jmapviewer-2.0
is incompatible to jmapviewer-1.x).
(Of course this can be done very easily by using a property like you do for svn.Revision)

Thanks and Best Regards,
Felix

[Felix Natter <fnatter@…>]

hello again,

could you please make a release with the new build.xml (with or without svn.Revision) relatively soon?
With the current build.xml in the source zip I cannot build the jmapviewer Debian package.

Thanks and Best Regards,
Felix

[Don-vip]

@The111: the patch looks ok, can we take it ?

[anonymous]

@Don-vip: I am sorry for my slow/lack of response to this message thread. I've been away from my dev PC for some time and dealing with some heavy personal stuff. It may be several weeks before I would be able to respond to this ticket myself. However I do agree with you Don-vip, at a glance the patch looks ok and I have no problems with it being implemented. Sorry again for not being able to offer more help more quickly.

[The111]

The above comment (11) was made by me (The111). I was not logged in apparently. Sorry about that.

[Don-vip]

No problem, everyone deserves holidays :)

[Felix Natter <fnatter@…>]

Could you please consider making a release? We need to package this for Debian :-)

[The111]

@fnatter: Sorry again for the slow response here. Check out my latest commit ​[o29985]. I think/hope this addresses all of your concerns, and I hope it also sits will with the rest of the JOSM/JMapViewer community. I added a svn property called "ReleaseVersion" and set it to 1.0 initially. That property is now used when the build.xml is run to create release zips. Future committers will need to manually rev the version number (this is new) and manually create the release zips (this was always the case). I also incorporated your other small patch from above. I am pretty inexperienced with Ant scripting and svn properties, so hopefully I've done it all correctly.

I'll change this to resolved, but please feel free to re-open if there are still any issues.

[Felix Natter <fnatter@…>]

hi The111,

thanks for the reply. Unfortunately you didn't apply all of my patch.

* 71,75
23 <zipfileset file="build.xml" prefix="jmapviewer-${svn.Revision}"/>
24 <zipfileset file="Gpl.txt" prefix="jmapviewer-${svn.Revision}"/>
25 ! <zipfileset dir="src" includes="/jmapviewer/" prefix="jmapviewer-${svn.Revision}"/>
26 </zip>
27 </target>
28 --- 74,78 ----
29 <zipfileset file="build.xml" prefix="jmapviewer-${svn.Revision}"/>
30 <zipfileset file="Gpl.txt" prefix="jmapviewer-${svn.Revision}"/>
31 ! <zipfileset dir="src" includes="/jmapviewer/" prefix="jmapviewer-${svn.Revision}/src"/>
32 </zip>
33 </target>

Without this, you cannot build the source package:

$ ant build
Buildfile: /home/felix/Freeplane-Debian-Package/jmapviewer/jmapviewer-1.0/build.xml

build:

BUILD FAILED
/home/felix/Freeplane-Debian-Package/jmapviewer/jmapviewer-1.0/build.xml:17: srcdir "/home/felix/Freeplane-Debian-Package/jmapviewer/jmapviewer-1.0/src" does not exist!

Total time: 0 seconds

Could you please make another 1.0 release with the above change?

BTW: I have one question: Are there deprecations compared to the last release
(I think that was svn rev 29618)?

Thanks and Best Regards,
Felix

[The111]

You're right, I did miss the last line of the patch, sorry about that. I blame the trac syntax highlighting for not making it green for some reason. :-)

I just updated the build.xml file again and created new release zip 1.0 in ​​[o29986] and ​​[o29987]. Hopefully resolved now?

And I'm not entirely sure what you mean by deprecations, but in the short time I've worked with JMapViewer (~9 months), I have seen no backwards incompatibilities introduced that I am aware of, and certainly not in the last couple months since svn rev 29618. I am sure @don-vip will correct me if I'm wrong since I think he was the only other recent committer, but it didn't look like any huge changes were made.

[AlfonZ]

Replying to The111:

I blame the trac syntax highlighting for not making it green for some reason. :-)

It seems that trac can handle only unified diffs, build.xml.patch​ looks to be in context format.

[Felix Natter <fnatter@…>]

hi The111,

thanks for the update. Unfortunately, the pack target depends on svn:

$ ant clean build pack

[...]
=> generates JMapViewer_${svnReleaseVersion}.jar (the variable cannot be resolved).

However, when I execute

$ ant clean build svn_info pack

then this fails because I'm not running it from a svn repo.
(it generates files/dirs like JMapViewer_svn: warning: cannot set LC_CTYPE
locale?svn: warning: environment variable LANG is en_US?svn: warning:
please check that your locale name is correct?svn: E155007: ')

I could patch build.xml in the Debian package and remove 'svnReleaseVersion',
but then the JMapViewer-1.0.zip would still not be buildable outside of Debian.
=> I suggest that you remove the "_${svnReleaseVersion}" suffix+infix from the
"pack" target (see attached patch "build.xml.diff", should be 'unified'/-u).

Concerning the the deprecations: This is great! (I've asked on the mailing list some months ago,
and they said that API breakage can happen).

Thanks and Best Regards,
Felix

[Felix Natter <fnatter@…>]

If you apply the above patch ("build.xml.diff") then it might be a good idea to tell users about this
with a comment:

<!-- if you want to build outside of svn, use "ant clean build [pack]" -->

Best Regards,
Felix

[The111]

I'm starting to get confused. You want to build the release zips yourself, outside of SVN? The release zips are already built, which I thought was the whole point of this ticket. Also, I'm not sure in what context you'd have this whole package on your computer but not have it be an SVN repo. I don't know any other practical way to get the entire archive on your machine except through an SVN checkout. If an SVN checkout is not practical, then it makes more sense to just download the release zips, which puts as back at square one.

Also, if I remove the release version from the filename as you are now suggesting, then it would seem that this ticket wouldn't even be solved any more, since the whole point was to put a release version on the zips, right?

I'll admit I am not 100% familiar with your build cases in Debian, which could explain some of my confusion above, but I do think that perhaps it is not the job of the JMapViewer team to make these build cases all work properly. We're maintaining an SVN repo JMapViewer, and I think it makes sense for our updates to work in that context. But I'm relatively new here and would like to hear feedback from other JOSM community members on this.

[stoecker]

Debian is a bit special and I do not always understand what they really want :-)

Do what you think is useful and leave the other stuff to Debian - it's open source, so if they want something changed, they can do themselves always. The wishes of packagers are not always equal to the plans of developers - I know that, as I package a lot for openSUSE.

On rule - The final decision is yours, as you do the work.

[Felix Natter <fnatter@…>]

hi The111,

I am not trying to build the release zips myself, I am only trying to bild the (binary) jar from the source zip
("pack" target).
The idea was that anyone could build the jars himself by running "ant clean build pack" outside of svn,
but of course there is the binary distribution so that is not important!

=> I'll apply the patch within the Debian package, you don't have to do anything,
thanks for your help!

Best Regards,
Felix

[The111]

Ok, I understand better now, thanks for explaining. I think that I can apply that most recent diff with no negative effects to anybody else, if you still want me to. You mentioned that you've patched it on your end so I'm not sure if it's still needed. Let me know either way.

[h.goebel@…]

I tried building from the source zip, but this failed:

$ ant
[...]
svn_info:
     [exec] Result: 1
[...]

Now I have a directory called JMapViewer_svn: E155007: » and one called release/JMapViewer_svn: E155007: ». None if them contain expected results.

[h.goebel@…]

Replying to The111:

I added a svn property called "ReleaseVersion" and set it to 1.0 initially. That property is now used when the build.xml is run to create release zips.

This is a quite uncommon behaviour. This would make every ant build pack to create a "1.0" release until somebody cares changing it.

[Felix Natter <fnatter@…>]

hello,

h.goebel: obviously you cannot run the svn target from a Source ZIP, you should invoke:
$ ant clean build pack

We are talking about making pack do the right thing (patch build.xml.diff), or whether that should be done in packaging.

=>
@The111: please include the patch (and the <!-- if you want to build outside of svn, use "ant clean build [pack]" --> comment)
in order to avoid things like "JMapViewer_${svnReleaseVersion}.jar" as a result of 'and clean build pack'.

Best Regards,
Felix

[Felix Natter <fnatter@…>]

hi Hartmut,

Replying to h.goebel@…:

Replying to The111:

I added a svn property called "ReleaseVersion" and set it to 1.0 initially. That property is now used when the build.xml is run to create release zips.

This is a quite uncommon behaviour. This would make every ant build pack to create a "1.0" release until somebody cares changing it.

What's the problem, you have to store the version number somewhere? Freeplane stores it in version.properties, and IMO it makes
sense to put this in a single file and use it everywhere.

[h.goebel@…]

Replying to Felix Natter <fnatter@…>:

$ ant clean build pack

Well, this does not work either:

[...]
   [jar] Building jar: /tmp/jmapviewer-1.0/JMapViewer_${svnReleaseVersion}.jar
[...]

Obviously the version is not stored in the src-zip.

[h.goebel@…]

Replying to Felix Natter <fnatter@…>:

What's the problem, you have to store the version number somewhere? Freeplane stores it in version.properties, and IMO it makes
sense to put this in a single file and use it everywhere.

I agree, the version has to be stored somewhere. So I was partly wrong.

But
a) The name "ReleaseVersion" leaves the impression of this being a release. This is misleading.
b) A SVN property is not obvious, but hidden. And (as we see in my 27) does not go into the source-zip.

Also IMO, the version should go into a file.

[Felix Natter <fnatter@…>]

hello,

@Hartmut: if I understand you correctly, you want to have a property 'version' in build.xml or in version.properties,
and use that in 'pack' and other targets.

I think that it's good enough to apply patch build.xml.diff​ (remove the version from the jars in 'pack').
=> then you can build from source with "ant clean build pack".
For me it's ok that the jar does not have a version suffix, as it's copied like that into /usr/share/java
(and a link with version suffix is automatically created).

=> so Hartmut, what do you think, can you live with that?

Best Regards,
Felix

[h.goebel@…]

Hi,
Replying to Felix Natter <fnatter@…>:

=> so Hartmut, what do you think, can you live with that?

Yes, for the purpose of building the rpm-package for Mageia, this would be okay. (Seams as if I missed you first.)

@The111: Never the less building from source should create a jar with a proper name.

[Felix Natter <fnatter@…>]

=> so, to summarize:

@The111: please include the patch "build.xml.diff" and add the

<!-- if you want to build outside of svn, use "ant clean build [pack]" -->

comment, in order to avoid things like "JMapViewer_${svnReleaseVersion}.jar" as a result of 'and clean build pack'.
I hope then we can close this thread :-)

Thanks and Best Regards,
Felix

[The111]

Ok, one last try! See ​​​[o29991], hopefully that covers it.

[anonymous]

Building the .jar from teh Source-Zip works fine here. Thanks!

[Felix Natter <fnatter@…>]

hi The111,

you could fix this (create_run_jar target):

<attribute name="Class-Path" value="JMapViewer_${svnReleaseVersion}.jar" />

otherwise the demo jar cannot be run when built like this (I patched this in my package so it's not a requirement for me!).

Please do NOT update ​http://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/1.0/JMapViewer-1.0-Source.zip
as I am already referencing it in my Debian package!!!

Thanks and Best Regards,
Felix

[The111]

Good catch Felix. Fixed in ​​​​[o29993] and [o29994]. I rolled the version to 1.01 so the 1.0 source zip is unchanged.

[Felix Natter <fnatter@…>]

hi The111,

One last thing: you cannot build with LANG=C due to the UTF-8 encoding of the source files.

This can be fixed like this:

<target name="build">

<javac srcdir="src" destdir="bin" source="1.6" target="1.6" debug="true" includeantruntime="false" encoding="UTF-8">

<include name="org/openstreetmap/gui/jmapviewer/" />

</javac>

(add encoding="UTF-8")

Thanks and Best Regards,
Felix

[The111]

Ok, I created [o29998] to address that.