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 170667 - javacard.xml should be read only w/ comment noting that changes will be clobbered
Summary: javacard.xml should be read only w/ comment noting that changes will be clobb...
Status: RESOLVED INCOMPLETE
Alias: None
Product: javacard
Classification: Unclassified
Component: Java Card (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords:
Depends on: 170671
Blocks: 170636
  Show dependency tree
 
Reported: 2009-08-19 18:20 UTC by _ tboudreau
Modified: 2010-03-22 14:05 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
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 _ tboudreau 2009-08-19 18:20:19 UTC 
The javacard.xml file for Java Card projects should be non-editable (using editor magic comments) and should contain a comment stating that it is 
regenerated frequently and any user-made changes will be clobbered.
Comment 1 _ tboudreau 2009-08-19 18:24:52 UTC 
Anki, questions for you:
1.  If we are generating javacard.xml in the build process, why have it in the source code at all?  That would solve this problem much more cleanly.
2.  If we are generating javacard.xml, and we keep the copy in the project source code, what code updates it, why, how and when?  This is particularly an issue 
for source control:
  a.  It will generate spurious diffs and the build script modifies the source copy, then it will show up as a modified file when the user commits their project-
wide changes to version control
  b.  If we make the file non-editable in the NetBeans editor, and a user does a merge w/ a locally modified copy and this generates merge conflicts, the user 
will have no way to resolve the conflicts because they can't edit the file

Would much prefer we simply generate the file into the build dir, and get rid of the source version if users are not supposed to be editing it anyway.
Comment 2 _ tboudreau 2009-08-19 18:35:03 UTC 
Also:  Should the javacard.xml be visible in the template and editable for non-classic projects?
Comment 3 _ tboudreau 2009-09-02 23:22:34 UTC 
I'm thinking, if we are going to generate the javacard.xml during the build process, it simply should not be visible at
all in the files tree - it should only exist in ${build.classes.dir} and the resulting JAR file.  That would be the
cleanest way to have it be non-user-editable - have it not exist.
Comment 4 msmirnov 2010-03-22 14:05:52 UTC 
I agree that we don't need javacard.xml (for classic applets only) at all. It isn't used during CAP generation and it actually shouldn't be neither in META-INF directory nor in build/META-INF directory. It is present in generated CAP file only. Accordingly Classic Applet Project shouldn't generate this file or generate it with comment that it won't be used.

For non-classic projects this file is essential and should be editable.