This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 38265 - Need to use proper impl deps
Summary: Need to use proper impl deps
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Action Items (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: tasklist-issues@contrib
URL: http://www.netbeans.org/download/dev/...
Keywords: ARCH
: 38345 38487 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-22 13:37 UTC by Jesse Glick
Modified: 2004-03-02 08:47 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-12-22 13:37:43 UTC
Currently the tasklist modules have complex impl
interdependencies based on build number, which
makes it effectively impossible to update daily
builds of these NBMs from the Alpha update center
- the dependencies generally fail.

They should switch to using
OpenIDE-Module-Build-Version (see URL) for the
actual build version, and a special token of your
choice for the impl version. For example, there
could be a file tasklist/build.properties
containing just the line

impl.version=22dec03

and every submodule using impl deps could
substitute e.g. @IMPL_VERSION@ in manifest.mf
(whether in OpenIDE-Module-Implementation-Version,
or OpenIDE-Module-Module-Dependencies, or both)
with ${impl.version}.

Then all you need to do is change ${impl.version}
whenever you make a potentially incompatible
change in private APIs. When you do this, be sure
to also increment the spec version in all
submodules making use of this version, so that AU
will get the new NBMs.
Comment 1 _ pkuzel 2003-12-22 17:56:09 UTC
Possible enhancement: for {impl.version} one can use a number (and
increment it), then declare dependent modules spec versions ala
1.x.@IMPL_VERSION@. Incrementing {impl.version} also increments spec
version of dependent modules (those aware of the property).
Comment 2 Jesse Glick 2003-12-22 18:10:43 UTC
Yes, I like that idea.
Comment 3 _ pkuzel 2004-01-08 18:14:40 UTC
Done.
Comment 4 Jesse Glick 2004-01-08 19:30:42 UTC
Looks good, except you forgot to add

OpenIDE-Module-Build-Version: @BUILD_NUMBER_SUBST@

to each manifest.

Also in the build scripts, probably the second filter in e.g.

<filter filtersfile="../version.properties"/>
<filter token="tl.suggestions.spec" value="${tl.suggestions.spec}"/>

is redundant: version.properties already defines
${tl.suggestions.spec}. Then you can also delete

<property file="../version.properties"/>

if nothing else in the build script is using these properties.

BTW using the standalone <filter/> task is not a good idea - best to
embed it in the task that will use the filter, e.g.

<copy file="manifest.mf" tofile="manifest-subst.mf">
    <filterset>
        <filtersfile file="../version.properties"/>
        <filter token="BUILD_NUMBER_SUBST" value="${buildnumber}"/>
    </filterset>
</copy>

Some day we will update all build scripts to use the preferred style.
Comment 5 _ pkuzel 2004-01-09 13:29:36 UTC
*** Issue 38345 has been marked as a duplicate of this issue. ***
Comment 6 _ pkuzel 2004-01-09 13:39:03 UTC
*** Issue 38487 has been marked as a duplicate of this issue. ***
Comment 7 _ pkuzel 2004-01-26 18:39:33 UTC
the build version attribute added
Comment 8 Milan Kubec 2004-03-02 08:47:33 UTC
Please, reporter, could you verify fixed issues. Thanks a lot.