Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#3305 closed defect (fixed)

Version is UNKNOWN

Reported by: sbrunner Owned by: stoecker
Priority: normal 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 4 years ago by plaicy

  • Owner changed from team to sbrunner
  • Status changed from new to needinfo

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 4 years ago by stoecker

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

comment:3 follow-up: Changed 4 years ago by stoecker

  • Owner changed from sbrunner to Gubaer
  • Status changed from needinfo to new

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 4 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 4 years ago by sbrunner

Thanks stoecker for the revert !

comment:6 in reply to: ↑ 3 Changed 4 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 4 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 4 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 follow-up: Changed 4 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 4 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 4 years ago by Gubaer

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:12 Changed 4 years ago by stoecker

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 4 years ago by Gubaer

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:14 Changed 4 years ago by stoecker

Changed page to DevelopersGuide/CreateBuild.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed .
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.