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 141414 - "Can not change modification date of read-only file [.*]\lib\nblibraries-private.properties"
Summary: "Can not change modification date of read-only file [.*]\lib\nblibraries-priv...
Status: RESOLVED WONTFIX
Alias: None
Product: projects
Classification: Unclassified
Component: Ant Project (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P3 blocker (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-23 20:18 UTC by thealchemist
Modified: 2008-08-25 21:39 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description thealchemist 2008-07-23 20:18:11 UTC 
== Description ==

Because of the SCM we are using, we have some NetBeans projects that are in directories that are entirely read-only. 
Specifically, I have a few projects--some regular Java Class projects and a Web Application project--and if you try to
Build, you will get:

C:\Documents and Settings\User\My Documents\Documents\p4\depot\mainline\MyProject\nbproject\build-impl.xml:45: Can not
change modification date of read-only file C:\Documents and Settings\User\My
Documents\Documents\p4\depot\mainline\MyProject\lib\nblibraries-private.properties
BUILD FAILED (total time: 0 seconds)

Since I'm not changing the libraries that these projects depend on, I don't see why NB couldn't compile the project
without having those files writable.

== Workaround ==
Make all your lib/nblibraries.properties lib/nblibraries-private.properties files writable.
Comment 1 Peter Pis 2008-07-29 10:38:01 UTC 
Reassigning to projects.
Comment 2 Tomas Zezula 2008-08-20 14:32:15 UTC 
Caused by shared libraries, namely the following code:
<touch file="${{libraries.{position()}.dir}}/${{libraries.{position()}.basename}}-private.properties"/> <!-- has to exist, yuck -->

Correctly the private-properties should be loaded only when they exist, it requires split of the -init-libraries into several targets
where the target loading private props has to be conditional.
Something like this in the build-impl.xml:


    <target depends="-pre-init,-init-private,-init-libraries-common,-init-libraries-private,-init-libraries-shared" name="-init-libraries"/>
    
    <target depends="-pre-init,-init-private" name="-init-libraries-common">
        <property location="../lib/nblibraries.properties" name="libraries.1.path"/>
        <dirname file="${libraries.1.path}" property="libraries.1.dir.nativedirsep"/>
        <pathconvert dirsep="/" property="libraries.1.dir">
            <path path="${libraries.1.dir.nativedirsep}"/>
        </pathconvert>
        <basename file="${libraries.1.path}" property="libraries.1.basename" suffix=".properties"/>
        <condition property="hasLibrariesPrivateProps">
            <available file="${libraries.1.dir}/${libraries.1.basename}-private.properties"/>
        </condition>
    </target>
    <target depends="-pre-init,-init-private,-init-libraries-common" if="hasLibrariesPrivateProps" name="-init-libraries-private">
        <loadproperties srcfile="${libraries.1.dir}/${libraries.1.basename}-private.properties">
            <filterchain>
                <replacestring from="$${base}" to="${libraries.1.dir}"/>
            </filterchain>
        </loadproperties>
    </target>
    <target depends="-pre-init,-init-private,-init-libraries-common,-init-libraries-private" name="-init-libraries-shared">
        <loadproperties srcfile="${libraries.1.path}">
            <filterchain>
                <replacestring from="$${base}" to="${libraries.1.dir}"/>
            </filterchain>
        </loadproperties>
    </target>


Unfortunately the shared libraries allow more references to lib folders, so the xslt will need to generate
more -init-libraries-private and -init-libraries-shared targets, pretty ugly.
It will be trivial to fix when we allow scripting (javascript) in generated build scrips.
Comment 3 David Konecny 2008-08-25 05:09:33 UTC 
<touch file="${{libraries.{position()}.dir}}/${{libraries.{position()}.basename}}-private.properties"/> <!-- has to
exist, yuck -->

Jesse, any reason why <touch> was used instead of what Tomas proposes?
Comment 4 Tomas Zezula 2008-08-25 10:23:56 UTC 
I think the touch is much more simpler unfortunately it causes problems on some VCSs, the suggested fix becomes complicated when there is more shared 
libs folders.
Comment 5 Jesse Glick 2008-08-25 16:17:14 UTC 
Right, the use of <touch> is much simpler.

nblibraries-private.properties should not be versioned, i.e. it should be in the ignore list of the SCM. Does Perforce
make even ignorable files r/o? I don't see how you could do a build at all in such a case (you could not even create the
build/ directory).
Comment 6 thealchemist 2008-08-25 16:28:58 UTC 
I had no idea nblibraries-private.properties isn't meant to be in source control.  In that case, I can just tell
Perforce to ignore it (via .p4ignore, akin to .cvsignore), and this issue becomes moot.

Is there a list of files from nbprojects/ that should and should not be under source control?  That would solve a bunch
of these issues, me thinks.
Comment 7 Jesse Glick 2008-08-25 16:39:21 UTC 
*-private.properties, nbproject/private/, build/, dist/, target/, etc. (variations according to project type) are
supposed to be ignorable. For a supported SCM such as CVS or SVN the IDE automatically registers such entries in the
SCM's ignore list when they appear in an open project.
Comment 8 David Konecny 2008-08-25 21:39:50 UTC 
In such a case I would keep script as is.