Bug 145376 - [import/export] J2EE archive export customization needed
Summary: [import/export] J2EE archive export customization needed
Status: NEW
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 1.5   Edit
Hardware: PC Windows 2000
: P3 enhancement (vote)
Target Milestone: Future   Edit
Assignee: Kaloyan Raev CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard:
Keywords: helpwanted
: 145509 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-05 12:46 EDT by Dimo Stoilov CLA
Modified: 2011-05-20 09:17 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimo Stoilov CLA 2006-06-05 12:46:59 EDT
We (SAP) need to customize the export J2EE
archive feature, as we have our custom J2EE archive build. We need some
extension point or some other way for customization so that when an J2EE archive file is being exported our build methods to be invoked instead of the WTP operation responsible for export.
We could use the existing org.eclipse.wst.common.frameworks.OperationExtension (to execute custom operation after the primary operation), 
but we do not want the primary operationto be executed.
Comment 1 Chuck Bridgham CLA 2006-06-05 13:00:04 EDT
Keep in mind this extension allows pre and post operations....

Do you have any details of the features/sceanrios you would like to support?
Comment 2 John Lanuti CLA 2006-06-06 09:23:50 EDT
*** Bug 145509 has been marked as a duplicate of this bug. ***
Comment 3 Dimo Stoilov CLA 2006-06-12 09:51:37 EDT
Our real life scenrio is that our j2ee projects are integrated in our own development infrastructure that has its own build process and it is more correct to use this infrastructure for these projects, therefore pre and post create actions are not feasible for us in this case. 
Comment 4 Jason Sholl CLA 2006-06-12 10:13:16 EDT
Do you want to offer your users another way to export a particular project, or force them?  To satisfy the former, I suggest you create another set of export operations and label them clearly; e.g. "WAR (SAP) export".  The latter may require substantial base enhancements.  Here is a seat of the pants idea:

Base the export operation on facets; i.e. if the "SAP Web Support" facet is installed, then export should use ther operation specified by the "SAP Web Support" provider.  This would be a simple enhancement if no additional UI were required (assuming the general rule that there will be only defined export provider per facet combination; otherwise there need to be a prioritization mechanism or merge capacity)  However, if additional UI were required, then the vaious Export wizards would probably need to be redesigned in the fashion of the creation wizards so additional UI could be displayed.
Comment 5 Jason Sholl CLA 2006-06-12 10:15:19 EDT
I forgot to ask, do you have any additional specifications for this functionality?  Do you have any ideas on how WTP could accomidate your requirement?
Comment 6 Dimo Stoilov CLA 2006-06-16 10:04:51 EDT
We want to force the user to use our export operation. 
The solution you propose - to have export operations based on the facets - really solves the issue for us. There is no additional UI to be required.
Comment 7 Dimo Stoilov CLA 2006-10-10 04:56:38 EDT
  I want to raise a hotbug request for this bug: 

  1. Affiliation: SAP
  2. Target release: WTP 2.0
  3. See comments #4 and #6 for details on the solution. 
Comment 8 Jeffrey Liu CLA 2006-10-10 09:46:53 EDT
Also adding David to this hot bug request.
Comment 9 Chuck Bridgham CLA 2006-11-30 14:31:47 EST
Not a hotbug (regression).   Removing this designation
Comment 10 Kaloyan Raev CLA 2006-12-01 03:14:07 EST
(In reply to comment #9)
> Not a hotbug (regression).   Removing this designation
> 

Hi Chuck, 

Can you give more details on this decision. It is not clear for us at the moment. 

Thanks
Comment 11 David Williams CLA 2006-12-01 09:17:00 EST
I'm not Chuck :) ... but him and I did discussed at/after a status meeting so I can reply, especially since I encouraged this one (and another) to not be hot bugs). (And, yes, I thought Chuck's response was pretty short too ... e-communication is so hard :( 

We want to reserve the "hot bug" designation to 1. bugs, and 2. only hot ones :) 
Just kidding, but we really do want it mean a defect that prevents or greatly inhibits someone from adopting WTP. Since this is an enhancement request, it doesn't seem to qualify. 

And, don't get us wrong, we still do read _all_ comments and arguments for why this is important (not just those for hot bugs), and those are extra comments and pleas are appreciated. Please do keep explaining the importance of the use case.

Also, for enhancements, seems reasonable you might be willing to provide a high quality patch with the desired functionality, along with JUnit tests, etc? 

Since we have so many bugs and feature requests, we'd like to reserve the hot_bug designation to things that might be what would be called "stop ship" sorts of bugs for adopters. And, the reason we make this available is that some bugs are not really all that bad for a "plain" WTP, but would show up as a really bad but in the context of some adopters use. 

Hope that helps. Again, we are not saying this is not important, or that it will never get done ... just that is doesn't seem to be a "hot bug" per se. 

Comment 12 Kaloyan Raev CLA 2008-09-01 11:45:39 EDT
Assigning to Carl for evaluation
Comment 13 Carl Anderson CLA 2008-10-02 12:09:21 EDT
Setting the Target to Future, but assigning this to Kaloyan since this was an SAP request and you may have the time to look into doing this now.
Comment 14 David Williams CLA 2009-05-14 13:47:11 EDT
removed "hotbug_declined" attribute as it makes queries harder.