[josm-dev] [patch] Build process: Ant does not find svn executable

[Frederik Ramm]

Hi,

Stephan wrote:
> Why not? What is the benefit of not submitting the patch? That 
> discussion should have been done weeks ago as I originally created the 
> ticket. Now I already invested time into fixing the problem.

As far as I understand, your patch requires additional external 
libraries to be copied into our SVN, am I wrong? This is not something 
that I would categorically reject but any such inclusion, in my eyes, 
has to be carefully considered. And all this just for the benefit of 
allowing people to build the jar file from inside Eclipse on systems 
where they don't have SVN installed. Or is that a misunderstanding on my 
part?

> Why not support multiple platforms? Just because it's "cool" to be a 
> Linux-only developer? Why to enforce the need for a svn executable if 
> support is already in eclipse? Should be the same for Linux. Or is there 
> no subversive plugin?

My suggestion was to remove the whole version numbering mechanism from 
the build.xml, including the call to the SVN binary. This would mean 
that if someone builds their own josm.jar they would have to set the 
version number manually somehow (or we make the build.xml always assume 
9999 or whatever), but I don't view this as a big problem; JOSM .jar 
files that get into wider circulation will always be built centrally on 
the JOSM build machine at openstreetmap.de, where build.xml is not used 
at all, and people doing their own development will usually not bother 
to build a .jar at all, they will run the softwar from inside their 
development environment anyway.

What I'm suggesting is not "drop build support for non-linux platforms" 
but instead "drop automatic version number inclusion from build.xml for 
all platforms".

> I must admit I would consider that what you describe correct behavior. 
> Because the build uses the LOCAL revision. As long as you don't update 
> you still have that one.

> Consider you have revision 1136, do some changes. In the meantime 
> another one changes and submits 1137. Now you submit your change. So it 
> is based on SVN 1136 and that should be in the version string. 1138 
> would be wrong. even if that is the revision of your change, you don't 
> have the files updated from 1137.

Granted, but 1136 is just as wrong - you will build something that 
claims to be 1136 but is not the same as what someone else would build 
from 1136.

> What about extending the build process? We could simply add a task to 
> update the depot. Maybe a "dist-latest" target that depends on "update"?
> svnant has the possibility to query for files with conflicts. That check 
> might be interesting after running an update.

I would rather *reduce* the build process; in my eyes it should not have 
*anything* to do with SVN.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"