You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2006/09/13 08:50:02 UTC
How to get predictable moduleId when using DeploymentManager.distribute()
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
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Sachin Patel <sp...@gmail.com>.
JSR-88 interface
On Sep 14, 2006, at 12:18 PM, 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 <go...@gmail.com> 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 <am...@alumni.princeton.edu> wrote:
>> > On 9/13/06, Jason Dillon <ja...@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 <ja...@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
>> > > >>
>> > >
>> > >
>> >
>>
-sachin
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Jason Dillon <ja...@planet57.com>.
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 <go...@gmail.com> 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 <am...@alumni.princeton.edu> wrote:
>> > On 9/13/06, Jason Dillon <ja...@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 <ja...@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
>> > > >>
>> > >
>> > >
>> >
>>
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <go...@gmail.com> 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 <am...@alumni.princeton.edu> wrote:
> > On 9/13/06, Jason Dillon <ja...@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 <ja...@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
> > > >>
> > >
> > >
> >
>
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Prasad Kashyap <go...@gmail.com>.
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 <am...@alumni.princeton.edu> wrote:
> On 9/13/06, Jason Dillon <ja...@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 <ja...@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
> > >>
> >
> >
>
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Sachin Patel <sp...@gmail.com>.
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 <ja...@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 <ja...@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
>> >>
>>
>>
-sachin
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 9/13/06, Jason Dillon <ja...@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 <ja...@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
> >>
>
>
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Jason Dillon <ja...@planet57.com>.
Can I use the artifactId with
javax.enterprise.deploy.spi.DeploymentManager and friends?
--jason
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 <ja...@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
>>
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <ja...@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
>