Here is our finding and our proposal.

Finding. The new DnD added in response to useability requests creates a flat
collection of artifacts in a folder

Partners/<WebServic>/*.wsdl | *.xsd

The collection of files is a single "target" WSDL (the partner service wsdl)
PLUS the closure of this file - the collection of all .xsd and .wsdls imported
recursively by the "target".

This collection of files may contain an arbitrary number of "schemaLocation" and
"location" attributes in the various schema and wsdl import elements. The values
of these location attributes are currently being preserved untouched. 

The discrepancy b/t the flat files and their original location values is being
mediated by the cataog.xml. The values in the catalog.xml are set by the
retriever to mediate the discrepancy b/t the physical location and the location
attribute values.

For instance here is a catalog.xml that result from DnD of several use cases
1) DnD of EJB partner WS named HelloService 
2) DnD of arbitrary partner WSDL named MyPartnerProcessWSDL.wsdl
3) DnD of the TRS process WSDL which was adjusted to be more complex in its
original state by offsetting its own import of AirlineService.wsdl to a
subdirectory.

These 3 drops show 3 possible problems.
1) local developer host IP addresses which are not portable across development
team. 
i.e.
http://129.159.127.197:8080/HelloServiceService/HelloService/__container$publishing$subctx/META-INF/wsdl/HelloServiceService_schema1.xsd"

2) local file system references like this which have drive specific details
file:/C:/Documents%20and%20Settings/Mike/TravelReservationService10/TravelReservationService10/src/TravelReservationService.wsdl

3) local files system references which were offset from the target like this
<system systemId="WSDL/HotelReservationService.wsdl"
uri="src/Partners/TravelReservationService/HotelReservationService.wsdl"/>

Each of these represent a possible problem for either another team member doing
development, or in some cases a problem for the build or deploy actions. 

In short, this is truly a problematic collection of references.

Our proposal to "fix" this is the following:

DnD will remain as before. For user, nothing changes.
During DnD the following will occur
1) User releases mouse
2) IDE retrieves necessary files and they are placed in Partners/<ServiceName>/
folder  - again, nothing changes from today
3) programattically IDE will recursively follow all import statements included
in the "target" WSDL and do the following adjustments (this is the new part)
 --- Adjust all "location" and "schemaLocation" to be the current directory.
for example:
      <xsd:import namespace="http://webservice/"
schemaLocation="http://129.159.127.197:8080/HelloServiceService/HelloService/__container$publishing$subctx/META-INF/wsdl/HelloServiceService_schema1.xsd"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"/>

woudl become
   <xsd:schema>
      <xsd:import namespace="http://webservice/"
schemaLocation="HelloServiceService_schema1.xsd"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"/>
    </xsd:schema>

and 
	<import namespace="http://www.sun.com/javaone/05/HotelReservationService"
location="WSDL/HotelReservationService.wsdl"/>

would become

	<import namespace="http://www.sun.com/javaone/05/HotelReservationService"
location="HotelReservationService.wsdl"/>

---- the exceptions to this rule would be any import which was obviously of
network origin. 
i.e. an import which is "http://<network addresss>" where "network addres" is !=
to the current host machine. If it is == to the current host, then this will be
adjused as described above because such address are problematic across team
developement.

The net result of this adjustment will be much better team development environment.

One consequence of this adjustement is that some of the catalog.xml entries will
be irrelevant at this point. They will not be needed and they will no longer be
valid. They will be harmless garbage. Obviously, this is not good to have
harmless garbage but it is better than having non-helpful non-garbage.

After further review it was suggested that the plan described above is a good
one for the EJB/WS node DnD.

However, a different plan was suggested for the DnD of arbitrary WSDL across
project boundaries. Instead of invoking retriever to place retrieved file in
single flat directory, in this use case the files should be retrieved as per
normal by the retriever and layed down as retriever ordinarily would deposit
files. This would preserve the relative pathing and not require any adjustments
by us to any of the imports. 

The working assumption here is that there is a fundamental different b/t the 2
use cases. 
In the use case of DnD of EJB/WS node, the files are retrieved from the App
Server and the flat filesystem that we introduce at retrieval is preferable to
the ugly hierarchy that would otherwise be retrieved by default.

However, in the use case of the DnD of local WSDL across project boundaries, the
assumption is that the local files will be retrieved in the same relative order
that they were in their source directory. And this organization can be assumed
to be satisfactory and in fact preferable. Of course,  we would still deposit
them in the Partners/<ServiceName>/ directory, but the organization under that
directory would be whatever the retriever provides by default.

Mike, 
The last scenario(use original folder structure and do not fix URL for cross-
project WSDL DnDs ) is good, but i faced some problems with PL editor dialog 
with it. The problem appears when DnD'ed WSDL imports schema from parent 
folder, like schemaLocation = ".../some.xsd". In that case PL editor dialog 
appears empty(it was unable to find any PLT or PL in dropped WSDL). But 
canceling PL editor and dropping the local copy of this WSDL to diagram works 
just fine.

So, i commiting the version described in your comment dated Tue Sep 26 
15:42:06 +0000 2006.

 

Note to docs. The final resolution of this did inolve implmenting a slight
deviation from the origianl spec. I don't think the deviation affects on line
help at all since it does not go into the detail that is affected by this fix.

However, we probably need to review the Developer Guide section on Partner Link
construction to make sure it is in sync with the final (hopefully)
implementation of the DnD action.

Verified in build 2006.09.27

Found out that one of the scenarios still does not work correctly. Reopening bug

Switched to structured retriever for cross-project WSDL dnd.

Note to Docs - lets just review the sections on this DnD operation to make sure
they are consistent with actual behavior.

Verified in build 070530.