« Return to Thread: BPEL validation from a command line can not find the WSDLs

Re: BPEL validation from a command line can not find the WSDLs

by jsexton0 :: Rate this Message:

Not quite it seems. It looks like it does this, but when I removed lines from catalog.xml the build process from the IDE still had no trouble on the two java steps. It only fails later in the process at the end when trying to build the actual dist files. The catalog.xml is indeed used at that later step (and in fact that part also works from outside the IDE).

How those two classes locate the files is a mystery, however, when doing the validation and copying files into the build directory. I could grep no other reference to those location tags anywhere in the project.

Kirill Sorokin wrote:

Well, the build process per se relies heavily on the data found in
catalog.xml, which
is located @ the root of the file hierarchy of the project. It is used, for
example, to turn
these AAA/xxx.wsdl entries into sensible file paths.

On 5/18/09 8:24 AM, jsexton0 wrote:
> There appears to be a great deal of mystery surrounding the build process.
> I'll include here a few more details for other that may be interested, but
> it appears that a headless build is not possible or practical at this time.
>
> First of all, the information found here:
> http://blogs.sun.com/tronds/entry/creating_a_simple_headless_build
> is vital to even getting started with regard to the build environment. That
> setup may be enough for most projects, or at least projects other than BPEL
> projects that refer to WSDLs in other projects.
>
> The nature of the "location" clause of an import in a BPEL file is unknown.
> It is not a file path, nor does using "file://" work. The build process
> somehow knows where to look for "AAA" when the location tag is
> "AAA/BBB.wsdl", even when the target is in some completely different project
> and hierarchy on the machine. I have been unable to determine how this
> happens - ie, how "AAA/BBB.wsdl" is mapped to a physical file.
>
> This magic occurs in at least two classes invoked by the build process:
>
> org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask
> org.netbeans.modules.bpel.project.anttasks.cli.CliGenerateCatalogTask
>
> Somehow, inside the GUI only, these classes can map the location tags to
> physical files and find thus the WSDLs required. GUI-only builds is a very
> surprising limitation, but there it is. I anyone has anyother information
> on this, I'd very much like to hear about it. It seems we will have to
> replace the build scripts for our projects.
>
>
> jsexton0 wrote:
>> Hello -
>>
>> When a WSDL from a separate project is included in a BPEL, the<import>
>> tag's location cause looks like this:
>>
>> <import namespace="http://myns" location="otherProject/my.wsdl"
>> importType="http://schemas.xmlsoap.org/wsdl/"/>
>>
>> whereas WSDLs from the local BPEL project look like this:
>>
>> <import namespace="http://myns" location="my.wsdl"
>> importType="http://schemas.xmlsoap.org/wsdl/"/>
>>
>> Both forms work when building from inside Netbeans. When building from
>> the command line with ant, the WSDL file pointed to by the location cause
>> for these imported from other projects can not be found.
>>
>> My question is, what is the location clause exactly? A path? It doesn't
>> seem to be if both the above forms work. What do we have to do so the
>> WSDLs in other projects are found when building from the command line?
>> How does the validation/build process search for included WSDL files?
>>
>> Thank you
>>
>

« Return to Thread: BPEL validation from a command line can not find the WSDLs