[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ant-dev] new Ant tasks
|
Improving the Ant integration is always at the top of our list. Currently
we don't have anything planned to implement and ideas like yours are
welcome. Also, you can go ahead and enter feature requests in bugzilla. If
anyone is interested in implementing anything that is (or is not) on
bugzilla just send a message to the list and we can discuss that. We would
really appreciate contributions from the community.
Another thing is that you could consider splitting various feature requests
in multiple email messages so that our motivation about reading the message
doesn't get too low. ;-)
Now, back to your suggestions.
eclipse.prompt
I can see its use but since it involves UI, the org.eclipse.ant.core
plug-in might not be the best home for it. Does not mean it prevents it
from being discussed here. The discussion/implementation can start here and
we might find a home for the code later.
eclipse.getWorkspaceLocation
Good one. It could be a property as well but then people that do not
use it would get an extra overhead when running their scripts (sure it
could be made optional, and so on... - we can go very far on this
discussion - not that I think we shouldn't).
Currently, as a workaround, you can get this to work by using the
external tools. In the "Tool arguments:" field add -DworkspaceLocation
=${workspace_loc} and it will work. You should be able to use any variable
provided by the external tools.
eclipse.getProjectLocation
You already have it and its called eclipse.convertPath (so you can
get not only the project location but any resource). Take a look at the
following doc:
http://download.eclipse.org/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.isv/guide/ant_eclipse_tasks.htm
eclipse.getClasspathVariable
http://bugs.eclipse.org/bugs/show_bug.cgi?id=6006
Another good one. When/if done it would probably live in the JDT Core
plug-in.
eclipse.getClasspath
http://bugs.eclipse.org/bugs/show_bug.cgi?id=5950
eclipse.getXML
eclipse.setXML
I'm not sure why they would be Eclipse specific tasks. They seem to
be better contributed without any Eclipse dependencies.
Rodrigo
Dan Rubel
<dan_rubel@instantiatio To: platform-ant-dev@xxxxxxxxxxx
ns.com> cc:
Sent by: Subject: [platform-ant-dev] new Ant tasks
platform-ant-dev-admin@
eclipse.org
07/16/2002 10:04 AM
Please respond to
platform-ant-dev
In the spirit of better Eclipse/Ant integration, I am proposing additional
Eclipse specific Ant tasks similar to the few existing Eclipse specific Ant
tasks that I found. If you all approve, I'll propose these enhancements on
the newsgroup next to see what others are thinking. Hopefully some folks
out there (eclipse.org folks, users, etc, in addition to myself) will
contribute time to make this all happen. Obviously if eclipse.org already
has a plan in place I'll happily drop this one. All thoughts are most
welcome.
Existing: (from the org.eclipse.core.resources plugin)
- eclipse.convertPath
- eclipse.incrementalBuild
- eclipse.refreshLocal
Proposed:
- eclipse.prompt
Prompt the user for one or more property values via simple one line text
fields. The current property value(s) appears as the default value(s) in
the prompter if one is not specified. A number of seconds to wait can be
specified, after which the dialog closes and either automatically accepts
the current values or throws a build exception indicating that no input was
received. If any input is received (e.g. the user pressed a key to modify
a current property value), then the countdown is stopped.
<eclipse.prompt
title="My prompt title"
message="My prompt message">
<property name="myPropertyA"/>
<property name="myPropertyB" value="a default value"/>
</eclipse.prompt>
Prompts the user for two property values
- eclipse.getWorkspaceLocation
Place the current workspace location into a property. (Perhaps this is
already or should be available as a pre-defined eclipse/ant property?)
<eclipse.getWorkspaceLocation property="aPropertyName"/>
Places the current workspace location into the property named
"aPropertyName"
- eclipse.getProjectLocation
Place the current location for the specified project into a property.
<eclipse.getProjectLocation project="MyProject"
property="aPropertyName"/>
Places the current location of "MyProject" into the property named
"aPropertyName"
- eclipse.getClasspathVariable
Places the current content for the specified classpath variable into a
property
<eclipse.getClasspathVariable classpathVariable="ECLIPSE_HOME"
property="aPropertyName"/>
Places the current location of the classpath variable named
"ECLIPSE_HOME"
into the property named "aPropertyName"
- eclipse.getClasspath
Places the entire classpath for the specified project into a property. Any
references to classpath variables in the classpath will be replaced with
the current values for those classpath variables before the string is
placed into the property.
<eclipse.getClasspath project="MyProject" property
="aPropertyName"/>
Places the current classpath of the project named "MyProject"
into the property named "aPropertyName"
- eclipse.getXML
Retrieves a value from an XML file and places it into a property. We
(Instantiations) use a simplified version of this internally in our build
process to retrieve the value of a top level XML element's attribute. This
is a first attempt to generalize this functionality, so feedback its form
and even on whether this should be part of the eclipse base is most
welcome.
<eclipse.getXML
file="MyProject/aFile.xml"
attribute="version"
property="aPropertyName"/>
Parses the specified XML file and retrieves the value of the
specified attribute,
placing the value found into the property named "aPropertyName".
If the attribute is not found, then a build exception is thrown.
<eclipse.getXML
file="MyProject/aFile.xml"
attribute="version"
defaultValue="aDefaultValue"
property="aPropertyName"/>
Parses the specified XML file and retrieves the value of the
specified attribute,
placing the value found into the property named "aPropertyName".
If the attribute is not found, then "aDefaultValue" is used
instead.
In the examples above, the specified attribute could be a path to an
attribute nested several levels deep in the XML structure. For example
attribute="foo/bar/attributeName"
Retrieves the specified attribute of the first element
with tag name bar
inside the first element with a tag name foo
attribute="foo[3]/bar[5]/attributeName"
Retrieves the specified attribute of the third element
with tag name bar
inside the fifth element with a tag name foo
- eclipse.setXML
Identical to eclipse.getXML, except modifies an attribute value rather than
retrieving its value.
Of course the above eclipse.getXML and eclipse.setXML tasks above might not
be the right approach at all to a build process. Perhaps imbedding
@VERSION@ in the plugin.xml and using ANT's Copy task with a filterset as
shown below would be a better approach.
<copy file="plugin.xml" todir="../output_dir" >
<filterset>
<filter token="VERSION" value="1.0.0" />
</filterset>
</copy>
The problem with this approach is that the runtime-workbench rejects this
in the plugin.xml, posting the following error message in the error log...
"!MESSAGE Error while processing
"file:C:/Dev/eclipse20020612/workspace/MyProject/plugin.xml: assertion
failed: The major (1st) component of plug-in version identifier,
"@VERSION@", must be numeric."."
... but perhaps the code for the runtime-workbench should be modified
instead of introducing eclipse.getXML and eclipse.setXML. All ideas are
welcome.
- Dan Rubel
Principal Member of Technical Staff
Instantiations, Inc.
412-492-9536 (land line)
412-400-7567 (cell)
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
