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
[email protected]
919-543-0011 (t/l 441-0011)
From: Rob Stryker <[email protected]>
To: "General discussion of project-wide or architectural issues."
<[email protected]>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
