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 103933 - add clone option to project configurations
Summary: add clone option to project configurations
Status: NEW
Alias: None
Product: javame
Classification: Unclassified
Component: Build System (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: Petr Suchomel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-14 18:16 UTC by mkochano
Modified: 2009-10-01 13:28 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mkochano 2007-05-14 18:16:19 UTC
I think about some very useful (in my opinion) option that should be added to
projects configurations - clone configuration. There should be an option, which
would let us create new configurations from a set of "master builds"
configurations by cloning already compiled builds only with changing name of the
jar/jad. For eg. it would be great if having "standard_176x208_nokia_keys"
configuration would let us to make "nokia_6630" "nokia_6600" and so on, just by
cloning this configuration. There should be some additional checkbox saying that
this is clone configuration and list box to choose "master" for that clone. List
would be uneditable if checkbox "clone" is not checked. Cloned configuration has
 just differend name of jar, jad
and maybe additional jad attributies. After deselecting checkbox or something
like that, this configuration could become "normal" (not cloned) configuration
if some other changes are needed, but it should inherit all abilities from the
configuratin it was cloned from. Cheers - hope that didnt make You laught a lot :DD
Comment 1 Milan Kubec 2007-05-15 08:11:00 UTC
Reassigning since mobility has its own implementation of project configurations.
Comment 2 Adam Sotona 2007-05-17 06:47:37 UTC
Correct me if I am wong.
I think similar requests are to support configuration inheritance from other
then Default Configuration or to support multiple configuration inheritance.
Technically the most possible is to implement tree structure of configurations
inheritance. But even that feature still has a lot of implementation difficulties.
Would the configurations inheritance tree satisfy your requirements?
Comment 3 mkochano 2007-05-17 08:27:19 UTC
I think about something very simple, right now we have our own tool for creating
builds from set of master builds. We have couple of already compiled "master
builds" and this tool "matches" master build to proper "destination build" by
just copying .jar and .jad with different name and changing some .jad values.
For eg. You can have "standard_sony_176x220" build compiled and out of this You
can make "SonyEricssonK700i", "SonyEricssonK750i", etc. by just copying jar jad
changing their names and manifest values. Having for eg. 10 "master builds" can
give us lets say 40 or more "destination builds". Its important to copy them not
recompile all over again after every change cause it takes a looot of time (for
eg. for 300 "destination builds"). I was thinking about checkbox that would say
"this build is a copy of another build with manifest values and filename
changed", and list box to set "master build", and jar name field editable to
enter new value. After deselecting checkbox configuration would become "normal"
configuration "Duplicated" from another configuration like it is now.