Best way to extend install plugin?

[Tim Moloney <t....@verizon.net>]

I'd like to add a little extra functionality to the maven-install-plugin 
(create/update an xml file based on the jar being installed).  I tried 
creating my own plugin which subclassed InstallMojo, but I ended up with 
a NPE inside InstallMojo.  I think that InstallMojo's class variables 
aren't getting initialized by the javadoc handling of maven-plugin-plugin.

Is it possible to subclass Mojos?  If so, how do I get around the NPE?  
If not, what is the best way to extend an existing Mojo?

Thanks,
  Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Tim Moloney <t....@verizon.net>]

Eric Redmond wrote:
> On 2/18/07, Tim Moloney <t....@verizon.net> wrote:
> > Can two bundles be bound to the same phase as default?
>
> Yes, you can write a comma-seperated list of goals in the phase field of
> your packaging extension.
>
> For example, the definition of the maven-plugin lifecycle mapping for 
> phase
> is:
>
>              <package>
>                org.apache.maven.plugins:maven-jar-plugin:jar,
>
> org.apache.maven.plugins:maven-plugin-plugin:addPluginArtifactMetadata
>              </package>

Sweet!  Thanks.  :)

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Eric Redmond <er...@gmail.com>]

On 2/18/07, Tim Moloney <t....@verizon.net> wrote:
>
> Tom Huybrechts wrote:
> > Extending existing mojo's doesn't work very well, because the
> > parameters for the extended mojo are not injected.
>
> Thanks, you confirmed my diagnosis.  :)
>
> > Do you really need to subclass ? Can't you just write an additional
> > mojo and bind that to the install phase, next to the ordinary install?
>
> I was planning on adding the new Mojo to maven-bundle-plugin (in Felix),
> binding it to the install phase, and changing the default install phase
> to use maven-bundle-plugin.  If the new Mojo subclassed InstallMojo from
> maven-install-plugin, it would have all the functionality of
> maven-install-plugin plus the functionality to create/update the OBR
> repository.xml file.
>
> If I mangaed to get that working (and I was very ambitious), I would
> then add another Mojo to maven-bundle-plugin, bound to the deploy phase,
> that would deploy a bundle to a remote OBR, updating its
> repository.xml.  Similarly, it would subclass DeployMojo from
> maven-deploy-plugin and add the functionality to create/update the
> remote repository.xml file.
>
> When completed, bundle developers would get the appropriate default
> behavior for the package, install, and deploy phases by specifying
> <packaging>bundle</packaging> in their pom file.
>
> Is there a better way?


Probably not - this looks like a perfect case for creating your own custom
type.

Can two bundles be bound to the same phase as
> default?


Yes, you can write a comma-seperated list of goals in the phase field of
your packaging extension.

For example, the definition of the maven-plugin lifecycle mapping for phase
is:

              <package>
                org.apache.maven.plugins:maven-jar-plugin:jar,

org.apache.maven.plugins:maven-plugin-plugin:addPluginArtifactMetadata
              </package>


If not, what exactly would I add to a pom.xml to run the new
> Mojo "next to the ordinary install"?
>
> > And when you have the OBR plugin, would you mind sharing it :) ?
> >
> > Tom
>
> Yes, I was going to contribute the patch to Felix.
>
> Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond

Re: Creating a new build type - InstallShiled

[Dan Tran <da...@gmail.com>]

use antrun to populate staging area
use exec to run installshield builder
use build-helper to attach installershield output to maven so that it can be
deployed.

-D


On 2/18/07, Rahamim, Zvi (Zvi) <zr...@avaya.com> wrote:
>
> The problem is that I don't know how to create this new type (life
> cycle, mojo/es, how to connect between all...)
>
> -----Original Message-----
> From: Dan Tran [mailto:dantran@gmail.com]
> Sent: Sunday, February 18, 2007 6:39 PM
> To: Maven Users List
> Subject: Re: Creating a new build type - InstallShiled
>
> what is the problem you are facing?
>
> -D
>
>
> On 2/18/07, Rahamim, Zvi (Zvi) <zr...@avaya.com> wrote:
> >
> > Hi
> > I have a new type of project: build install shield project.
> > This build require to get files from the version control, copy files
> > from remote repository and execute a command line.
> > I believe creating a plug-in is not enough, Can you tell me what I
> > should do?
> > Thanks!
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

RE: Creating a new build type - InstallShiled

["Rahamim, Zvi (Zvi)" <zr...@avaya.com>]

The problem is that I don't know how to create this new type (life
cycle, mojo/es, how to connect between all...)

-----Original Message-----
From: Dan Tran [mailto:dantran@gmail.com] 
Sent: Sunday, February 18, 2007 6:39 PM
To: Maven Users List
Subject: Re: Creating a new build type - InstallShiled

what is the problem you are facing?

-D


On 2/18/07, Rahamim, Zvi (Zvi) <zr...@avaya.com> wrote:
>
> Hi
> I have a new type of project: build install shield project.
> This build require to get files from the version control, copy files 
> from remote repository and execute a command line.
> I believe creating a plug-in is not enough, Can you tell me what I 
> should do?
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Creating a new build type - InstallShiled

[Dan Tran <da...@gmail.com>]

what is the problem you are facing?

-D


On 2/18/07, Rahamim, Zvi (Zvi) <zr...@avaya.com> wrote:
>
> Hi
> I have a new type of project: build install shield project.
> This build require to get files from the version control, copy files
> from remote repository and execute a command line.
> I believe creating a plug-in is not enough,
> Can you tell me what I should do?
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Creating a new build type - InstallShiled

["Rahamim, Zvi (Zvi)" <zr...@avaya.com>]

Hi
I have a new type of project: build install shield project.
This build require to get files from the version control, copy files
from remote repository and execute a command line.
I believe creating a plug-in is not enough,
Can you tell me what I should do?
Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Tim Moloney <t....@verizon.net>]

Tom Huybrechts wrote:
> Extending existing mojo's doesn't work very well, because the
> parameters for the extended mojo are not injected.

Thanks, you confirmed my diagnosis.  :)

> Do you really need to subclass ? Can't you just write an additional
> mojo and bind that to the install phase, next to the ordinary install?

I was planning on adding the new Mojo to maven-bundle-plugin (in Felix), 
binding it to the install phase, and changing the default install phase 
to use maven-bundle-plugin.  If the new Mojo subclassed InstallMojo from 
maven-install-plugin, it would have all the functionality of 
maven-install-plugin plus the functionality to create/update the OBR 
repository.xml file.

If I mangaed to get that working (and I was very ambitious), I would 
then add another Mojo to maven-bundle-plugin, bound to the deploy phase, 
that would deploy a bundle to a remote OBR, updating its 
repository.xml.  Similarly, it would subclass DeployMojo from 
maven-deploy-plugin and add the functionality to create/update the 
remote repository.xml file.

When completed, bundle developers would get the appropriate default 
behavior for the package, install, and deploy phases by specifying 
<packaging>bundle</packaging> in their pom file.

Is there a better way?  Can two bundles be bound to the same phase as 
default?  If not, what exactly would I add to a pom.xml to run the new 
Mojo "next to the ordinary install"?

> And when you have the OBR plugin, would you mind sharing it :) ?
>
> Tom

Yes, I was going to contribute the patch to Felix.

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Tom Huybrechts <to...@gmail.com>]

Extending existing mojo's doesn't work very well, because the
parameters for the extended mojo are not injected.

Do you really need to subclass ? Can't you just write an additional
mojo and bind that to the install phase, next to the ordinary install
?
And when you have the OBR plugin, would you mind sharing it :) ?

Tom

On 2/17/07, Tim Moloney <t....@verizon.net> wrote:
> Wendy Smoak wrote:
> > On 2/17/07, Tim Moloney <t....@verizon.net> wrote:
> >
> >> I'd like to add a little extra functionality to the maven-install-plugin
> >> (create/update an xml file based on the jar being installed).
> >
> > Does your file go inside the jar, beside it in the repository, or
> > somewhere else?
> >
> > Maven already writes and updates the xml metadata files in its
> > repositories, so there should be some code to borrow if that's what
> > you need to do.
> >
>
> The file would be in the root of the local repository
> (~/.m2/repository/repository.xml) and allow the local repository to also
> be an OSGi bundle repository (OBR).
>
> I know that I can get things working by copying existing code into my
> plugin.  However, that's not the best implementation from a maintenance
> point of view.  I was hoping to write a plugin that called the code in
> maven-install-plugin (to keep present and future compatibility) and just
> add my little bit.
>
> Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Tim Moloney <t....@verizon.net>]

Wendy Smoak wrote:
> On 2/17/07, Tim Moloney <t....@verizon.net> wrote:
>
>> I'd like to add a little extra functionality to the maven-install-plugin
>> (create/update an xml file based on the jar being installed).
>
> Does your file go inside the jar, beside it in the repository, or
> somewhere else?
>
> Maven already writes and updates the xml metadata files in its
> repositories, so there should be some code to borrow if that's what
> you need to do.
>

The file would be in the root of the local repository 
(~/.m2/repository/repository.xml) and allow the local repository to also 
be an OSGi bundle repository (OBR).

I know that I can get things working by copying existing code into my 
plugin.  However, that's not the best implementation from a maintenance 
point of view.  I was hoping to write a plugin that called the code in 
maven-install-plugin (to keep present and future compatibility) and just 
add my little bit.

Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to extend install plugin?

[Wendy Smoak <ws...@gmail.com>]

On 2/17/07, Tim Moloney <t....@verizon.net> wrote:

> I'd like to add a little extra functionality to the maven-install-plugin
> (create/update an xml file based on the jar being installed).

Does your file go inside the jar, beside it in the repository, or
somewhere else?

Maven already writes and updates the xml metadata files in its
repositories, so there should be some code to borrow if that's what
you need to do.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org