Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 23597 invoked from network); 14 Sep 2006 16:45:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Sep 2006 16:45:35 -0000 Received: (qmail 65230 invoked by uid 500); 14 Sep 2006 16:45:32 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 65190 invoked by uid 500); 14 Sep 2006 16:45:32 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 65179 invoked by uid 99); 14 Sep 2006 16:45:32 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Sep 2006 09:45:32 -0700 Authentication-Results: idunn.apache.osuosl.org smtp.mail=sppatel@gmail.com; spf=pass Authentication-Results: idunn.apache.osuosl.org header.from=sppatel@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,RCVD_BY_IP Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates 64.233.184.237 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from ([64.233.184.237:34474] helo=wr-out-0506.google.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id DE/00-06374-DD689054 for ; Thu, 14 Sep 2006 09:45:28 -0700 Received: by wr-out-0506.google.com with SMTP id 57so963384wri for ; Thu, 14 Sep 2006 09:44:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer:sender; b=QCs+gTVeZxCVbU7SFN3avHH14jP+9D+ioveblMeeUNqQn76/WBcntFflRFuyQcbsAERKGGcWaUOXGGgwCJHmGhN9HBnvMbd2b+Spej2j78+mK7wdjhmNXJgbHOJ3gxHY3XaHVv2QphXhILTE28pmbyru5iwNkXzQ2YAG+qSlJpI= Received: by 10.90.81.14 with SMTP id e14mr3349824agb; Thu, 14 Sep 2006 09:44:10 -0700 (PDT) Received: from ?9.27.40.137? ( [129.33.49.251]) by mx.gmail.com with ESMTP id 15sm927760wrl.2006.09.14.09.44.07; Thu, 14 Sep 2006 09:44:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <74e15baa0609140918t2c85250dt9f94c4451f458356@mail.gmail.com> References: <74e15baa0609130430k2c0783f3i6a869de9e87fc943@mail.gmail.com> <7DEDCD08-8961-435A-9B0B-9C42A6BFD621@planet57.com> <74e15baa0609140748mf640a85p2b44fad64770bd5d@mail.gmail.com> <74e15baa0609140918t2c85250dt9f94c4451f458356@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-13--443575502 Message-Id: <0BDDA3D2-B1EE-4E29-87C4-F189A73CE9B8@gmail.com> From: Sachin Patel Subject: Re: How to get predictable moduleId when using DeploymentManager.distribute() Date: Thu, 14 Sep 2006 12:44:10 -0400 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.2) Sender: Sachin Patel X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-13--443575502 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 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 wrote: >> > On 9/13/06, Jason Dillon 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 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 --Apple-Mail-13--443575502 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 JSR-88 = interface

On Sep 14, 2006, at 12:18 PM, Aaron Mulder = wrote:

OK.=A0 I guess the issue is that by = default, the DeploymentManager
expects a = TargetModuleID which is assumed to be complete.=A0 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

Thanks,
=A0 =A0 Aaron

On = 9/14/06, Prasad Kashyap <goyathlay.geronimo@gmail.com<= /A>> 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.

Prasad

> On 9/13/06, Jason Dillon = <jason@planet57.com> = wrote:
> > Can I use the = artifactId with
> > = javax.enterprise.deploy.spi.DeploymentManager=A0 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.=A0 Can you try and if it doesn't = work create a Jira?
>
> Thanks,
>=A0 =A0 =A0 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).=A0 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.=A0 The default artifact ID is = the JAR name
> > > minus the = extension.
> > >
> > > Thanks,
> = > > =A0 =A0 = 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?=A0 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
> > >>
> = >
> >
>



 =

= --Apple-Mail-13--443575502--