Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Regarding the wisdom of export vs deployable factory
Wouldn't an easier first step to simply make the export functions get the list of resources from the Deployment Factory? The wizards already filter out any projects that don't have the facet, so we *know* an IModule exists for each such project being exported. If we have the export simply get access to this IModule, iterate through its list of resources, and save it to the appropriate jar, we'd automatically remove the need for the duplicate logic and replace it with a generic class which can take any IModule and output it to a file.
This class would be much more useful not just for you but for adopters, and also remove the duplication in one fell swoop. 

Jason A Sholl wrote:


Hey Rob,
Yes, this is something we have talked about in the past. There are in fact 4 different code paths :) Two for export (one for EE 5 and one for J2EE 1.4 and below). And two for deployable (one for EE5 and one for J2EE 1.4 and below).
One step in the right direction I was hoping to make during M6 is consolidating the export (and import) functions to run on top of IArchive (i.e. remove the CommonArchive code path here).
The step would be to combine both J2EE and JEE deployable factories into one; this could occur in parallel, but we haven't made plans to address this.
The final step would be to take the combined deployable factory and rework it to also use IArchive, and again, we have not made plans to address this. 

Thank you,

Jason A. Sholl
jsholl@xxxxxxxxxx
919-543-0011 (t/l 441-0011)


From: 	Rob Stryker <rob.stryker@xxxxxxxxxx>
To: "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx> 
Date: 	02/13/2009 04:31 AM
Subject: 	[wtp-dev] Regarding the wisdom of export vs deployable factory


------------------------------------------------------------------------



Hi all:

Currently there are two ways to turn a project into a jar / war / ear
etc. The first is to use the export menu selections. The second is to
use a deployable server adapter.

My question is, what is the wisdom between having two different sections
of code (not just two entry points, but 2 different pieces of code
entirely) in charge of compiling the output archive? As an example, the
JEEDeployableFactory exposes a webtools project in the servertools API.
You also have the J2EEExportArtifactOperation for exporting.  They both
seem to do much of the same thing, though slightly differently. One
(JEEFlexProjDeployable) uses just the virtual component model. The other
(export) is checking ComponentArchiveLoadAdapter and a whole host of
parallel model code.

Wouldn't it be wise to have both the export functionality and the
deployable factories be simply entry points to the same code, rather
than having huge swaths of duplicate code with slight but undefined
differences between the two? I do remember in the past there were also
inconsistencies between the export behavior and a server adapter's
behavior because of the differences in the export vs deployable code.

Any thoughts?

- Rob Stryker
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


------------------------------------------------------------------------

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top