geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: How to get predictable moduleId when using DeploymentManager.distribute()
Date Thu, 14 Sep 2006 16:13:35 GMT
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 <ammulder@alumni.princeton.edu> wrote:
> On 9/13/06, Jason Dillon <jason@planet57.com> 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 <jason@planet57.com> 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
> > >>
> >
> >
>

Mime
View raw message