[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Extensions to plan {enhancement idea}
|
I did think of that after pressing send :)
Few questions for potential approach on deployment.
Dropping fragment plan into pickup should generate an exception. That is fragment plans are always discovered from repository and deployment is driven by parent plan deployment.
or
Dropping fragment plan into pickup will trigger deployment of parent plan if present in repository and exception otherwise.
I kind of favor first option - simpler I think. Unless there is a desire for child plan deployment in pickup to refresh parent plan deployment at runtime without restart or manual user "refresh" operation.
Regards,
Dmitry
On Fri, Nov 12, 2010 at 10:45 AM, Glyn Normington
<gnormington@xxxxxxxxxx> wrote:
Hi Dmitry
That sounds quite reasonable and pretty straightforward to implement.
I would favour a slightly different syntax as I'd like to be able to see plan extensions as artifacts at runtime, so I'd like plan extensions to be plans in their own right and function just like child plans do today, except the reference is the other way round. In particular, each plan extension should have a type (plan), name, and version in addition to information about which plan it extends.
So the extension plan below would be spelled something like this:
<plan name="admin.extension" version="2.1.0" parentPlan="org.eclipse.virgo.apps.admin.plan" ...
Regards,
Glyn
On 12 Nov 2010, at 15:27, Dmitry Sklyut wrote:
Hi,
I wonder if the following idea can pass the smell test.
I would like to propose a concept of an extension/fragment plan that can be attached to the referenced parent plan during deployment. The concept is similar to one plan importing another (currently supported feature), except that it is up to deployer to discover association and "fault-in"/merge the extension/fragment plan with parent plan.
I think this will provide one more interesting feature in OSGi Application space. Plans are treated as applications, but to add features to these applications requires modification to the plan and that is a manual step. With PAR this means a whole new build.
Thoughts? I have a use case where this feature would be invaluable. It will give me concreate boundaries and knowledge of deployment unit completeness. Having this completeness allows interesting use case implementations based on InstallArtifactLifecycleListener. For example support for per plan JPA/Hibernate SessionFactory with entities spread out across multiple bundles vs. OSGi JPA Spec that is targeted at a single bundle.
Regards,
Dmitry
Example:
<!-- parent -->
<?xml version="1.0" encoding="UTF-8"?>
<plan name="org.eclipse.virgo.apps.admin.plan" version="2.1.0" scoped="false" atomic="true"
xmlns="
http://www.springsource.org/schema/dm-server/plan"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springsource.org/schema/dm-server/plan
http://www.springsource.org/schema/dm-server/plan/springsource-dm-server-plan.xsd">
<artifact type="bundle" name="org.eclipse.virgo.apps.admin.core" version="[2.0,3.0)"/>
<artifact type="bundle" name="org.eclipse.virgo.apps.admin.web" version="[2.0,3.0)"/>
</plan>
<!-- extension (scoped and atomic are ignored/conflict with extension attribute-->
<!-- can also be done with subelement -->
<?xml version="1.0" encoding="UTF-8"?>
<plan name="org.eclipse.virgo.apps.admin.plan" version="2.1.0" extension="true"
xmlns="
http://www.springsource.org/schema/dm-server/plan"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springsource.org/schema/dm-server/plan
http://www.springsource.org/schema/dm-server/plan/springsource-dm-server-plan.xsd">
<artifact type="bundle" name="org.eclipse.virgo.apps.admin.extension.datasource" version="[2.0,3.0)"/>
</plan>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
