Hello Folks,
If i understood properly, The webMethods Deployer Dependency default option advantage is ONLY to intiate dependency check manually as to avoid each addition of components to deployment sets. I agree that it would improve performance as you documented.
Let’s consider a case where i want to deploy 3 packages called Package1 to Package3
regardless of dependencies. I am aware of all required dependencies are exist in target server and i DO NOT want to tell the Deployer that dependent componets are exist by selecting EXISTS option for every dependency.
Most cases, we deploy required packages under the assumption that all the dependents are exist at taget server. In this case, the deployer really irritating and time consuming because it will list out dependencies gradually based on my selection.
For ex, for deployment of 3 packages it would show 25 (i assume we have 25 packages which are dependent on these 3 packages) packages (not once, gradually) that are
dependent of these packages.
Is there any feature in Deployer 6.5 that will deploy with out considering dependencies/unresolved references?
I know its just like forced deployment with out considering the consequences/references. But I dont care as I am confident that all the dependent compents are exists on target and dont want to resolve deployer dependency checkings.
Another bug i noticed in Deployer as follows,
I created a project called DemoDeployer6.5 and deleted it. When i attempt to recreate the same project the deployer throws an exception that the project already exist.
I can send the screen shot if you guys want it.
Thanks
Anil
Hello Anil,
If it’s OK with you, I’m going to log a feature request for the Deployer based on your request. Essentially, it sounds like you would like an option to defeat the dependency checking algorithm entirely – not just postponing the dependency check as we allow today, but eliminating it entirely.
With respect to the exception you saw when creating a project (with the same name as a previously deleted project), would you mind helping us explore this a bit more? (We cannot duplicate that behavior here).
- Did you delete the Project using the Deployer?
- Did you have any of the files in the …\persist\projects<project> folder structure open in applications outside of Deployer?
My best guess at this point is that the OS had a project file opened, and the project deletion failed to clean up the folder structure. Upon creating a project of the same name, the Deployer believed the project already existed as there were artifacts from the original project on the file system.
Although a screen-shot is always helpful, perhaps you could check on the file-system, specifically:
…\packages\WmDeployer\persist\projects<yourProjectName>
And tell us which files, if any, exist in this structure. That may help us determine if the Deployer is somehow leaving a file open which would break the project deletion scheme.
Thanks very much!
Tom Dayton
Product Development
Hi Tom,
Thanks for your response. I am glad to have that feature in your feature release.
Let me know, if you need a SR for the same.
Also, send me your email address to send the screen shot and clarifications that you asked. I think its good to discuss those issues off public forum.
Also, I just noticed that Deployer creating huge count of sessions and Threads in IS Source and as well as Target during define, map and build steps.
I will confirm the same with you ASAP.
Thanks
Anil