Home » Eclipse Projects » Plugin Development Environment (PDE) » Reading Bundle-SymbolicName and Bundle-Version from custom build.xml?
| | |
| Re: Reading Bundle-SymbolicName and Bundle-Version from custom build.xml? [message #52781 is a reply to message #52755] |
Tue, 31 March 2009 13:42   |
 Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
It was before my time, but it was probably named 'build.xml' for the
same reason you named yours build.xml, (it is an ant script that builds
the project).
Note that the warning is only in the UI for export, headless build can't
prompt for warnings since that defeat the whole purpose of an automated
headless build.
For the version, PDE/Build will modify the custom build.xml and replace
the value on a property named "version.suffix", the value will be the
full version of the bundle with the qualifier replaced.
There is no property for the symbolic-name. Don't you know this? It
isn't something that changes.
-Andrew
Tom Morris wrote:
> Chris Aniszczyk wrote:
>> Tom Morris wrote:
>>> Back in 2006, there didn't appear to be an easy way to access the
>>> necessary parameters (Bundle-SymbolicName and Bundle-Version)
>>> according to this report
>>> http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/m sg10949.html
>>>
>>> Has the situation improved today? Is there a way to get this
>>> information from the manifest or some other source which is
>>> accessible to Ant?
>>
>> Is there a reason you have to have a build.xml in your project? can't
>> it be my-build.xml?
>
> Thanks for the quick reply Chris. I take it that that's a "No" in
> answer to the original question(s).
>
> In answer to your questions, the main reasons that it's called build.xml
> are: a) that's what Ant uses and b) that's what the development team
> chose in Fall 2000 when they switched to using Ant for their builds.
>
If a name like
> your-special-eclipse-pde-temporary-build.xml was used, there'd be fewer
> conflicts. Better yet, check to make sure the chosen name isn't already
> in use.
>
> I'm trying to promote Eclipse plugins to a project which has been around
> for a decade, so I really don't want to be insisting that they have to
> change things just to get started. I'd like to emphasize the benefits,
> not the costs.
>
> If I figure out a good way to parse the manifest or some other solution,
> I'll post an update.
>
> Tom
|
|
| |
| Re: Reading Bundle-SymbolicName and Bundle-Version from custom build.xml? [message #53043 is a reply to message #52807] |
Wed, 01 April 2009 15:22 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
See my comment here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=120840#c8
Changing the default name of the script should be considered a major
breaking API change. The alternative is then to allow a bundle to
provide an alternate name. With some restrictions on features, this
should be possible, however it is not a small change and affects all the
generated scripts.
There is no time for something like this in 3.5. This would need to be
accounted for in the initial planning at the beginning of a release cycle.
-Andrew
Chris Aniszczyk wrote:
> Andrew Niefer wrote:
>> It was before my time, but it was probably named 'build.xml' for the
>> same reason you named yours build.xml, (it is an ant script that
>> builds the project).
>>
>> Note that the warning is only in the UI for export, headless build
>> can't prompt for warnings since that defeat the whole purpose of an
>> automated headless build.
>>
>> For the version, PDE/Build will modify the custom build.xml and
>> replace the value on a property named "version.suffix", the value will
>> be the full version of the bundle with the qualifier replaced.
>>
>> There is no property for the symbolic-name. Don't you know this? It
>> isn't something that changes.
>
> Andrew, is there a way we can change the build.xml that gets generated
> to be pde-build.xml or something?
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
| | |
| Re: Reading Bundle-SymbolicName and Bundle-Version from custom build.xml? [message #594286 is a reply to message #52755] |
Tue, 31 March 2009 13:42 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
It was before my time, but it was probably named 'build.xml' for the
same reason you named yours build.xml, (it is an ant script that builds
the project).
Note that the warning is only in the UI for export, headless build can't
prompt for warnings since that defeat the whole purpose of an automated
headless build.
For the version, PDE/Build will modify the custom build.xml and replace
the value on a property named "version.suffix", the value will be the
full version of the bundle with the qualifier replaced.
There is no property for the symbolic-name. Don't you know this? It
isn't something that changes.
-Andrew
Tom Morris wrote:
> Chris Aniszczyk wrote:
>> Tom Morris wrote:
>>> Back in 2006, there didn't appear to be an easy way to access the
>>> necessary parameters (Bundle-SymbolicName and Bundle-Version)
>>> according to this report
>>> http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/m sg10949.html
>>>
>>> Has the situation improved today? Is there a way to get this
>>> information from the manifest or some other source which is
>>> accessible to Ant?
>>
>> Is there a reason you have to have a build.xml in your project? can't
>> it be my-build.xml?
>
> Thanks for the quick reply Chris. I take it that that's a "No" in
> answer to the original question(s).
>
> In answer to your questions, the main reasons that it's called build.xml
> are: a) that's what Ant uses and b) that's what the development team
> chose in Fall 2000 when they switched to using Ant for their builds.
>
If a name like
> your-special-eclipse-pde-temporary-build.xml was used, there'd be fewer
> conflicts. Better yet, check to make sure the chosen name isn't already
> in use.
>
> I'm trying to promote Eclipse plugins to a project which has been around
> for a decade, so I really don't want to be insisting that they have to
> change things just to get started. I'd like to emphasize the benefits,
> not the costs.
>
> If I figure out a good way to parse the manifest or some other solution,
> I'll post an update.
>
> Tom
|
|
| |
| Re: Reading Bundle-SymbolicName and Bundle-Version from custom build.xml? [message #594413 is a reply to message #52807] |
Wed, 01 April 2009 15:22 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
See my comment here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=120840#c8
Changing the default name of the script should be considered a major
breaking API change. The alternative is then to allow a bundle to
provide an alternate name. With some restrictions on features, this
should be possible, however it is not a small change and affects all the
generated scripts.
There is no time for something like this in 3.5. This would need to be
accounted for in the initial planning at the beginning of a release cycle.
-Andrew
Chris Aniszczyk wrote:
> Andrew Niefer wrote:
>> It was before my time, but it was probably named 'build.xml' for the
>> same reason you named yours build.xml, (it is an ant script that
>> builds the project).
>>
>> Note that the warning is only in the UI for export, headless build
>> can't prompt for warnings since that defeat the whole purpose of an
>> automated headless build.
>>
>> For the version, PDE/Build will modify the custom build.xml and
>> replace the value on a property named "version.suffix", the value will
>> be the full version of the bundle with the qualifier replaced.
>>
>> There is no property for the symbolic-name. Don't you know this? It
>> isn't something that changes.
>
> Andrew, is there a way we can change the build.xml that gets generated
> to be pde-build.xml or something?
>
> Cheers,
>
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
|
|
|
Goto Forum:
Current Time: Sat Apr 20 01:30:36 GMT 2024
Powered by FUDForum. Page generated in 0.03812 seconds |
] 
Search
Help
Register
Login
Home
