[
https://issues.apache.org/jira/browse/FELIX-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673579#action_12673579
]
koszegir edited comment on FELIX-136 at 2/15/09 1:07 AM:
---------------------------------------------------------------
The problem is that by default classes are in the bin subdirectory of the
project while MANIFEST.MF and other directories/files are in the project root.
One solution would be to add the bin directory to the bundle classpath the
other is to copy the MANIFEST and other stuff under the bin directory.
My plugin uses the later. It scans the bin.includes entry in the
build.properties file for each bundle and copies the files/directories under
the bin directory . Eclipse is intelligent enough to copy only modified files.
The generated config.properties file has entries like:
reference:file:<project location>/bin
for each selected project.
The plugin has two classes only (12Kb) + a helper plugin that must be put into
the target platform. The later is needed only for the validation process (it
defines execution environments required by the Eclipse launch validation
process) and not required in a deployment environment. It contains no classes.
Yes, if you guys find it useful I will contribute it to Felix.
I will attach it to this issue soon after finished the documentation and
refactored it (or post it to an other location if preferred).
Regards,
Robert
was (Author: koszegir):
The problem is that by default classes are in the bin subdirectory of the
project while MANIFEST.MF and other directories/files are in the project root.
One solution would be to add the bin directory to the bundle classpath the
other is to copy the MANIFEST and other stuff under the bin directory.
My plugin uses the later. It scans the bin.includes entry in the
build.properties file for each bundle and copies the files/directories under
the bin directory . Eclipse is intelligent enough to copy only modified files.
The generated config.properties file has an entries like:
reference:file:<project location>/bin
for each selected project.
The plugin has two classes only (12Kb) + a helper plugin that must be put into
the target platform. The later is needed only for the validation process (it
defines execution environments required by the Eclipse launch validation
process) and not required in a deployment environment. It contains no classes.
Yes, if you guys find it useful I will contribute it to Felix.
I will attach it to this issue soon after finished the documentation and
refactored it (or post it to an other location if preferred).
Regards,
Robert
> Add property to modify development-time bundle class path for Eclipse PDE
> -------------------------------------------------------------------------
>
> Key: FELIX-136
> URL: https://issues.apache.org/jira/browse/FELIX-136
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
> Attachments: osgi-frameworks.JPG, run-configurations.JPG,
> target-platform.JPG
>
>
> Eclipse PDE uses "framework launchers" for lauching arbitrary OSGi
> frameworks. Felix in combination with its "reference:" protocol is
> successfully able to be launched by Eclipse PDE, but it is not ideal since it
> requires that the project be structured with everything in the root
> directory. Since projects are typically organized around bin/ and classes/
> directories, this is less than perfect.
> Equinox supports a special property to modify the bundle's class path at
> development time to alleviate this situation. Such a property could also be
> added to Felix to improve integration with Eclipse PDE.
> For example, DirectoryRevision could be modified to search for a
> configuration property named ${bundle-symbolic-name}.classpath and could
> prepend this value to the existing manifest header. To my understanding, this
> is similar to the approach used by Equinox.
> If we implement this, then we should probably add another property to
> enable/disable development-time features, so that people cannot use this
> property unless the framework is being used in development mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
