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 153542 - Ability to override or hook some targets in build-impl.xml for mobility projects
Summary: Ability to override or hook some targets in build-impl.xml for mobility projects
Status: RESOLVED FIXED
Alias: None
Product: javame
Classification: Unclassified
Component: Build System (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Radko Najman
URL:
Keywords:
Depends on: 138228
Blocks: 162137
  Show dependency tree
 
Reported: 2008-11-20 14:33 UTC by Radko Najman
Modified: 2009-05-20 09:01 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Proposed patch (12.13 KB, patch)
2009-05-13 10:48 UTC, Radko Najman
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Radko Najman 2008-11-20 14:33:17 UTC
Java ME SDK 3.0 UI which is based on NB and Mobility project type defines a few own ant targets. We would like to have a
possibility to update a project with these targets when the projects is open and these targets are not included in it.
Comment 1 _ tboudreau 2008-11-20 16:33:39 UTC
Adding dependency on issue 138228 - patches for this add project update helper.

BUT:  Radko, as we discussed last week:
If we can avoid it, I really don't want to have build-impl.xml wars between your tool and NetBeans (i.e., someone opens
a mobility project in your tool and it creates a diff in the build-impl.xml;  someone opens it in NetBeans and it
changes it back, and so forth - build-impl.xml is very hard to read, and it will just scare people.

So there are two things we can do to solve this (and we will probably do both of them):
1.  Where you need some target in the standard build-impl.xml, and it will not hurt anything if it is never used when
the project is opened in NetBeans, give me the *exact text* of that target and we will simply add it to the standard
mobility project's build-impl.xml.

2.  If you need to override some targets, or needs a hook to run before or after some target in the standard
build-impl.xml, your tool should *not* change the build-impl.xml.  Instead, it should generate a file *beside*
build-impl.xml (maybe don't make it sharable, so it won't interfere with the same project opened in NetBeans by some
other user?).  For now, let's call that file toolbar.xml.  

Here is how it will work:
 - build-impl.xml will define the targets you need.  
 - build-impl.xml will <import file="toolbar.xml" optional="true"/>
 - toolbar.xml will override the targets
    - if toolbar.xml is not there, a dummy target in build-impl.xml will run
    - if toolbar.xml is there, the target in that file will run

Here is a simple example of how this works to try it out.  Take a j2seproject.  Edit its build.xml and add this:
    <import file="toolbar.xml" optional="true"/>
    
    <target name="compile" depends="toolbar.-precompile">
        <echo message="I am 'compile'"/>
    </target>
    
    <target name="toolbar.-precompile">
        <echo message="I am local toolbar.-compile"/>
    </target>

Now create a file called toolbar.xml next to build.xml.  It looks like this:
    <target name="-precompile">
        <echo message="I am toolbar.-precompile in toolbar.xml"/>
    </target>

Try running the compile target.  Then rename toolbar.xml to something else and run the compile target again.  It is easy
to override things this way and you do not have to make changes to build-impl.xml.

I don't want to even consider having your tool change the build-impl.xml unless there is something which is really
impossible to do by one of these two approaches.

So what I need here is a list of what targets you need - that is:
 - What targets in build-impl.xml do you want to override
 - What targets do you want to add to build-impl.xml
 - What pre- or post-hooks do you need for existing targets in build-impl.xml

Comment 2 _ tboudreau 2008-11-20 16:38:42 UTC
Adding Jesse to cc, as our resident Ant expert.  Jesse, is the proposed solution here working by accident or by design?  

That is, 
 - if a.xml optionally imports b.xml, 
 - b's project name is "foo"
 - a defines target foo.bar
 - b defines target bar

then it is by design that b's bar target runs if b.xml exists, and that a's bar target runs if it does not.  I just want
to be sure this precedence will not break on some future version of Ant.  Guessing it won't but would be good to confirm.
Comment 3 Jesse Glick 2008-11-20 19:52:16 UTC
First of all, you should be using AntBuildExtender.

Second, the described override system seems too magical. Just use the same, simple target name in both a.xml and b.xml
and it should be fine. (A target present in an imported script is always overridden by a target with the same name in
the importing script.)
Comment 4 _ tboudreau 2008-11-26 15:09:34 UTC
Radko, I'm still waiting for a list of what targets you actually need to override/replace in build-impl.xml
Comment 5 Radko Najman 2008-12-01 10:30:23 UTC
Tim, we don't override existing targets. We define new own targets. I sent their list in a private email last week.
Comment 6 _ tboudreau 2008-12-02 20:41:36 UTC
Per discussion with Radko, reassigning.  Radko will add the targets they need into the standard mobility build script; 
if they are unused in NetBeans, that is still preferable to generating diffs in people's projects depending on what tool
last opened the project.
Comment 7 Radko Najman 2009-05-13 10:48:41 UTC
Created attachment 82027 [details]
Proposed patch
Comment 8 Quality Engineering 2009-05-20 07:32:08 UTC
Integrated into 'main-golden', will be available in build *200905200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/48d54b9d58dd
User: rnajman@netbeans.org
Log: #153542 - Ability to override or hook some targets in build-impl.xml for mobility projects
Adding Java ME SDK specific ant targets. They are called only when the project is running in Java ME SDK, otherwise not.
Reviewed by Tim.
Comment 9 Radko Najman 2009-05-20 09:01:39 UTC
Proposed patch applied.