Re: How to get predictable moduleId when using DeploymentManager.distribute()

[Sachin Patel]

I think what you may be looking for is ConfigIDExtractor.identifyTargetModuleIDs perhaps? On Sep 14, 2006, at 10:48 AM, Aaron Mulder wrote: On 9/13/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager  and friends? I'll have to look -- I'm not sure whether the "decode artifact to full module ID" code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there.  Can you try and if it doesn't work create a Jira? Thanks,     Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: > First, if you specify a module ID in your plan, that will be used (or > as much as you provide with defaults for the rest).  And you can pack > the plan in the module if you don't want to track it separately. > > Second, you can undeploy using only the artifact ID (so in your > example, you could "undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT") so long > as there aren't conflicts.  The default artifact ID is the JAR name > minus the extension. > > Thanks, >     Aaron > > On 9/13/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Anyone know how to get predictable moduleIds when using >> DeploymentManager.distribute()? >> >> I'd like to figure out how to get the moduleIds to be the same as the >> artifactId for the archive that is deployed, so that we can undeploy >> it after tests have been run. >> >> How can I do this?  Do I need to specify a plan for the archive to >> tie it to a specific moduleId? >> >> I have been playing with test-ear-j2ee_1.4.ear, and it keeps >> generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ >> 1158129807807/car' which is kinda hard to undeploy after that state >> has been lost. >> >> If I do need to specify a plan, can I tuck that into the .ear so that >> Maven does not need to worry about 2 artifacts for one deployment? >> >> --jason >> -sachin