Bug 31287 - Use simpler-format buildnumber for xml/**/build.xml
Use simpler-format buildnumber for xml/**/build.xml
Status: VERIFIED FIXED
Product: xml
Classification: Unclassified
Component: Code
3.x
PC Linux
: P1 (vote)
: 3.x
Assigned To: _ pkuzel
issues@xml
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-20 22:36 UTC by Jesse Glick
Modified: 2003-07-10 10:47 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments
Requested patch (11.04 KB, patch)
2003-02-20 22:38 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-02-20 22:36:12 UTC
This patch just uses a "buildnumber" for xml
module impl versions consisting of the date, no
time. Probably there is no reason for impl
dependencies to have granularity less than one day
- even dev alpha NBMs are released at most once
per day.

Benefits:

1. NB build no longer fails under JDK 1.3 due to
line length in xml/tools/manifest.mf. The 12-char
impl versions were not working; the new 8-char
versions do work.

2. Incremental builds of some xml modules made
within the same day of the last clean build of the
others will be fine. With the current sources, any
time you do not clean & build every xml module
together, you get garbage - most of the modules
cannot be installed, and it is not obvious why
(even RE folks had to ask for help).

3. Impl version dependencies will not be sensitive
to NB-vs.-S1S build environment (since
nb_all/nbbuild/build.xml and the S1S build starter
use different formats for ${buildnumber}). This
also means that problem #1 can be solved once,
rather than testing in lots of different environments.

Overall I still advise that impl dependencies be
manually updated when there are significant code
changes, rather than relying on generated numbers.
But this patch is a compromise - a very easy
change with no maintenance overhead that gives
some of the benefits and predictability of
manually updated impl dependencies.

Please consider applying it quickly, since in the
meantime the build is *broken* for developers
using the recommended way of testing their sources:

1. Set path and all environment vars to point to
JDK 1.3.1.

2. Use Ant 1.4.1.

3. Run nbbuild/build.xml real-clean nozip-check.

4. Run xtest/instance/build.xml cleantests runtests.

Step #3 fails with a very mysterious error,
probably too hard to correct yourself if you do
not know about the JRE bug. This is not good.
Comment 1 Jesse Glick 2003-02-20 22:38:26 UTC
Created attachment 9069 [details]
Requested patch
Comment 2 _ pkuzel 2003-02-21 10:24:32 UTC
I'm not fully certain about xmlbuildnumber <tstamp>-ed property
lifetime. It must not be rewritten once initialized in project. Manual
is silent about it.

It's not a big issue as it can happen only at midnight.
Comment 3 _ pkuzel 2003-02-21 10:46:53 UTC
Discussed with Michal and he proposed to change default build number
for whole build to the "yyyyMMdd". Several modules use implementation
dependency on XML modules and <tstamp> always rewrite all properties.
Comment 4 Jesse Glick 2003-02-21 15:32:33 UTC
That works too, I guess.
Comment 5 _ pkuzel 2003-02-21 16:30:46 UTC
I can confirm.

export LANG=C
jdk1.3.1_06
ant real-clean; ant
[snip]
BUILD SUCCESSFUL

Comment 6 Jesse Glick 2003-02-21 16:51:09 UTC
Build works for me too. Thanks Michal.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo