Bug 46483

subcomp->project

Created attachment 16587 [details]
A modification to the freeform Actions class, to support compile/run/debug single, and debug fix.

The above patch ensures that when the actions Compile File, Run File,
Debug File or Debug Fix are used, the following properties are set:

context.path - The relative path to the selected file.
context.base - The above with .java stripped off.
context.class - The above converted to a FQ class name.

To enable the actions in the IDE, something like the following must be
added to project.xml:

 <ide-actions>
   :
   <action name="compile.single">
     <target>compile-single</target>
   </action>
   <action name="run.single">
     <target>run-single</target>
   </action>
   <action name="debug.fix">
     <target>debug-fix</target>
   </action>
   <action name="debug.single">
     <target>debug-single</target>
   </action>
 </ide-actions>

Compiling a single JSP file is not handled by this patch.

Created attachment 16589 [details]
Replacement for above patch. Also handles JSP and sets context.root.

Already had plans to add support for context-sensitive actions, though
not using quite the same approach taken in this patch. Note
boundActions type in the schema (needs further definition). Should be
able to support any c-s action uniformly, without needing to hardcode
particular action names in the module.

BTW: patches can't be accepted without a JCA signature. Also -u format
is preferred since it is more robust if sources have changed a bit
since when the patch was made. More details:

http://www.netbeans.org/community/contribute/patches.html

I was also thinking about a similar problem, and I had yet another
solution in mind.

The truth is, most real life Ant projects that people use don't have
targets set up and ready for single file compilation, debugging,
fix-and-continue, JSP compilation, and sometimes even for things like
deployment to the server. These actions are IDE-specific, and are not
required for command-line use of the Ant script. 

So the IDE will not only need to make sure that right parameters are
passed to the Ant script, but also that the right targets exist
(although users can work around this by manually copying targets from
a dummy IDE-created script). So the IDE should have the capability to
generate the missing Ant targets for freeform projects - probably to a
separate script, so the original user-supplied script is not polluted
by IDE implementation details.

Thoughts?

Re. generating targets needed for IDE-oriented actions: interesting
idea, but quite off-topic here. In the short term, for D, it must be
possible when declaring an action to name properties to pass to the
script derived somehow from the selection. That I intend to implement
shortly. A more helpful UI will have to wait for E or beyond.

Re. off-topic: point taken, filed a separate enhancement request 46886.

Working on it. Provisional schema fragments:

<xsd:complexType name="bound-actions">
 <xsd:sequence>
  <xsd:element name="action" minOccurs="0" maxOccurs="unbounded">
   <xsd:complexType>
    <xsd:sequence>
     <xsd:element name="script" minOccurs="0" type="substitutable-text"/>
     <xsd:element name="target" minOccurs="0" maxOccurs="unbounded"
type="xsd:token"/>
     <xsd:element name="context" minOccurs="0" maxOccurs="unbounded">
      <xsd:complexType>
       <xsd:sequence>
        <xsd:element name="property" type="xsd:token"/>
        <xsd:element name="folder" type="substitutable-text"/>
        <xsd:element name="pattern" minOccurs="0"
type="substitutable-text"/>
        <xsd:element name="format" type="context-format"/>
        <xsd:element name="arity" type="context-arity"/>
       </xsd:sequence>
      </xsd:complexType>
     </xsd:element>
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:NMTOKEN" use="required"/>
   </xsd:complexType>
  </xsd:element>
 </xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="context-format">
 <xsd:restriction base="xsd:NMTOKEN">
  <xsd:enumeration value="absolute-path"/>
  <xsd:enumeration value="relative-path"/>
  <xsd:enumeration value="java-name"/>
 </xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="context-arity">
 <xsd:choice>
  <xsd:element name="one-file-only"/>
  <xsd:element name="separated-files" type="xsd:string"/>
 </xsd:choice>
</xsd:complexType>

and example of usage:

<action name="compile.single">
 <target>compile-some-files</target>
 <context>
  <property>files</property>
  <folder>${src.dir}</folder>
  <pattern>\.java$</pattern>
  <format>relative-path</format>
  <arity>
   <separated-files>,</separated-files>
  </arity>
 </context>
</action>
<action name="compile.single">
 <target>ant-compile-some-files</target>
 <context>
  <property>files</property>
  <folder>${ant.src.dir}</folder>
  <pattern>\.java$</pattern>
  <format>relative-path</format>
  <arity>
   <separated-files>,</separated-files>
  </arity>
 </context>
</action>
<action name="run.single">
 <target>start-with-specified-class</target>
 <context>
  <property>class</property>
  <folder>${src.dir}</folder>
  <pattern>\.java$</pattern>
  <format>java-name</format>
  <arity>
   <one-file-only/>
  </arity>
 </context>
</action>

Pretty flexible; should be able to handle most scenarios. Not
currently able to simulate j2seproject's behavior of enabling Run Test
on a non-test source file which has an accompanying test, but I don't
want to make it too complex or embed scripting languages!

Looks good! One concern/idea though: When you have more than one
source folder in the project, and the same target can be used to
compile files in all of them, it would be nice if you then didn't have
to add a separate action for each of them. If the <folder> element is
omitted then maybe that could act as a kind of wildcard so that if the
<pattern> matches, it is executed. In such an action a
<folder-property> element could instead be used to specify the
property that is set to the actual folder in which a match was found,
like the "contect.root" property in the "single-targets-jsp.diff" patch.

Re. a <folder-property> element - interesting idea but I don't see it
working. Just from looking at the <bound-actions> list, how is the IDE
to know what the desired parent folder is vs. what the desired
relative path is? I.e. if you press F9 on $projdir/a/b/c.jsp, it could
pass folder=$projdir and path=a/b/c.jsp, or folder=$projdir/a and
path=b/c.jsp or folder=$projdir/a/b and path=c.jsp (and it is even
worse for external source roots).

Perhaps a better idea: just allow extra properties to be passed to the
script when running any target (was thinking of allowing this anyway).
Then you would still need multiple <action> entries, one for each root
folder, but you could reuse one target. A little more verbose in
project.xml but I would rather err on the side of verbosity (if there
is a clear, concrete link between the text of project.xml and its
behavior) than making things too clever.

Adding also optional <property> elements you can pass when running
scripts (after <target>).

Along with some other fixes:

committed 1.6  ant/freeform/eg/simple/build.xml
committed 1.9  ant/freeform/eg/simple/nbproject/project.xml
added     1.1  ant/freeform/eg/simple/src/org/foo/myapp/SomeFile.java
added     1.1  ant/freeform/eg/simple/src/org/foo/myapp/some-resource.txt
committed 1.11 ant/freeform/nbproject/project.properties
committed 1.5 
ant/freeform/src/org/netbeans/modules/ant/freeform/Actions.java
committed 1.19
ant/freeform/src/org/netbeans/modules/ant/freeform/FreeformProjectGenerator.java
committed 1.9 
ant/freeform/src/org/netbeans/modules/ant/freeform/resources/freeform-project-general.xsd
committed 1.3 
ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/ActionsTest.java
committed 1.9 
ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/FreeformProjectGeneratorTest.java

You can try the ant/freeform/eg/simple project to get a feel for it.

Concerning folder-property: I don't see the difficulty here, but then
I might be a bit blind. You say "I.e. if you press F9 on
projdir/a/b/c.jsp, it could pass folder=$projdir and path=a/b/c.jsp,
or folder=$projdir/a and path=b/c.jsp ...". Why can't the selected
file be searched for in each source group until it is found, like I do
in the patch? That way the SourceGroup is known and its root folder
can be used for the property value, preferrably relative to the
project folder if possible. There would probably have to be a way for
the <context> to contain the information necessary to pass the correct
type parameter to Sources.getSourceGroups and the correct suffix to
ActionUtils.findSelectedFiles. You already have a <pattern> element
that could maybe be extended. I'm sure I don't see the whole picture
here so please disregard this comment if I'm completely "out cycling"
as we say in Sweden.

Re. finding the base folder automatically based on the known
<source-folder>s declared in another section of project.xml: yes, I
had considered that, but as you mention it does not trivially solve
the problem; you still have to have some way of referring to the
particular source group(s) you mean to use. It seems this would wind
up being more complicated than the simple approach I took: declaring
the root folder you want to search for the selection in directly in
the <context>. (There is no maintenance issue with repeating the
folder name in several places, since you can always define a property
to represent the actual folder path.)

Searching in all source groups could make the project.xml more concise
in some cases, but it could also result in unintentional effects,
because it is less explicit. In the example I pasted into this issue
report, I don't *want* run.single to search for Java classes in each
Java source group; only in the main source dir (${src.dir}). Note that
for actions which can apply to multiple groups, you can either use a
different target for each group (as in the example), or use the same
target but set a special property depending on which group is used, etc.

Re. <pattern> - this is a regexp so it is easy to match based on file
extension as well as many other criteria.

OK, I can live without generic actions and as you say there are
obvious advantages with your solution. It works very well except for
one small detail. I had some trouble writing the target for the
"debug.fix" action since I needed both the relative path to the java
file as well as to the class file. First I solved it with a small ant
task that strips off the suffix but then I thought that it would be
better to have a suffixless format. The enclosed patch shows better
what I mean, although I'm not sure about the format names
"relative-path-base" and "absolute-path-base". And this time the patch
is in unified format and the JCA is signed!

Created attachment 16786 [details]
Support for additional formats in action context.

Looks fine, thanks! I renamed *-base to *-noext for clarity (I hope)
and updated the schema.

In the longer term, it might be useful to be able to extract groups
from the pattern match etc., but this can wait I think so long as
typical targets can be written cleanly. You can always use
<pathconvert>, <script>, etc. in your script if you really need to.

committed   * Up-To-Date  1.6        
ant/freeform/src/org/netbeans/modules/ant/freeform/Actions.java
committed   * Up-To-Date  1.10       
ant/freeform/src/org/netbeans/modules/ant/freeform/resources/freeform-project-general.xsd
committed   * Up-To-Date  1.36        core/release/CREDITS.html

This issue was solved long time ago. Because nobody has reopened it neither
added comments, we are verifying/closing it now. 
If you are still able to reproduce the problem, please reopen. Thanks in advance.