[
https://issues.apache.org/jira/browse/FELIX-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673911#action_12673911
]
Richard S. Hall commented on FELIX-136:
---------------------------------------
Well, the one thing I will point out, though, is that it doesn't really address
this issue, since this issue is talking about introducing support in Felix for
a development-time class path concept that would eliminate the need to do any
copying or restructuring. But that is not a big deal, we would just need to
create a different issue for your patch.
Looking through the issues, it looks like we already have an issue for this
with a patch:
https://issues.apache.org/jira/browse/FELIX-420
I wonder how the two approaches compare? We should probably move these
attachments to there.
> 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: felix-launcher.zip, 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.
