This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 150911 - Selectively excluding a SU from the service assembly
Summary: Selectively excluding a SU from the service assembly
Status: VERIFIED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: Composite Application (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jun Qian
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-21 17:28 UTC by Tientien Li
Modified: 2009-12-03 17:19 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
basic test projects (296.93 KB, application/x-compressed)
2009-07-21 02:01 UTC, Jun Qian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tientien Li 2008-10-21 17:28:24 UTC
In some use cases, the user like to have connections to an external SU be auto-generated by CompApp project.

However, adding external modules into CompApp processing may require some major changes. An alternative solution 
proposed for this problem is to allow SU be selectively excluded in the packaging of SA. For example, a SU can be used 
in the service connection generation phase, but not be packaged in the resulting SA. This will the user to achieve the 
similar result as auto-generating connections to an external SU.
Comment 1 Jun Qian 2009-07-20 23:56:40 UTC
Phase 1: add back-end project system support

    Task 1.1: CompApp project system should support the concept of external SU projects. EAR project's concept of
excluded library project serves this purpose. 

    Task 1.2: CompApp project should auto generate connections to external SU projects without packaging them in the
resulting SA. 

    Task 1.3: CompApp project should generate external SUs in the CASA file properly. (I think the purpose of showing
external projects in CASA is to visualize the links FROM the internal modules TO the external modules, not visualizing
how the external project works internally or how the external project calls back to the internal project. Therefore,
when generating CASA, we probably don't want to show external SUs' consume endpoints.)


Phase 2: add UI support

    Task 2.1: Add "Add External Module" action into CompApp project node's context menu.

    Task 2.2: Support DnD of SU projects into CASA Editor's "External Modules" region.

    Task 2.3: Show SU projects' Internal/External state in the "Deploy SA Artifacts" table in the CompApp project
customizer.


Phase 3: possible future UI enhancements:

    Task 3.1: Support of changing SU project's internal/external state in the CompApp project customizer
    
    Task 3.2: Support of changing SU project's internal/external state inside CASA Editor through DnD
Comment 2 Jun Qian 2009-07-21 02:01:11 UTC
Created attachment 84958 [details]
basic test projects
Comment 3 Jun Qian 2009-07-21 02:29:33 UTC
Initial Phase 1 implementation in soa-dev65 branch: 
    http://hg.netbeans.org/soa-dev65/rev/9a00844d616d
Comment 4 Jun Qian 2009-07-24 01:24:10 UTC
Initial Phase 2 implementation in soa-dev65 branch: 
    http://hg.netbeans.org/soa-dev65/rev/1c630eca14d8
Comment 5 Jun Qian 2009-07-25 01:15:10 UTC
The previous compapp project system (up to NB 6.5.1 included in GFESB v2.1) contains the following bug:

When both Java EE modules and non-EE modules are added to a compapp project, the project's meta data (project.xml) gets
corrupted, that is, the non-EE module projects' references don't get persisted in the "included-library" section because
of the EE modules' presence [1]. However, this issue is invisible to the end-user because the "included-library" data is
never utilized before.

Now we are going to use "included-library" to indicate whether an SU project is internal or external, that is, whether
an SU project is included in the SA deployment or not, we need to fix the above issue for all the existing compapp
projects first.

Since "jbi.content.javaee.jars" is a redundant property and exists only when the compapp project contains (or contained)
EE modules, we are going to use its presence as a marker to indicate the project's meta data needs a fix. Once the meta
data is fixed, we will remove the "jbi.content.javaee.jars" property and use the combination of "jbi.content.additional"
and "jbi.content.component" to compute it when needed.

Implemented in soa-dev branch:
    http://hg.netbeans.org/soa-dev65/rev/d081732d8a2a


[1] This is fixed in the previous commit (1c630eca14d8).
Comment 6 Jun Qian 2009-08-14 20:53:30 UTC
Changes merged to gfesbv211.

Also in gfesbv211, changed to disable external EE modules' Properties Action. (0972527b03df)
Comment 7 Jun Qian 2009-08-15 01:13:12 UTC
No longer packaging external SU projects' WSDls in BC SU. (gfesbv211: 8a841ca760cf)
Comment 8 sbondada 2009-12-03 17:19:01 UTC
    Task 2.1: Add "Add External Module" action into CompApp project node's
context menu.

Add from the menu, right click on CompApp project add external module

    Task 2.2: Support DnD of SU projects into CASA Editor's "External Modules"
region.
Drag and Drop BPEL project external into CASA External Panel

    Task 2.3: Show SU projects' Internal/External state in the "Deploy SA
Artifacts" table in the CompApp project

In CompApp properties, In deployment checked means internal and uncheck is external.

Tested on Build GFESBv2.2.