You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2006/05/23 15:12:45 UTC
m2 : packaging plugin
David J,
Based on your suggestions, I have used the following conventions to
add dependency elements to the plan file :
type = jar/unspecified : generate <import>classes</import>
If the version is specified, it is kept otherwise
an available version is chosen.
type = car : The scope element is used as follows:
unspecified : It is a parent configuration and added to the
plan.xml
provided : It is used to force the build order on the
configurations in a multi project build. This
dependency is not added to the generated plan.
compile : generate <import>classes</import>
runtime : generate <import>services</import>
Thnaks
Anita
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: m2 : packaging plugin
Posted by anita kulshreshtha <a_...@yahoo.com>.
David J,
Here it is... These are the configurations without the openejb.
Just FYI few points :
1. The o.a.g.d.BootstrapPlugin.bootstrap uses hardcoded
Maven1Repository. I keep changing the following lines to switch between
m1 and m2. I would like to change this:
Maven1Repository repository = new Maven1Repository(localRepo);
2. I am generating zip files for all the configurations in target
directory, and installing them using install:install. This will work
for all the configurations except the daytrader.
3. I have used the deploymentConfig to keep things identical to the
other plugin. Once all the configurations have been built, I can
revisit this.
3. I just got the latest openejb patch, and am working on the other
configurations. It would be nice to have it tested on the other
machines.
Thanks
Anita
Generated package
D:\xxxxx\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
D:\xxxxx\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car to C:\Documents and
Settings\User\.m2\repository\org\
apache\geronimo\configs\unavailable-webservices-deployer\1.1-SNAPSHOT\unavailable-webservices-deploy
er-1.1-SNAPSHOT.car
[INFO] [maven-one-plugin:install-maven-one-repository {execution:
default}]
[INFO] Installing
D:\xxxxx\geronimo\geronimo-1.1\configs\unavailable-webservices-deployer\target\una
vailable-webservices-deployer-1.1-SNAPSHOT.car to C:\Documents and
Settings\User\.maven\repository\o
rg.apache.geronimo.configs\cars\unavailable-webservices-deployer-1.1-SNAPSHOT.car
[INFO]
[INFO]
[INFO]
----------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
----------------------------------------------------------------------------
[INFO] Geronimo Configs ....................................... SUCCESS
[2.203s]
[INFO] Geronimo Configuration for performing service deployments
SUCCESS [5.734s]
[INFO] System Configuration for the J2EE Server ............... SUCCESS
[2.375s]
[INFO] RMI Naming configuration ............................... SUCCESS
[0.938s]
[INFO] Server Configuration for the J2EE Server ............... SUCCESS
[1.312s]
[INFO] Axis Configuration for the J2EE Server ................. SUCCESS
[1.094s]
[INFO] Configuration for performing J2EE deployments .......... SUCCESS
[1.813s]
[INFO] Axis Configuration for performing J2EE deployments ..... SUCCESS
[1.063s]
[INFO] System Configuration for the J2EE Client ............... SUCCESS
[0.594s]
[INFO] Directory Configuration ................................ SUCCESS
[1.031s]
[INFO] Hot Deployer ........................................... SUCCESS
[1.500s]
[INFO] Security Configuration for the J2EE server ............. SUCCESS
[2.359s]
[INFO] LDAP Security Realm .................................... SUCCESS
[0.938s]
[INFO] Online Deployer Configuration .......................... SUCCESS
[0.578s]
[INFO] Shared Library GBean ................................... SUCCESS
[0.657s]
[INFO] Shutdown Configuration ................................. SUCCESS
[0.781s]
[INFO] Tomcat Configuration for the J2EE Server ............... SUCCESS
[1.187s]
[INFO] Tomcat Deployer Configuration for performing J2EE deployments
SUCCESS [1.094s]
[INFO] Configuration for no j2ee app clients .................. SUCCESS
[0.781s]
[INFO] Configuration for no EJBs .............................. SUCCESS
[0.672s]
[INFO] Unavailable Web Services deployer ...................... SUCCESS
[0.687s]
[INFO]
----------------------------------------------------------------------------
[INFO]
----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
----------------------------------------------------------------------------
[INFO] Total time: 33 seconds
[INFO] Finished at: Tue May 23 22:48:00 EDT 2006
--- David Jencks <da...@yahoo.com> wrote:
> I won't know this will work until I see it in action :-) but this
> basically looks good to me.
> On May 23, 2006, at 6:12 AM, anita kulshreshtha wrote:
>
> > David J,
> > Based on your suggestions, I have used the following
> > conventions to
> > add dependency elements to the plan file :
> > type = jar/unspecified : generate <import>classes</import>
>
> I don't think this is needed, since if you don't specify anything you
>
> get whatever is available: for a plain jar that's just classes.
> > If the version is specified, it is kept
> > otherwise
> >
> > an available version is chosen.
>
> I think since we can interpolate versions ourselves we should leave
> out the version if it is not in the pom.xml.
>
> > type = car : The scope element is used as follows:
> > unspecified : It is a parent configuration and added to the
> >
> > plan.xml
> > provided : It is used to force the build order on the
> > configurations in a multi project build. This
> > dependency is not added to the generated plan.
>
> After some further thought I'm not 100% sure we need to specify the
> startup order explicitly. I think that recursive loading of parents
>
> will be sufficient. This needs some testing, and if we can leave out
>
> the explicit orders we should.
> > compile : generate <import>classes</import>
> > runtime : generate <import>services</import>
> This part seems reasonable, but we haven't really specified the
> import element anywhere yet: I think we'll have to try it and see.
>
> With your settings here does the plugin work? I can't wait for an m2
>
> build!
>
> thanks
> david jencks
>
> >
> > Thnaks
> > Anita
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: m2 : packaging plugin
Posted by David Jencks <da...@yahoo.com>.
I won't know this will work until I see it in action :-) but this
basically looks good to me.
On May 23, 2006, at 6:12 AM, anita kulshreshtha wrote:
> David J,
> Based on your suggestions, I have used the following
> conventions to
> add dependency elements to the plan file :
> type = jar/unspecified : generate <import>classes</import>
I don't think this is needed, since if you don't specify anything you
get whatever is available: for a plain jar that's just classes.
> If the version is specified, it is kept
> otherwise
>
> an available version is chosen.
I think since we can interpolate versions ourselves we should leave
out the version if it is not in the pom.xml.
> type = car : The scope element is used as follows:
> unspecified : It is a parent configuration and added to the
>
> plan.xml
> provided : It is used to force the build order on the
> configurations in a multi project build. This
> dependency is not added to the generated plan.
After some further thought I'm not 100% sure we need to specify the
startup order explicitly. I think that recursive loading of parents
will be sufficient. This needs some testing, and if we can leave out
the explicit orders we should.
> compile : generate <import>classes</import>
> runtime : generate <import>services</import>
This part seems reasonable, but we haven't really specified the
import element anywhere yet: I think we'll have to try it and see.
With your settings here does the plugin work? I can't wait for an m2
build!
thanks
david jencks
>
> Thnaks
> Anita
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com