Trygve,

Many thanks for the detailed response. It's been very helpful. I've been
going through the m2 plugins in svn but armed with your advice I think I can
progress now.

Brett, if you could point me to the partially done/defunct dotnet plugin
when you've checked it in I'll try and steal as much from this as possible.
Thanks for the advice. 

I'll keep the list updated with my progress and submit the plugin when it
gets to a decent standard.

Cheers,

Chris

-----Original Message-----
From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] 
Sent: 08 August 2005 17:43
To: Maven Users List
Subject: Re: [m2] Advice on creating a plugin to compile and deploy dotnet
pro jects

On Mon, Aug 08, 2005 at 05:05:49PM +0100, Stevenson, Chris wrote:
> Hello All,
>  
> I'm looking for a bit of advice from any of the plugin developers out
there.
> 
>  
> I'm currently in the process of reviewing m2 before my team upgrade 
> from Maven 1.0. As part of this we need to build a Maven2 plugin to 
> compile dotnet dll's and install them into the repository. We 
> previously achieved this through several generous helpings of jelly 
> but I'd like to move it over to the new m2 Mojo architecture. However, 
> I'm a little confused at where to start.
>  
> What I want to achieve:
>  
> - Write a Mojo to wrap the CSC/Mono exe which compiles all the source 
> in the src/main/dotnet directory to the a dll with the finalName 
> property in Maven2

There I think that you should be able to reuse the existing compiler and
test compiler mojo and just write a new implementation of the Plexus
Compiler interface. The Plexus Compiler interface can be checked out from
[1] using Subversion.

As I'm pretty .NET cluefree, will the CSC/Mono compiler compile all types of
.NET source code? Or only a specific subset? Can new languanges be supported
using plugin to the compiler?

> - Write a Mojo to wrap the CSC/Mono exe which compiles all the test 
> resources in the test dir

Compiles the test resources?

> - Write a Mojo to wrap the Nunit exe which will run all of the Nunit 
> tests and which depends on the compile step to have occurred
> - Hook these into the build schedule at the right points.

Here you want to implement your own "dotnet" or "dotnet-assembly"
lifecycle. This lifecycle will be selected by setting
<packaging>dotnet</packaging>. The a lifecycle will set default values for
what plugins to run when. If you in [2] look for the LifecycleMapping you
can see the different lifecycles already implemented.

> - Use the existing M2 infrastructure to deploy it out to repository 
> and get in back as req..
>  
> What I need to do seems to be:
>  
> - Create the pom.xml detailing that the plugin will be this will 
> probably contain only the references to the standards:
>  
>     <dependency>
>       <groupId>org.apache.maven</groupId>
>       <artifactId>maven-project</artifactId>
>       <version>2.0-beta-1-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.maven</groupId>
>       <artifactId>maven-artifact</artifactId>
>       <version>2.0-beta-1-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.maven</groupId>
>       <artifactId>maven-artifact-manager</artifactId>
>       <version>2.0-beta-1-SNAPSHOT</version>
>     </dependency>
>  
> - Specificfy in the javadoc annotations where I'd like the 2 plugins 
> to occur in the build cycle:
>    ie: CSC/Mono compile would be either compile or package I guess.
>    the CSC/Mono Test compile would occur in  test  and the Nunit 
> wrapper would also occur in test after the compile.
> - In the projects that will use the plugin set the output 
> type/packaging as "dll"?

John Casey suggested "dotnet-assembly" as the packaging type, dll is only
the file format. What you also need to implement is the ArtifactHandler[3]
interface and declare that like in [4].

>  
> My questions are really:
>  
> - How can I inject the project information into the plugin, I can see 
> that it is through the annotations in the existing plugins but is that 
> all I need to do?

Yeah, that's all you need to do. As you're going to make stuff that's pretty
similar to what we already have for Java stuff I suggest that you take a
look at the existing plugins and how they're written.

> - Is there anything else I need to specify other than annotation to 
> get the plugin to run at the correct point in build process?
> - When I've set the type in the pom of the dotnet projects that will 
> use the plugin to "dll" and my new plugin has built the dll's will m2 
> pick them up and run with them and stick them in the repo without any more
configuration?

In you .net projects you'll need to set
<packaging>dotnet-assembly</packaging> and Maven will pick your new dotnet
lifecycle. When installing the artifact the install plugin will look at the
packaging of the project and use the correct artifact handler to install it.

You will also need to include a reference to the
maven-dotnet-assembly-plugin (which is the one you're writing) in your
projects and set <extensions>true</extensions> so that Maven knows to pick
up the extensions you're bringing to the core.

> Any other comments/recommendations would be greatly appreciated.

[1]:
https://svn.codehaus.org/plexus/trunk/plexus-components/plexus-compiler/
[2]:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/
resources/META-INF/plexus/components.xml
[3]:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact/src/m
ain/java/org/apache/maven/artifact/handler/ArtifactHandler.java
[4]:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact/src/m
ain/resources/META-INF/plexus/components.xml

--
Trygve


--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to 
http://www.drkw.com/disc/email/ or contact the sender. 3167
--------------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to