geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: How to get predictable moduleId when using DeploymentManager.distribute()
Date Thu, 14 Sep 2006 19:27:05 GMT
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 <goyathlay.geronimo@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 <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