Modify

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#8747 closed enhancement (fixed)

[Patch] Enhance JMapViewer release system

Reported by: h.goebel@… Owned by: The111
Priority: minor Milestone:
Component: JMapViewer Version: latest
Keywords: build Cc: fnatter@…

Description

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!

Attachments (4)

build-source-zip.patch (1.2 KB) - added by h.goebel@… 6 years ago.
build-source-zip.2.patch (1.2 KB) - added by h.goebel@… 6 years ago.
fixed version - first one did use wrong timestamp
build.xml.patch (1.1 KB) - added by Felix Natter <fnatter@…> 6 years ago.
patch against build.xml from jmapviewer-29618
build.xml.diff (767 bytes) - added by Felix Natter <fnatter@…> 6 years ago.

Download all attachments as: .zip

Change History (43)

comment:1 Changed 6 years ago by Don-vip

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 6 years ago by h.goebel@…

Cc: h.goebel@… added
Resolution: invalid
Status: closedreopened

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.

Changed 6 years ago by h.goebel@…

Attachment: build-source-zip.patch added

Changed 6 years ago by h.goebel@…

Attachment: build-source-zip.2.patch added

fixed version - first one did use wrong timestamp

comment:3 Changed 6 years ago by h.goebel@…

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

comment:4 Changed 6 years ago by Don-vip

Keywords: build added
Priority: majorminor
Summary: Source release is missingEnhance JMapViewer release system
Type: defectenhancement

comment:5 Changed 6 years ago by Don-vip

Cc: h.goebel@… removed
Summary: Enhance JMapViewer release system[Patch] Enhance JMapViewer release system

comment:6 Changed 6 years ago by 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

comment:7 Changed 6 years ago by The111

Resolution: fixed
Status: reopenedclosed

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.

Changed 6 years ago by Felix Natter <fnatter@…>

Attachment: build.xml.patch added

patch against build.xml from jmapviewer-29618

comment:8 Changed 6 years ago by Felix Natter <fnatter@…>

Cc: fnatter@… added
Resolution: fixed
Status: closedreopened

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

comment:9 Changed 6 years ago by 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

comment:10 Changed 6 years ago by Don-vip

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

comment:11 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by The111

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

Last edited 6 years ago by The111 (previous) (diff)

comment:13 Changed 6 years ago by Don-vip

No problem, everyone deserves holidays :)

comment:14 Changed 6 years ago by Felix Natter <fnatter@…>

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

comment:15 Changed 6 years ago by The111

Resolution: fixed
Status: reopenedclosed

@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'll change this to resolved, but please feel free to re-open if there are still any issues.

Version 0, edited 6 years ago by The111 (next)

comment:16 Changed 6 years ago by Felix Natter <fnatter@…>

Resolution: fixed
Status: closedreopened

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

comment:17 Changed 6 years ago by The111

Resolution: fixed
Status: reopenedclosed

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.

comment:18 in reply to:  17 Changed 6 years ago by 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.

comment:19 Changed 6 years ago by Felix Natter <fnatter@…>

Resolution: fixed
Status: closedreopened

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

Changed 6 years ago by Felix Natter <fnatter@…>

Attachment: build.xml.diff added

comment:20 Changed 6 years ago by 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

comment:21 Changed 6 years ago by 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 us back at square one... they are already built.

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 for 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.

Last edited 6 years ago by The111 (previous) (diff)

comment:22 Changed 6 years ago by 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.

comment:23 Changed 6 years ago by 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

comment:24 Changed 6 years ago by 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.

comment:25 Changed 6 years ago by 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.

comment:26 in reply to:  15 ; Changed 6 years ago by 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.

comment:27 Changed 6 years ago by 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

comment:28 in reply to:  26 ; Changed 6 years ago by 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.

comment:29 in reply to:  27 Changed 6 years ago by 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.

comment:30 in reply to:  28 Changed 6 years ago by 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.

comment:31 Changed 6 years ago by 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

comment:32 in reply to:  31 Changed 6 years ago by 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.

comment:33 Changed 6 years ago by 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

comment:34 Changed 6 years ago by The111

Resolution: fixed
Status: reopenedclosed

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

comment:35 Changed 6 years ago by anonymous

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

comment:36 Changed 6 years ago by 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

comment:37 Changed 6 years ago by The111

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

comment:38 Changed 6 years ago by 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

comment:39 Changed 6 years ago by The111

Ok, I created [o29998] to address that.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain The111.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.