maven extension : adding a custom ArtifactHandler
Hello, I'd like to add support in maven for a custom packaging. I've created a META-INF/plexus/components.xml to define a new ArtifactHandler : component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintjavascript/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typejavascript/type extensionjsar/extension languagejavascript/language addedToClasspathfalse/addedToClasspath /configuration /component I the run mvn install from a test project that has a dependency of type javascript and defines my custom plugin as a build extension. The requested URL in my repo uses the unexpected .javascript extension. Runing maven in a debug session, in DefaultWagonManager.getArtifact() the requested artifact doens't have my custom handler attached, but what seems to be the default one for unresolved types. Is this the good way to extend maven ? What's wrong ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[resolved] maven extension : adding a custom ArtifactHandler
I just understood I have to configure the plugin in the build/plugins element with extensionstrue/extensions What's the meaning of the build/extensions element ? 2007/10/1, nicolas de loof [EMAIL PROTECTED]: Hello, I'd like to add support in maven for a custom packaging. I've created a META-INF/plexus/components.xml to define a new ArtifactHandler : component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintjavascript/role-hint implementation org.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typejavascript/type extensionjsar/extension languagejavascript/language addedToClasspathfalse/addedToClasspath /configuration /component I the run mvn install from a test project that has a dependency of type javascript and defines my custom plugin as a build extension. The requested URL in my repo uses the unexpected .javascript extension. Runing maven in a debug session, in DefaultWagonManager.getArtifact() the requested artifact doens't have my custom handler attached, but what seems to be the default one for unresolved types. Is this the good way to extend maven ? What's wrong ? Nico.
Re: [resolved] maven extension : adding a custom ArtifactHandler
I had this problem (It's a bug and also a problem in the conception of the
core) and I solved it like this :
package com.octo.mtg.plugin;
import java.io.File;
import org.apache.maven.artifact.handler.ArtifactHandler;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
import org.apache.maven.project.MavenProject;
/**
* Creates a WAR archive and register it in maven.
*
* @author a href=mailto:[EMAIL PROTECTED]Arnaud HERITIER/a
* @version $Id$
*
* @description Creates a WAR archive and register it in maven.
* @goal maven-war
* @phase package
* @since 0.1
*/
public class MavenWarMojo extends AbstractGrailsMojo {
/**
* The maven project.
*
* @parameter expression=${project}
* @required
* @readonly
*/
private MavenProject project;
/**
* The artifact handler.
*
* @parameter
expression=${component.org.apache.maven.artifact.handler.ArtifactHandler#grails-app}
* @required
* @readonly
*/
protected ArtifactHandler artifactHandler;
/**
* Executes the MavenWarMojo on the current project.
*
* @throws MojoExecutionException
* if an error occured while building the webapp
*/
public void execute() throws MojoExecutionException,
MojoFailureException {
// launch grails
launchGrails(war);
File warGeneratedByGrails = new File(getBasedir(),
getGrailsDescriptor().getAppName() + -
+
getGrailsDescriptor().getAppVersion() + .war);
project.getArtifact().setFile(warGeneratedByGrails);
project.getArtifact().setArtifactHandler(artifactHandler);
}
}
You have to manually set the file and the artifact handler
Arnaud
http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin/src/main/java/com/octo/mtg/plugin/MavenWarMojo.java
On 01/10/2007, nicolas de loof [EMAIL PROTECTED] wrote:
I just understood I have to configure the plugin in the build/plugins
element with extensionstrue/extensions
What's the meaning of the build/extensions element ?
2007/10/1, nicolas de loof [EMAIL PROTECTED]:
Hello,
I'd like to add support in maven for a custom packaging.
I've created a META-INF/plexus/components.xml to define a new
ArtifactHandler :
component
roleorg.apache.maven.artifact.handler.ArtifactHandler/role
role-hintjavascript/role-hint
implementation
org.apache.maven.artifact.handler.DefaultArtifactHandler/implementation
configuration
typejavascript/type
extensionjsar/extension
languagejavascript/language
addedToClasspathfalse/addedToClasspath
/configuration
/component
I the run mvn install from a test project that has a dependency of
type javascript and defines my custom plugin as a build extension.
The requested URL in my repo uses the unexpected .javascript
extension.
Runing maven in a debug session, in DefaultWagonManager.getArtifact()
the requested artifact doens't have my custom handler attached, but
what seems to be the default one for unresolved types.
Is this the good way to extend maven ? What's wrong ?
Nico.
--
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...
Re: An Experiment with GIT
Jason van Zyl wrote: On 30 Sep 07, at 12:23 PM 30 Sep 07, Mauro Talevi wrote: This is a comparison with SVN I've found on the Git site: http://git.or.cz/gitwiki/GitSvnComparsion But one of the main issues IMO is the integration with IDEs - it took quite a long time for SVN to catch up to CVS standards. Until an analogous level is available for Git, how many will be willing to consider trading in the ease of development for the advantages it may offer? We're not going to be using GIT at Apache. In this case it's use GIT versus mail patches. I don't expect a landslide of people using this method, just the most determined and those who understand that using an SCM while working on their changes is a good idea. There is just no way to work like this with SVN, it was just not designed to work like this. Some one who is not a committer cannot incrementally check in their changes so the existing IDE integration doesn't help in this regard. There is someone working on an Eclipse GIT plugin, but anyone wanting to use the standard SVN diff and attach patches to JIRA can continue to do so. It's not like it's one or the other. Well - if the proposal is of an optional layer that sits on top of SVN and provides easy branching for patch submission/tracking, then yes it seems OTOH something really worth exploring. Once the Git infrastructure has been set up I'd be up for taking it for a spin. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CONTINUUM-310 - customizable email templates
This was marked closed, should it have been? I still see no way of allowing the user to customize the content of the email body. Right now the velocity templates are part of the continuum-core project and are buried inside the core.jar so it's not easy for the users to edit the template. What does everybody think about adding a step to the continuum-webapp project that extracts the templates from the continuum-core.jar and puts a copy of them in the WEB-INF/classes directory. When the mail notifier loads the templates it should find the ones in the WEB-INF/classes before the ones in the jar and run with those. That way the users can edit them and customize them any way they want. -- tom
Re: [discuss] Graduate Continuum to its own TLP
Jesse McConnell wrote: I actually would prefer to have an increased focus on maven and maven2 integration. tbh there are many different continuous integration servers and the ties with maven could be increased some more and leverage some really nice features in maven. I don't really think continuum needs to really try and compete in the shell script launched builds and tying ourselves to these kinda ideas limits the fun things that can be done. with increased maven integration we could integrate build and reporting tools automatically into the builds, just injecting these kinda reports into maven2 projects that are under CI. lots of things possible but increasing the maven2 support just my thoughts :) I'm not saying it should not have strong support and integration with m2. Just that it if Continuum wants to graduate from under the wings of maven umbrella, it should also address the concerns of other build systems. As much as possible try to offer the same feature set to all build tools, but also offer extra functionality leveraging on m2 features where it can. Cheers
Re: [resolved] maven extension : adding a custom ArtifactHandler
This artifact handler bug has proven a problem for me as well. Maven does
pick up and maintain the handlers from the components.xml file; it just
doesn't add them to the ArtifactHandlerManager, making the
handlers inaccessible to the ArtifactFactory, which creates the respective
artifacts. If you need to add multiple handlers, you could take the list of
artifact handlers and programmaticly add any missing ones to the
ArtifactHandlerManager. This should also be relatively simple to fix within
the core.
Shane
On 10/1/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:
I had this problem (It's a bug and also a problem in the conception of the
core) and I solved it like this :
package com.octo.mtg.plugin;
import java.io.File;
import org.apache.maven.artifact.handler.ArtifactHandler;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
import org.apache.maven.project.MavenProject;
/**
* Creates a WAR archive and register it in maven.
*
* @author a href=mailto:[EMAIL PROTECTED]Arnaud HERITIER/a
* @version $Id$
*
* @description Creates a WAR archive and register it in maven.
* @goal maven-war
* @phase package
* @since 0.1
*/
public class MavenWarMojo extends AbstractGrailsMojo {
/**
* The maven project.
*
* @parameter expression=${project}
* @required
* @readonly
*/
private MavenProject project;
/**
* The artifact handler.
*
* @parameter expression=${
component.org.apache.maven.artifact.handler.ArtifactHandler#grails-app}
* @required
* @readonly
*/
protected ArtifactHandler artifactHandler;
/**
* Executes the MavenWarMojo on the current project.
*
* @throws MojoExecutionException
* if an error occured while building the webapp
*/
public void execute() throws MojoExecutionException,
MojoFailureException {
// launch grails
launchGrails(war);
File warGeneratedByGrails = new File(getBasedir(),
getGrailsDescriptor().getAppName() + -
+
getGrailsDescriptor().getAppVersion() + .war);
project.getArtifact().setFile(warGeneratedByGrails);
project.getArtifact().setArtifactHandler(artifactHandler);
}
}
You have to manually set the file and the artifact handler
Arnaud
http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin/src/main/java/com/octo/mtg/plugin/MavenWarMojo.java
On 01/10/2007, nicolas de loof [EMAIL PROTECTED] wrote:
I just understood I have to configure the plugin in the build/plugins
element with extensionstrue/extensions
What's the meaning of the build/extensions element ?
2007/10/1, nicolas de loof [EMAIL PROTECTED]:
Hello,
I'd like to add support in maven for a custom packaging.
I've created a META-INF/plexus/components.xml to define a new
ArtifactHandler :
component
roleorg.apache.maven.artifact.handler.ArtifactHandler/role
role-hintjavascript/role-hint
implementation
org.apache.maven.artifact.handler.DefaultArtifactHandler
/implementation
configuration
typejavascript/type
extensionjsar/extension
languagejavascript/language
addedToClasspathfalse/addedToClasspath
/configuration
/component
I the run mvn install from a test project that has a dependency of
type javascript and defines my custom plugin as a build extension.
The requested URL in my repo uses the unexpected .javascript
extension.
Runing maven in a debug session, in DefaultWagonManager.getArtifact()
the requested artifact doens't have my custom handler attached, but
what seems to be the default one for unresolved types.
Is this the good way to extend maven ? What's wrong ?
Nico.
--
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...
Re: An Experiment with GIT
Ok, everything seemed have loaded over night. I'll now work on publishing and setting up webgit. On 1 Oct 07, at 4:23 AM 1 Oct 07, Mauro Talevi wrote: Jason van Zyl wrote: On 30 Sep 07, at 12:23 PM 30 Sep 07, Mauro Talevi wrote: This is a comparison with SVN I've found on the Git site: http://git.or.cz/gitwiki/GitSvnComparsion But one of the main issues IMO is the integration with IDEs - it took quite a long time for SVN to catch up to CVS standards. Until an analogous level is available for Git, how many will be willing to consider trading in the ease of development for the advantages it may offer? We're not going to be using GIT at Apache. In this case it's use GIT versus mail patches. I don't expect a landslide of people using this method, just the most determined and those who understand that using an SCM while working on their changes is a good idea. There is just no way to work like this with SVN, it was just not designed to work like this. Some one who is not a committer cannot incrementally check in their changes so the existing IDE integration doesn't help in this regard. There is someone working on an Eclipse GIT plugin, but anyone wanting to use the standard SVN diff and attach patches to JIRA can continue to do so. It's not like it's one or the other. Well - if the proposal is of an optional layer that sits on top of SVN and provides easy branching for patch submission/tracking, then yes it seems OTOH something really worth exploring. Once the Git infrastructure has been set up I'd be up for taking it for a spin. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site skin
It worked ok for me when I tried it a while back. Did you add the skin config to your project's site.xml? project ... skin groupIdorg.apache.maven.skins/groupId artifactIdmaven-classic-skin/artifactId version1.0/version /skin ... /project Brian E. Fox wrote: I followed the instructions here: http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins .html And copied the default-site.vm to my skin, but when velocity is processing, my site.vm is completely ignored. What's missing? --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
any war plugin hack ?
Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico.
RE: any war plugin hack ?
None that I know of, and I don't think the 2.1 will change this. The war plugin is the code doing all the work to pull things together. So unless the war plugin was broken into two separate mojos, it would still have the effect of being a single black box. -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 1:00 PM To: dev@maven.apache.org Subject: any war plugin hack ? Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any war plugin hack ?
I agree, I was just meaning I can wait maven 2.1 to introduce the pre-package pahse, AND the war plugin to honor this new phase 2007/10/1, Brian E. Fox [EMAIL PROTECTED]: None that I know of, and I don't think the 2.1 will change this. The war plugin is the code doing all the work to pull things together. So unless the war plugin was broken into two separate mojos, it would still have the effect of being a single black box. -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 1:00 PM To: dev@maven.apache.org Subject: any war plugin hack ? Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: site skin
Yes. It was in fact the maven site I was trying to change. I changed the stylus skin and installed a snapshot and updated the site.xml. All the -X logs from velocity only mention the default-site.vm, not my site.vm. -Original Message- From: Paul Gier [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 12:29 PM To: Maven Developers List Subject: Re: site skin It worked ok for me when I tried it a while back. Did you add the skin config to your project's site.xml? project ... skin groupIdorg.apache.maven.skins/groupId artifactIdmaven-classic-skin/artifactId version1.0/version /skin ... /project Brian E. Fox wrote: I followed the instructions here: http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins .html And copied the default-site.vm to my skin, but when velocity is processing, my site.vm is completely ignored. What's missing? --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any war plugin hack ?
In the maven-js-plugin, we process the exploded web-app that gets built along side the WAR and either re-create the WAR or create a second one based on user preferences. It might work for what you need. On 10/1/07, nicolas de loof [EMAIL PROTECTED] wrote: I agree, I was just meaning I can wait maven 2.1 to introduce the pre-package pahse, AND the war plugin to honor this new phase 2007/10/1, Brian E. Fox [EMAIL PROTECTED]: None that I know of, and I don't think the 2.1 will change this. The war plugin is the code doing all the work to pull things together. So unless the war plugin was broken into two separate mojos, it would still have the effect of being a single black box. -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 1:00 PM To: dev@maven.apache.org Subject: any war plugin hack ? Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adam Altemus Software Engineer
RE: any war plugin hack ?
Or just use the dependency plugin to unpack the just-created-war. Not optimal but neither is creating it twice. -Original Message- From: Adam Altemus [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 4:57 PM To: Maven Developers List Subject: Re: any war plugin hack ? In the maven-js-plugin, we process the exploded web-app that gets built along side the WAR and either re-create the WAR or create a second one based on user preferences. It might work for what you need. On 10/1/07, nicolas de loof [EMAIL PROTECTED] wrote: I agree, I was just meaning I can wait maven 2.1 to introduce the pre-package pahse, AND the war plugin to honor this new phase 2007/10/1, Brian E. Fox [EMAIL PROTECTED]: None that I know of, and I don't think the 2.1 will change this. The war plugin is the code doing all the work to pull things together. So unless the war plugin was broken into two separate mojos, it would still have the effect of being a single black box. -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 1:00 PM To: dev@maven.apache.org Subject: any war plugin hack ? Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adam Altemus Software Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any war plugin hack ?
Thanks for those ideas. 2007/10/1, Brian E. Fox [EMAIL PROTECTED]: Or just use the dependency plugin to unpack the just-created-war. Not optimal but neither is creating it twice. -Original Message- From: Adam Altemus [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 4:57 PM To: Maven Developers List Subject: Re: any war plugin hack ? In the maven-js-plugin, we process the exploded web-app that gets built along side the WAR and either re-create the WAR or create a second one based on user preferences. It might work for what you need. On 10/1/07, nicolas de loof [EMAIL PROTECTED] wrote: I agree, I was just meaning I can wait maven 2.1 to introduce the pre-package pahse, AND the war plugin to honor this new phase 2007/10/1, Brian E. Fox [EMAIL PROTECTED]: None that I know of, and I don't think the 2.1 will change this. The war plugin is the code doing all the work to pull things together. So unless the war plugin was broken into two separate mojos, it would still have the effect of being a single black box. -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 1:00 PM To: dev@maven.apache.org Subject: any war plugin hack ? Hello, is there any way to process the explosed webapp before it gets packaged into a .war ? I could wait for maven 2.1 and the pre-package phase, but I need a solution now... There seems not to be an official way to hook into the war plugin, but maybe some at your own risk hack is possible ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adam Altemus Software Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
