Modify

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3305 closed defect (fixed)

Version is UNKNOWN

Reported by: sbrunner Owned by: stoecker
Priority: normal Milestone:
Component: Core Version: tested
Keywords: Cc:

Description

Hello !

I make the package for JOSM in Ubuntu and with the latest tested version The version if I don't rollback this diff (line 59-67):
http://josm.openstreetmap.de/changeset?old_path=%2Ftrunk%2Fsrc%2Forg%2Fopenstreetmap%2Fjosm%2Factions%2FAboutAction.java&old=1879&new_path=%2Ftrunk%2Fsrc%2Forg%2Fopenstreetmap%2Fjosm%2Factions%2FAboutAction.java&new=1598

Thanks in advance to put again a working version.

CU

Stéphane

Attachments (0)

Change History (14)

comment:1 Changed 10 years ago by plaicy

Owner: changed from team to sbrunner
Status: newneedinfo

I can not reproduce this.

  1. I downloaded http://josm.openstreetmap.de/josm-tested.jar (md5 97f0a02f861124a2167d9b3c50ccd86e) and start it with "java -jar josm-tested.jar". Then I open the about dialog and it prints version 1981.
  1. I downloaded the sources of 1981 using svn and compile. Result is the same as for josm-tested.jar
  1. I extracted josm-tested.jar ("jar xf josm-tested.jar"): I contains a valid "REVISION" file.

comment:2 Changed 10 years ago by stoecker

(In [1986]) see #3305 - version set to UNKNOWN

comment:3 Changed 10 years ago by stoecker

Owner: changed from sbrunner to Gubaer
Status: needinfonew

I reverted the related change. The getResource call will not catch the correct manifest file.

Karl, this was your change. Any better solutions? :-)

comment:4 Changed 10 years ago by sbrunner

Hello,

First of all thanks for your quick responds.

I done:
svn co josm.openstreetmap.de/browser/trunk -r 1981 josm-test
cd josm-test
ant dist
java -jar dist/josm-custom.jar

I don't have any josm-tested.jar !
And the display version is UNKNOWN !
But I try with the latest version and it seem to be OK !

When I see this kind of thing I have the impression that the developer who made the release will do it in his own stream an checkin later ! And than it's difficult ton integrate in a distribution later ...

Stéphane

comment:5 Changed 10 years ago by sbrunner

Thanks stoecker for the revert !

comment:6 in reply to:  3 Changed 10 years ago by Gubaer

Owner: changed from Gubaer to stoecker

Replying to stoecker:

I reverted the related change. The getResource call will not catch the correct manifest file.

Karl, this was your change. Any better solutions? :-)

Yes.

Revert your revert and make sure your private build script for josm-tested.jar becomes part of the SVN respository such that Stéphane and others can build their own distributions which will include a REVISION file (which is not generated with the current "dist" target in build.xml but which seesm to be generated with your private build scripts for josm-tested.jar).

You should also revert your revert because what you've reverted doesn't seem to run in an applet environment. As plaicy pointed out above what has been in place before works fine with a standard build, according to my tests in an applet environment too.

comment:7 Changed 10 years ago by anonymous

No. A plain revert is no solution. The getResource for MANIFEST definitely fails. On my system it took a MANIFEST somewhere out of the Java installation path instead of the file from the josm jar file.

Thus instead of a revert we would need to drop MANIFEST reading at all and I don't like that solution.

Regarding REVISION - It is created by "LC_ALL=POSIX svn info >REVISION".
For Debian nevertheless I would suggest another way to create that file, so we can see which build it is in the bug reports (mainly only the Revision line is interesting, adding other lines like build date and System: Debian xxx would be helpful for BugReport-purposes).

Adding such a REVISION file should be a matter of "echo" and "zip" calls and I don't like to add it to the build scripts, as then we would loose an easy way to find out which build was used.

comment:8 Changed 10 years ago by Gubaer

Thus instead of a revert we would need to drop MANIFEST reading at all and I don't like that solution.

That's what I'd propose, though: drop MANIFEST reading. It's no use because there's a revision file.
Otherwise try one of the hacks described here, but I suggest to avoid

clazz.getProtectionDomain().getCodeSource().getLocation().toString()

because it doesn't seem to work in an applet environment (see also your ticket #3142).

Adding such a REVISION file should be a matter of "echo" and "zip" calls and I don't like to add it to the build scripts, as then we would loose an easy way to find out which build was used.

The problem is that people like Stéphane don't *know* that the ant dist target doesn't create a "distribution". Like Stéphane there seem to be people who create redistributable builds beside you. You can easily create another target (say, "make-really-distributable-distribution" ;-)) and add it to the build.xml such that everybody can run it if he or she feels this is necessary. The existing "dist" target can stay as it is. And a comment on the top of build.xml can explain that local builds for dev and test should be built with ant dist, redistributable builds with ant make-really-distributable-distribution,though.

comment:9 Changed 10 years ago by stoecker

Yes, but the problem is, that I want a "make-really-distributable-distribution-with-special-build-flavour". Ortherwise the normal build which produces a "SVN" version is just fine.

We can fix the build.xml, so it creates a slightly different REVISION file than the one for the release (e.g. containing system type, SVN info and other useful build information) and drop MANIFEST reading.

Adding a comment how to improve that for distribution-builds would be helpful as well, but i doubt somebody will read it.

comment:10 in reply to:  9 Changed 10 years ago by Gubaer

We can fix the build.xml, so it creates a slightly different REVISION file than the one for the release (e.g. containing system type, SVN info and other useful build information) and drop MANIFEST reading.

Perfect for me.

... but i doubt somebody will read it.

I see what you mean ;-) however, in my experience it's still easier to *point* people to this comment if they have questions than to explain the same issue over and over in emails or trac tickets.

comment:11 Changed 10 years ago by Gubaer

Resolution: fixed
Status: newclosed

(In [2358]) fixed #3305: Version is UNKNOWN
fixed #3429: created_by=* includes the wrong language when uploading from a new layer

comment:12 Changed 10 years ago by stoecker

Resolution: fixed
Status: closedreopened

You also dropped the ability to detect if local builds or not are used by dropping the SVN attribute. The JOSM version string passed to web-application should contain this in any case, as local version can have much different failures than offical versions.

comment:13 Changed 10 years ago by Gubaer

Resolution: fixed
Status: reopenedclosed

(In [2369]) fixed #3305: Version is UNKNOWN
see also howto create a JOSM build?

comment:14 Changed 10 years ago by stoecker

Changed page to DevelopersGuide/CreateBuild.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain stoecker.
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.