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

[Jason Dillon]

Trying to avoid pulling in too much of the server for the plugin, so  
the plugin has a better hope of working with different versions of G.

--jason

On Sep 14, 2006, at 9:18 AM, Aaron Mulder wrote:

OK.  I guess the issue is that by default, the DeploymentManager
expects a TargetModuleID which is assumed to be complete.  We have to
decide in this case whether we should just allow TargetModuleIDs that
essentially have wildcards, or whether we should add some methods to
our DeploymentManager subinterface that take arguments more like we
want for this case.

Do you guys asking for this care whether you're using the strict
JSR-88 DeploymentManager interface or e.g. a GeronimoDeploymentManager
interface?

Thanks,
    Aaron

On 9/14/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
I tried your suggestion about using just the artifactId in a mojo
execution. That wouldn't work. However, it works as you said from the
CLI.

Cheers
Prasad

On 9/14/06, Aaron Mulder <[EMAIL PROTECTED]> 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
> > >>
> >
> >
>