Where do I put non-java project common files?
I have n projects:
project_super: Aggregates the projects project_subi. Just a "pom-project".
project_sub1 : Inherits project_super
...
project_subi : Inherits project_super
...
roject_subn : Inherits project_super
1)
Most projects project_subi have an assembly descriptor sited in their
${basedir}\src\main\resources-build directories. They are identical. As n
gets big, these identical files will proliferate with the maintenance
overhead following. I guess this file could be "stored/defined" in
project_super and referred to by project_subi. How do I achieve this
conforming to best practices?
2)
Moreover, most project_subi uses this assembly descriptor in an identical
way, i.e. using the "maven-assembly-plugin". The plugin definitions are
identical. I.e. each project_subi pom contains exactly:
...
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-4
Package installation archive...
pre-integration-test
${basedir}/src/main/resources-build/assembly.descriptor.installation.archive.xml
target
target
assembly
...
Could this somehow be defined in project_super and be referred to (run) by
the relevant projects project_subi?
--
View this message in context:
http://maven.40175.n5.nabble.com/Where-do-I-put-non-java-project-common-files-tp401369p401369.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Problem using maven-deploy-plugin against an https server via proxy
Hi, I am trying to deploy a snapshot of an Apache project to https://repository.apache.org/content/repositories/snapshots. From my point of view, the configuration is correct: I have a "server" entry in my settings.xml and I have configured an https proxy. (See "Adding User-Agent configuration" and "Using Proxy: ..." below.) Nevertheless, the deploy-plugin fails with the following error message: Caused by: java.net.UnknownHostException: repository.apache.org In other words, it seems that the proxy is unused and a direct connection is attempted, which, of course, fails. (We can't even resolve external host names in the corporate network.) Maven version: bash-3.2$ mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Any ideas what I might try? Thanks, Jochen -- Germanys national anthem is the most boring in the world - how telling! [INFO] Retrieving previous build number from apache.snapshots.https [DEBUG] Using Wagon implementation lightweight from default mapping for protocol https [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'apache.snapshots.https' with url: 'https://repository.apache.org/content/repositories/snapshots'. [DEBUG] Using Proxy: 10.175.249.65 [DEBUG] Using Wagon implementation lightweight from default mapping for protocol https [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error retrieving previous build number for artifact 'org.apache.rat:apache-rat-project:pom': repository metadata for: 'snapshot org.apache.rat:apache-rat-project:0.7-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file: repository.apache.org [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error retrieving previous build number for artifact 'org.apache.rat:apache-rat-project:pom': repository metadata for: 'snapshot org.apache.rat:apache-rat-project:0.7-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file: repository.apache.org at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error retrieving previous build number for artifact 'org.apache.rat:apache-rat-project:pom': repository metadata for: 'snapshot org.apache.rat:apache-rat-project:0.7-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file: repository.apache.org at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:189) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error retrieving previous build number for artifact 'org.apache.rat:apache-rat-project:pom': repository metadata for: 'snapshot org.apache.rat:apache-rat-project:0.7-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file: repository.apach
Re: Strange surefire error
Does it fail "immediately" or does it run the tests first ? Is the plugin configured with forkedProcessTimeoutInSeconds ? Kristian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problems with jar in central?
http://jira.codehaus.org/browse/MEV /Anders On Mon, Jun 14, 2010 at 23:58, Zac Thompson wrote: > Is there a place to report issues with the contents of maven central? > Or does it need to be reported to each project's maintainers? > > > https://repository.sonatype.org/content/repositories/central/org/codehaus/woodstox/stax2-api/3.0.1/ > > the jar.sha1 file reads > > 88985bfab2394cf8e56fcbd97cd44f7cac7bf8ca > > But when I check the jar file, I get > > 12393455d7d25eab09bb9b2043b6df13406ec70d > > Even worse, they're both wrong according to the codehaus repo: > > http://repository.codehaus.org/org/codehaus/woodstox/stax2-api/3.0.1/ > > 949fc43ccaca8ed6ff31b82bf18f560a3c9a3b6e > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: mvn release:prepare cannot tag correctly from a branch
OK, I've been able to recreate this using a dummy application. I do think it's a bug, so I've raised an issue on it http://jira.codehaus.org/browse/MRELEASE-576 It does actually end up building the release and deploying the correct one. However, in the process, it's checking out the entire contents of the branches directory. Which is not very efficient in regards to build time or disk space. Thanks, Ed - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare cannot tag correctly from a branch
More info... I am trying to reorganize my maven projects. Currently, there is a single pom that declares modules and acts as a parent project to those sub-modules. When I use this structure, the correct source is used when creating the SVN tag. I'm trying to move a bunch of the declarations into a new parent module, and update those modules to use this new parent module as the parent. The root pom now only delcares the modules and no longer acts as the parent pom for the listed sub-modules. When I have this set up, the tag url is not constructed correctly. So, I must have done something wrong. Both the root pom and the parent pom have the same developerConnection element value. Will both poms require the release plugin? Or is it something else? Honestly, I don't have a clue. Thanks, Ed - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare cannot tag correctly from a branch
Hi all. Some more info... when I change the developerConnection back to the URL, it's even worse. The tag reflects the code in the trunk instead of in the branch (I can tell because the POMs have different version numbers... the tag has the version number of the trunk instead of the branch... and it's a SNAPSHOT release as well). To me, this is worse because the release:perform works great, but it's using the trunk instead of the branch. So, I don't know what I'm doing wrong. I keep seeing posts about how people cut releases from branches "all the time". What I'm seeing is something that works, but the tag being created is incorrect. So it might work, but it's not right. What do I need to do to get the SVn tag to be copied from the correct source? Thanks again for any help, Ed - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn release:prepare cannot tag correctly from a branch
I've got my Maven project checked out from a branch using SVN. The SVN repository structure is the "standard" one trunk tags branches I've checked out a working copy from a branch, and have run release:prepare on it. It all works, but then the release:perform fails. When I look at the tag in SVN, it's actually copied the branches directory, instead of the branch subdirectory within "branches". So, specifically, my POM file has the following declaration: scm:svn:svn://wallaby/webguiRepos/branches/mavenReorg However, the command output from the prepare command is [INFO] Tagging release with the label webgui-7.00.01.15... [DEBUG] ScmTagPhase :: scmTagParameters remotingTag true [DEBUG] ScmTagPhase :: scmTagParameters scmRevision 3301 [DEBUG] SvnTagCommand :: scmTagParameters.remoteTagging : true [INFO] Executing: /bin/sh -c cd /u01/wb/ehillman/webgui-src && svn --non-interactive copy --file /tmp/maven-scm-1448374038.commit --revision 3301 svn://wallaby/webguiRepos/branches/ svn://wallaby/webguiRepos/tags/webgui-7.00.01.15 So, the svn command is not correct. What am I doing wrong? I've tried adding a trailing slash to the developerConnection, but it makes no difference. I'm using version 2.0 of the release plugin. It's not realistic for me to only cut releases from the trunk (which has worked fine before). Thanks for any help, Ed - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using javascript dependencies in a webapp (war packaging)
On 06/15/2010 01:55 AM, Haszlakiewicz, Eric wrote: -Original Message- From: Manos Batsis [mailto:manos_li...@geekologue.com] There is no standard convention yet AFAIK. Including the JS libs in the war is one thing, making it accessible to the browser through a specific URL is another. Well that sucks. :( Here (at Abiss.gr) we use the JStools plugin [1]; we include JS libs using JARs as everything else and a filter [2] to serve scripts to the client. I think the maven-javascript-plugin [3] has something else. Searching the archives should give more info, although both projects have pretty good documentation. Overall however, JS libs in repos have not cought on - you will have to include libs in your own repo for most stuff. [1] http://dev.abiss.gr/mvn-jstools/ [2] http://dev.abiss.gr/mvn-jstools/js-packaging.html [3] http://mojo.codehaus.org/javascript-maven-tools/ Yeah, I started to take a look at the maven-javascript-plugin, but it looks very oriented towards *developing* js packages, and I just want to *use* an existing one. It also isn't clear how to tell it where to actually put the files. I didn't see anything like that in the mvn-jstools either, and using a filter isn't going to work very well for my project. (At the moment I just need to get an existing project converted to maven with NO changes to the code at all) If you can put a JS lib as a JAR in a WAR lib as-is, the servlet filter of jstools will just look it up from the classpath and serve it. Take a look in the docos, it might work for you and worth it in actually handling JS deps. Manos I'll take a closer look tomorrow and see if there's something I can use. Thanks, eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using javascript dependencies in a webapp (war packaging)
I've worked on projects that share common javascript files, so I used a simple assembly descriptor to zip each set of files and install them as maven artifacts WAR projects then just specified them as dependencies in their POMs it's nice then to be able to treat these artifacts like any other project (versioned, deployable to a repo, etc) I used the maven-dependency plugin to unzip them to a standard folder we didn't require any parsing or compiling of the js, so this worked out fine for simple packaging and unzipping On Mon, Jun 14, 2010 at 6:23 PM, Haszlakiewicz, Eric wrote: > > I've got a webapp that uses javascript files from third party projects. > For instance, one of the files we use is prototype.js. It seems like > this must be something that many people have done in the past, but I > can't seem to find much information about it. > > The first issue I have is that I can't seem to find a maven repository > that has this file (or any of the other javascript scripts I use). Is > there one? > > Since I couldn't find one, I uploaded a copy to my local repository > (Nexus) using: > > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; > xmlns="http://maven.apache.org/POM/4.0.0"; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >4.0.0 >org.prototypejs >prototype >1.6.1 >js >http://prototypejs.org/assets/2009/8/31/prototype.js > > > and I then added an entry to the pom for my webapp: > >org.prototypejs >prototype >js >1.6.1 > > > > but I can't figure out how to get this to actually get included into the > war file. I tried configuring an overlay, but it doesn't seem to do > anything: > >org.apache.maven.plugins >maven-war-plugin > > > > org.prototypejs > prototype > js > common/javascript > > > > > > All I see is a warning when I run "mvn package": > [WARNING] Skip unpacking dependency > file[/u/ehaszla/.m2/repository/org/prototypejs/prototype/1.6.1/prototype > -1.6.1.js with unknown extension[js] > > I want to end up with a file called "prototype-1.6.1.js" in the > "common/javascript" directory within the war file. > > How do I get this to work? > > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
RE: using javascript dependencies in a webapp (war packaging)
>-Original Message- >From: Manos Batsis [mailto:manos_li...@geekologue.com] > >There is no standard convention yet AFAIK. Including the JS libs in the >war is one thing, making it accessible to the browser through a specific >URL is another. Well that sucks. :( >Here (at Abiss.gr) we use the JStools plugin [1]; we include JS libs >using JARs as everything else and a filter [2] to serve scripts to the >client. I think the maven-javascript-plugin [3] has something else. > >Searching the archives should give more info, although both projects >have pretty good documentation. Overall however, JS libs in repos have >not cought on - you will have to include libs in your own repo for most >stuff. > >[1] http://dev.abiss.gr/mvn-jstools/ >[2] http://dev.abiss.gr/mvn-jstools/js-packaging.html >[3] http://mojo.codehaus.org/javascript-maven-tools/ Yeah, I started to take a look at the maven-javascript-plugin, but it looks very oriented towards *developing* js packages, and I just want to *use* an existing one. It also isn't clear how to tell it where to actually put the files. I didn't see anything like that in the mvn-jstools either, and using a filter isn't going to work very well for my project. (At the moment I just need to get an existing project converted to maven with NO changes to the code at all) I'll take a closer look tomorrow and see if there's something I can use. Thanks, eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using javascript dependencies in a webapp (war packaging)
On 06/15/2010 01:23 AM, Haszlakiewicz, Eric wrote: I've got a webapp that uses javascript files from third party projects. For instance, one of the files we use is prototype.js. It seems like this must be something that many people have done in the past, but I can't seem to find much information about it. The first issue I have is that I can't seem to find a maven repository that has this file (or any of the other javascript scripts I use). Is there one? Since I couldn't find one, I uploaded a copy to my local repository (Nexus) using: http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> 4.0.0 org.prototypejs prototype 1.6.1 js http://prototypejs.org/assets/2009/8/31/prototype.js and I then added an entry to the pom for my webapp: org.prototypejs prototype js 1.6.1 but I can't figure out how to get this to actually get included into the war file. I tried configuring an overlay, but it doesn't seem to do anything: org.apache.maven.plugins maven-war-plugin org.prototypejs prototype js common/javascript All I see is a warning when I run "mvn package": [WARNING] Skip unpacking dependency file[/u/ehaszla/.m2/repository/org/prototypejs/prototype/1.6.1/prototype -1.6.1.js with unknown extension[js] I want to end up with a file called "prototype-1.6.1.js" in the "common/javascript" directory within the war file. How do I get this to work? There is no standard convention yet AFAIK. Including the JS libs in the war is one thing, making it accessible to the browser through a specific URL is another. Here (at Abiss.gr) we use the JStools plugin [1]; we include JS libs using JARs as everything else and a filter [2] to serve scripts to the client. I think the maven-javascript-plugin [3] has something else. Searching the archives should give more info, although both projects have pretty good documentation. Overall however, JS libs in repos have not cought on - you will have to include libs in your own repo for most stuff. [1] http://dev.abiss.gr/mvn-jstools/ [2] http://dev.abiss.gr/mvn-jstools/js-packaging.html [3] http://mojo.codehaus.org/javascript-maven-tools/ hth, Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using javascript dependencies in a webapp (war packaging)
I don't know the state of the plugin, but have a look at the Maven Javascript Plugin. http://mojo.codehaus.org/javascript-maven-tools/javascript-maven-plugin/index.html Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Tue, Jun 15, 2010 at 12:23 AM, Haszlakiewicz, Eric wrote: > > I've got a webapp that uses javascript files from third party projects. > For instance, one of the files we use is prototype.js. It seems like > this must be something that many people have done in the past, but I > can't seem to find much information about it. > > The first issue I have is that I can't seem to find a maven repository > that has this file (or any of the other javascript scripts I use). Is > there one? > > Since I couldn't find one, I uploaded a copy to my local repository > (Nexus) using: > > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; > xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > 4.0.0 > org.prototypejs > prototype > 1.6.1 > js > http://prototypejs.org/assets/2009/8/31/prototype.js > > > and I then added an entry to the pom for my webapp: > > org.prototypejs > prototype > js > 1.6.1 > > > > but I can't figure out how to get this to actually get included into the > war file. I tried configuring an overlay, but it doesn't seem to do > anything: > > org.apache.maven.plugins > maven-war-plugin > > > > org.prototypejs > prototype > js > common/javascript > > > > > > All I see is a warning when I run "mvn package": > [WARNING] Skip unpacking dependency > file[/u/ehaszla/.m2/repository/org/prototypejs/prototype/1.6.1/prototype > -1.6.1.js with unknown extension[js] > > I want to end up with a file called "prototype-1.6.1.js" in the > "common/javascript" directory within the war file. > > How do I get this to work? > > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
using javascript dependencies in a webapp (war packaging)
I've got a webapp that uses javascript files from third party projects. For instance, one of the files we use is prototype.js. It seems like this must be something that many people have done in the past, but I can't seem to find much information about it. The first issue I have is that I can't seem to find a maven repository that has this file (or any of the other javascript scripts I use). Is there one? Since I couldn't find one, I uploaded a copy to my local repository (Nexus) using: http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> 4.0.0 org.prototypejs prototype 1.6.1 js http://prototypejs.org/assets/2009/8/31/prototype.js and I then added an entry to the pom for my webapp: org.prototypejs prototype js 1.6.1 but I can't figure out how to get this to actually get included into the war file. I tried configuring an overlay, but it doesn't seem to do anything: org.apache.maven.plugins maven-war-plugin org.prototypejs prototype js common/javascript All I see is a warning when I run "mvn package": [WARNING] Skip unpacking dependency file[/u/ehaszla/.m2/repository/org/prototypejs/prototype/1.6.1/prototype -1.6.1.js with unknown extension[js] I want to end up with a file called "prototype-1.6.1.js" in the "common/javascript" directory within the war file. How do I get this to work? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
problems with jar in central?
Is there a place to report issues with the contents of maven central? Or does it need to be reported to each project's maintainers? https://repository.sonatype.org/content/repositories/central/org/codehaus/woodstox/stax2-api/3.0.1/ the jar.sha1 file reads 88985bfab2394cf8e56fcbd97cd44f7cac7bf8ca But when I check the jar file, I get 12393455d7d25eab09bb9b2043b6df13406ec70d Even worse, they're both wrong according to the codehaus repo: http://repository.codehaus.org/org/codehaus/woodstox/stax2-api/3.0.1/ 949fc43ccaca8ed6ff31b82bf18f560a3c9a3b6e - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Specifying plugin versions
Use the Maven Versions Plugin to show the latest versions of all the plugins you have specified. Most of the time the latest are the greatest. I only move back if I hit specific bugs (or I move forward if a patch is available, and make my own release) http://mojo.codehaus.org/versions-maven-plugin/display-plugin-updates-mojo.html With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Mon, Jun 14, 2010 at 11:36 PM, sebb wrote: > On 14/06/2010, Jason van Zyl wrote: >> All plugins because unfortunately we haven't had the best track record with >> respect to behavioral compatibility between releases. > > OK, thanks. > > What about the Maven Available Plugs list at [1] - can one assume that > these plugin versions will work together OK? > > [1] http://maven.apache.org/plugins/index.html > >> On Jun 14, 2010, at 1:37 PM, sebb wrote: >> >> > The guide to configuring plugins [1] says that: >> > >> > "Important Note: It is recommended to always defined each version of >> > the plugins used by the build to guarantee the build reproducibility." >> > >> > This seems sensible, but I've also been told that one should not >> > specify the versions of the core plugins [2] (such as clean, site, >> > verifier) as these may change between releases of Maven. >> > >> > So: does the statement in [1] apply to all plugins, or only non-core >> plugins? >> > >> > [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html >> > [2] http://maven.apache.org/plugins/index.html (first part of table) >> > >> >> > - >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> First, the taking in of scattered particulars under one Idea, >> so that everyone understands what is being talked about ... Second, >> the separation of the Idea into parts, by dividing it at the joints, >> as nature directs, not breaking any limb in half as a bad carver might. >> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) >> >> >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Specifying plugin versions
On 14/06/2010, Jason van Zyl wrote: > All plugins because unfortunately we haven't had the best track record with > respect to behavioral compatibility between releases. OK, thanks. What about the Maven Available Plugs list at [1] - can one assume that these plugin versions will work together OK? [1] http://maven.apache.org/plugins/index.html > On Jun 14, 2010, at 1:37 PM, sebb wrote: > > > The guide to configuring plugins [1] says that: > > > > "Important Note: It is recommended to always defined each version of > > the plugins used by the build to guarantee the build reproducibility." > > > > This seems sensible, but I've also been told that one should not > > specify the versions of the core plugins [2] (such as clean, site, > > verifier) as these may change between releases of Maven. > > > > So: does the statement in [1] apply to all plugins, or only non-core > plugins? > > > > [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html > > [2] http://maven.apache.org/plugins/index.html (first part of table) > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to resolve properties defined in another (external) artifact?
The way that we solved this is to build a set of pom files that identify
the 3rd party libraries that we use and version the POM with the version
of the product that we are building.
For example, we have a pom-spring-hibernate-mysql-tomcat project that
builds a jar with the spring, hibernate, mysql and tomcat jars that we
use in the specific project version.
In the in-house projects, we reference the ${project.version} of the
pom-spring-hibernate-mysql-tomcat project as a POM that is
PROVIDED(since we deploy the library to the shared tomcat /lib directory).
For example our web-service1's pom.xml is version 1.8.3 and depends on
pom-spring-hibernate-mysql-tomcat version 1.8.3.
We have similar poms for CXF (our web service), Jetspeed (portal),
shared (apache commons and other things), Jasper(reporting), etc.
This way the developers only have to know that they are building 1.8.3
and they use the libraries set up for 1.8.3.
Once the decision has been made about what versions of spring,
hibernate, mysql, etc is made and built into a set of POM, the version
is settled.
We treat our own library projects like 3rd party projects (just more
volatile in the 1.8.3-SNAPSHOT phase).
It means that there is an overhead step at the start of a new version.
You need to establish the versions of the dependencies and revise your
library poms if they change.
Most of the time you simply change the POM's version and leave the
library's dependencies alone and redeploy into the Nexus to make the new
1.8.4-SNAPSHOTs ready for the developers to use.
If during the building of 1.8.4-SNAPSHOT, you decide to upgrade the CXF,
you just change the pom-CXF project and redeploy the pom-CXF and its
jar-with-dependencies as new 1.8.4-SNAPSHOT. The rest of the
1.8.4-SNAPSHOT projects will automatically get the new CXF when they build.
This gives a very repeatable build and deploy since all of your 3rd
party libraries are included in the library jars. You don't have to go
looking through 60 jar files to be sure that you have deployed the right
commons-xxx.jar for the version that you have deployed.
Ron
On 14/06/2010 3:51 PM, Michael O'Cleirigh wrote:
Hello,
The case I am looking at is that I have two maven artifact hierarchies
that are independent.
Hierarchy A artifacts are core code that is shared between a bunch of
different projects.
Hierarchy B artifacts are for a single project and in some cases
depend on artifacts from A.
Now the A artifacts pull in the dependencies and define property
values to represent the version of the artifact.
The B projects don't care about the version but we need to make sure
that the versions used in B match the versions used in A.
In the A hierarchy I can define the ${something.version} and then in A
modules it will be able to resolve it.
My question is if there is a way to get the ${something.version}
property from the A artifact from within the B hierarchy.
Right now I have to create a matching ${something.version} in the B
pom and manually keep them matched on the same version. But I think
there must be a command or module that will allow this kind of inter
artifact property resolution.
A concrete example would be that A sets a ${spring.version} and in B
we want to include a different spring artifact but have the version be
aligned with what is being included with the A artifacts.
Thanks,
Mike
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to resolve properties defined in another (external) artifact?
Nope, not possible the way you describe it.
However, you can control the version of all dependencies (incl. transitive)
through the use of dependencyManagement in the B hierarchy.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
/Anders
On Mon, Jun 14, 2010 at 21:51, Michael O'Cleirigh <
michael.ocleir...@rivulet.ca> wrote:
> Hello,
>
> The case I am looking at is that I have two maven artifact hierarchies that
> are independent.
>
> Hierarchy A artifacts are core code that is shared between a bunch of
> different projects.
>
> Hierarchy B artifacts are for a single project and in some cases depend on
> artifacts from A.
>
> Now the A artifacts pull in the dependencies and define property values to
> represent the version of the artifact.
>
> The B projects don't care about the version but we need to make sure that
> the versions used in B match the versions used in A.
>
> In the A hierarchy I can define the ${something.version} and then in A
> modules it will be able to resolve it.
>
> My question is if there is a way to get the ${something.version} property
> from the A artifact from within the B hierarchy.
>
> Right now I have to create a matching ${something.version} in the B pom and
> manually keep them matched on the same version. But I think there must be a
> command or module that will allow this kind of inter artifact property
> resolution.
>
> A concrete example would be that A sets a ${spring.version} and in B we
> want to include a different spring artifact but have the version be aligned
> with what is being included with the A artifacts.
>
> Thanks,
>
> Mike
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
How to resolve properties defined in another (external) artifact?
Hello,
The case I am looking at is that I have two maven artifact hierarchies
that are independent.
Hierarchy A artifacts are core code that is shared between a bunch of
different projects.
Hierarchy B artifacts are for a single project and in some cases depend
on artifacts from A.
Now the A artifacts pull in the dependencies and define property values
to represent the version of the artifact.
The B projects don't care about the version but we need to make sure
that the versions used in B match the versions used in A.
In the A hierarchy I can define the ${something.version} and then in A
modules it will be able to resolve it.
My question is if there is a way to get the ${something.version}
property from the A artifact from within the B hierarchy.
Right now I have to create a matching ${something.version} in the B pom
and manually keep them matched on the same version. But I think there
must be a command or module that will allow this kind of inter artifact
property resolution.
A concrete example would be that A sets a ${spring.version} and in B we
want to include a different spring artifact but have the version be
aligned with what is being included with the A artifacts.
Thanks,
Mike
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Specifying plugin versions
All plugins because unfortunately we haven't had the best track record with respect to behavioral compatibility between releases. On Jun 14, 2010, at 1:37 PM, sebb wrote: > The guide to configuring plugins [1] says that: > > "Important Note: It is recommended to always defined each version of > the plugins used by the build to guarantee the build reproducibility." > > This seems sensible, but I've also been told that one should not > specify the versions of the core plugins [2] (such as clean, site, > verifier) as these may change between releases of Maven. > > So: does the statement in [1] apply to all plugins, or only non-core plugins? > > [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html > [2] http://maven.apache.org/plugins/index.html (first part of table) > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Specifying plugin versions
The guide to configuring plugins [1] says that: "Important Note: It is recommended to always defined each version of the plugins used by the build to guarantee the build reproducibility." This seems sensible, but I've also been told that one should not specify the versions of the core plugins [2] (such as clean, site, verifier) as these may change between releases of Maven. So: does the statement in [1] apply to all plugins, or only non-core plugins? [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html [2] http://maven.apache.org/plugins/index.html (first part of table) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multi module checkout
On 6/14/10 11:58 AM, House, Thomas wrote: > This seems like it would be a very common usecase so I'm surprised I > can't find more information about it on the web. Maybe I'm doing a bad > job searching. > An observation - I get the impression scm:checkout isn't used very much and/or this is a CVS-specific problem, so it may just be that no one has run into this before. Justin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to get the execution id from a plugin
I'm not sure it's possible to get the execution id, just as it's not
possible AFAIK to get the phase the execution is bound to
-Stephen
On 14 June 2010 17:05, wrote:
> Maybe this is the wrong list... Shall I move this question to the
> Developers list?
> Jeff
>
> > -Original Message-
> > From: giuseppe.gr...@b-source.ch [mailto:giuseppe.gr...@b-source.ch]
> > Sent: Monday, June 14, 2010 3:52 PM
> > To: users@maven.apache.org
> > Subject: How to get the execution id from a plugin
> >
> >
> > Hi all,
> >
> > I'm writing a Maven plugin:
> >
> > public class MyMojo extends AbstractMojo {
> >
> >...
> >
> >private void execute() throws MojoExecutionException
> >{
> >/* I need to get the execution id here */
> >}
> > }
> >
> > Given the following POM, I'm wondering how can I retrieve the
> > execution
> > id from it:
> >
> >
> >
> >
> > ch.bsource.plugins
> > my-plugin
> > RELEASE
> >
> > my-execution-id
> >
> > mygoal
> >
> >
> > ...
> >
> >
> >
> >
> >
> >
> >
> > Any help would be really appreciated.
> > Jeff
> >
> > Giuseppe Greco
> > Application Architect - System Integration & Applications
> >
> > B-Source SA, Via Simen 14, CH-6900 Lugano
> > Tel. +41 58 806 56 42 Fax +41 58 806 50 01
> > giuseppe.gr...@b-source.ch - www.b-source.ch
> >
> > IMPORTANT:
> > This e-mail transmission is intended for the named
> > addressee(s)only.
> > Its contents are private, confidential and protected
> > from disclosure and should not be read, copied or
> > disclosed by any other person.
> > If you are not the intended recipient, we kindly ask
> > you to notify the sender immediately by telephone
> > (+41 (0)58 806 50 00), to redirect the message to the
> > account "i...@b-source.ch" and to delete this e-mail.
> > E-mail transmissions may be intercepted, altered or
> > read by unauthorized persons and may contain viruses.
> > Therefore, it is recommended that you use regular mail
> > or courier services for any information intended to be
> > confidential. However, by sending us messages through
> > e-mail, you authorize and instruct us to correspond by
> > e-mail in the relevant matter.
> > Thank you.
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> IMPORTANT:
> This e-mail transmission is intended for the named
> addressee(s)only.
> Its contents are private, confidential and protected
> from disclosure and should not be read, copied or
> disclosed by any other person.
> If you are not the intended recipient, we kindly ask
> you to notify the sender immediately by telephone
> (+41 (0)58 806 50 00), to redirect the message to the
> account "i...@b-source.ch" and to delete this e-mail.
> E-mail transmissions may be intercepted, altered or
> read by unauthorized persons and may contain viruses.
> Therefore, it is recommended that you use regular mail
> or courier services for any information intended to be
> confidential. However, by sending us messages through
> e-mail, you authorize and instruct us to correspond by
> e-mail in the relevant matter.
> Thank you.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
RE: How to get the execution id from a plugin
Maybe this is the wrong list... Shall I move this question to the
Developers list?
Jeff
> -Original Message-
> From: giuseppe.gr...@b-source.ch [mailto:giuseppe.gr...@b-source.ch]
> Sent: Monday, June 14, 2010 3:52 PM
> To: users@maven.apache.org
> Subject: How to get the execution id from a plugin
>
>
> Hi all,
>
> I'm writing a Maven plugin:
>
> public class MyMojo extends AbstractMojo {
>
>...
>
>private void execute() throws MojoExecutionException
>{
>/* I need to get the execution id here */
>}
> }
>
> Given the following POM, I'm wondering how can I retrieve the
> execution
> id from it:
>
>
>
>
> ch.bsource.plugins
> my-plugin
> RELEASE
>
> my-execution-id
>
> mygoal
>
>
> ...
>
>
>
>
>
>
>
> Any help would be really appreciated.
> Jeff
>
> Giuseppe Greco
> Application Architect - System Integration & Applications
>
> B-Source SA, Via Simen 14, CH-6900 Lugano
> Tel. +41 58 806 56 42 Fax +41 58 806 50 01
> giuseppe.gr...@b-source.ch - www.b-source.ch
>
> IMPORTANT:
> This e-mail transmission is intended for the named
> addressee(s)only.
> Its contents are private, confidential and protected
> from disclosure and should not be read, copied or
> disclosed by any other person.
> If you are not the intended recipient, we kindly ask
> you to notify the sender immediately by telephone
> (+41 (0)58 806 50 00), to redirect the message to the
> account "i...@b-source.ch" and to delete this e-mail.
> E-mail transmissions may be intercepted, altered or
> read by unauthorized persons and may contain viruses.
> Therefore, it is recommended that you use regular mail
> or courier services for any information intended to be
> confidential. However, by sending us messages through
> e-mail, you authorize and instruct us to correspond by
> e-mail in the relevant matter.
> Thank you.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
IMPORTANT:
This e-mail transmission is intended for the named
addressee(s)only.
Its contents are private, confidential and protected
from disclosure and should not be read, copied or
disclosed by any other person.
If you are not the intended recipient, we kindly ask
you to notify the sender immediately by telephone
(+41 (0)58 806 50 00), to redirect the message to the
account "i...@b-source.ch" and to delete this e-mail.
E-mail transmissions may be intercepted, altered or
read by unauthorized persons and may contain viruses.
Therefore, it is recommended that you use regular mail
or courier services for any information intended to be
confidential. However, by sending us messages through
e-mail, you authorize and instruct us to correspond by
e-mail in the relevant matter.
Thank you.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
multi module checkout
Hi Everyone - I'm having a problem checking out the code from my multi
module project - it's very frustrating and I've been working on it for a
few days, so any help anyone can provide will be greatly appreciated.
Here's the background - I have a multi module project where the parent
project is just used for meta data- in other words there is no code
associated with the parent, it's just used to configure settings common
to all child projects. It builds nothing and its packaging is set to
POM.
I'm trying to check out my code from CVS
--
1. If I put the SCM element in the child pom's and remove it from the
parent then run mvn scm:checkout from the parent directory, I get the
error:
Cannot run checkout command :
Embedded error: Can't load the scm provider.
You need to define a connectionUrl parameter
I see no connectionUrl parameter within the SCM documentation.
--
2. If I put the SCM element in the parent pom and remove it from the
child pom's then run the mvn scm:checkout from the parent directory, I
get the error:
[ERROR] cvs server: cannot find module `reviewmanager' - ignored
cvs server: cannot find module `reviewmanager' - ignored
[ERROR] BUILD ERROR
Here it's trying to checkout the artifactId of reviewmanager, which is
the artifactId for the parent. However since the packaging is set to
POM, I'd think Maven would skip the parent knowing that it's a project
for meta data only
My scm configuration for the top 2 tries is structured like this:
scm:cvs:pserver:herestheuser:heresthepassw...@server.domain:
/ABC/DEF:${artifactId}
scm:cvs:pserver:herestheuser:heresthepassw...@serve
r.domain:/ABC/DEF:${artifactId}
HEAD
--
3. If I keep the configuration in the parent and remove the artifactId
from the connection / developerConnection and then run mvn scm:checkout
then I get the following error:
Cannot run checkout command
Embedded error: Exception while executing SCM command
Username isn't defined.
The scm config for this last attempt is like this:
scm:cvs:pserver:herestheuser:heresthepassw...@server.domain:
/ABC/DEF
scm:cvs:pserver:herestheuser:heresthepassw...@serve
r.domain:/ABC/DEF
HEAD
--
4. If I take the same configuration (as used in the top 2 examples With
the ${artifactId}) and put it in any of the child pom's and then run the
mvn scm:checkout from the Child Directory, then it works fine.
This seems like it would be a very common usecase so I'm surprised I
can't find more information about it on the web. Maybe I'm doing a bad
job searching.
Re: Strange surefire error
On Mon, Jun 14, 2010 at 5:04 PM, Wayne Fay wrote: > > As I wrote in the previous mail: "If I however run the command directly > it > > works." > > Yea, I saw that, but didn't actually believe that you were executing > the right command. We get a lot of hmmm confused people on this list > at times. > > Most likely there is something going on related to plexus.util.cli and > your new IBM JVM that no one has encountered previously (how new is > it?). If you really want it fixed in a reasonable timeline, you'll > probably need to take an active role in fixing it. As the trace shows, > Surefire is using plexus-utils 1.5.1. Pull the source and start poking > around near CommandLineUtils.java:146. > > Wayne > > Ok, thanks for your fast reply. I will see/hope I have time to dig into the source. I am not sure about the age of IBM's JVM but it should be at least 6 months old. -- Regards Joacim
Re: Strange surefire error
> As I wrote in the previous mail: "If I however run the command directly it > works." Yea, I saw that, but didn't actually believe that you were executing the right command. We get a lot of hmmm confused people on this list at times. Most likely there is something going on related to plexus.util.cli and your new IBM JVM that no one has encountered previously (how new is it?). If you really want it fixed in a reasonable timeline, you'll probably need to take an active role in fixing it. As the trace shows, Surefire is using plexus-utils 1.5.1. Pull the source and start poking around near CommandLineUtils.java:146. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Strange surefire error
> What happens when you run this from the same directory? Literally open > a MS-DOS prompt and copy/paste starting at cmd.exe through to the last > double quote. > > Forking command line: cmd.exe /X /C ""C:\Program > Files\IBM\WMBT700\jdk\jre\bin\java" -jar > C:\DOCUME~1\v008789\LOCALS~1\Temp\surefirebooter2356740905539978999.jar > C:\DOCUME~1\v008789\LOCALS~1\Temp\surefire25851443 > 23184620103tmp > C:\DOCUME~1\v008789\LOCALS~1\Temp\surefire4150186505744356578tmp" > > Hello, As I wrote in the previous mail: "If I however run the command directly it works." -- Regards Joacim
Re: New packaging type HOWTO?
This should provide you with the info you need: http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/ On Mon, 2010-06-14 at 09:06 -0400, Laird Nelson wrote: > Hello; I'd like to add a new packaging type for our builds. > > Strictly speaking, I could just pack up the file I need into a jar and > use that, and I will if I have to, but I'd like to see what's involved > in making a new packaging type. > > I hunted through the Maven Developer Centre links on the Maven > homepage to no avail; that documentation said to contact the mailing > lists if the topic was not listed. > > So: what's involved in making a new packaging type? Pointers to > documentation heartily welcomed. > > Thanks, > Laird > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Strange surefire error
> When running tests we get errors > "org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: > Error while executing external command, process killed." when Maven > runs the command below. What happens when you run this from the same directory? Literally open a MS-DOS prompt and copy/paste starting at cmd.exe through to the last double quote. Forking command line: cmd.exe /X /C ""C:\Program Files\IBM\WMBT700\jdk\jre\bin\java" -jar C:\DOCUME~1\v008789\LOCALS~1\Temp\surefirebooter2356740905539978999.jar C:\DOCUME~1\v008789\LOCALS~1\Temp\surefire25851443 23184620103tmp C:\DOCUME~1\v008789\LOCALS~1\Temp\surefire4150186505744356578tmp" Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New packaging type HOWTO?
On Mon, Jun 14, 2010 at 9:36 AM, kristian wrote: > maybe following blog post helps (just read the code if you can not > understand french): Thanks for the reference--and for the excuse to practice my 12 years of schoolroom-only French! Best, Laird - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to get the execution id from a plugin
Hi all,
I'm writing a Maven plugin:
public class MyMojo extends AbstractMojo {
...
private void execute() throws MojoExecutionException
{
/* I need to get the execution id here */
}
}
Given the following POM, I'm wondering how can I retrieve the execution
id from it:
ch.bsource.plugins
my-plugin
RELEASE
my-execution-id
mygoal
...
Any help would be really appreciated.
Jeff
Giuseppe Greco
Application Architect - System Integration & Applications
B-Source SA, Via Simen 14, CH-6900 Lugano
Tel. +41 58 806 56 42 Fax +41 58 806 50 01
giuseppe.gr...@b-source.ch - www.b-source.ch
IMPORTANT:
This e-mail transmission is intended for the named
addressee(s)only.
Its contents are private, confidential and protected
from disclosure and should not be read, copied or
disclosed by any other person.
If you are not the intended recipient, we kindly ask
you to notify the sender immediately by telephone
(+41 (0)58 806 50 00), to redirect the message to the
account "i...@b-source.ch" and to delete this e-mail.
E-mail transmissions may be intercepted, altered or
read by unauthorized persons and may contain viruses.
Therefore, it is recommended that you use regular mail
or courier services for any information intended to be
confidential. However, by sending us messages through
e-mail, you authorize and instruct us to correspond by
e-mail in the relevant matter.
Thank you.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: New packaging type HOWTO?
maybe following blog post helps (just read the code if you can not understand french): http://blog.tartachuc.org/2008/07/07/creer-un-packaging-maven2/ or have a look at the code and xml files (components.xml) of other maven plugins like the war-maven-plugin, etc regards Kristian On Mon, Jun 14, 2010 at 6:36 PM, Laird Nelson wrote: > Hello; I'd like to add a new packaging type for our builds. > > Strictly speaking, I could just pack up the file I need into a jar and > use that, and I will if I have to, but I'd like to see what's involved > in making a new packaging type. > > I hunted through the Maven Developer Centre links on the Maven > homepage to no avail; that documentation said to contact the mailing > lists if the topic was not listed. > > So: what's involved in making a new packaging type? Pointers to > documentation heartily welcomed. > > Thanks, > Laird > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Kristian Meier + Saumya Sharma + Sanuka Meier Vadakkethu House, Edayanmula West PO - 689532, Pathanamthitta District, Kerala, INDIA tel: +91 468 2319577 protect your privacy while searching the net: www.ixquick.com _=_ q(-_-)p '_) (_` /__/ \ _(<_ / )_ (__\_\_|_/__) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
New packaging type HOWTO?
Hello; I'd like to add a new packaging type for our builds. Strictly speaking, I could just pack up the file I need into a jar and use that, and I will if I have to, but I'd like to see what's involved in making a new packaging type. I hunted through the Maven Developer Centre links on the Maven homepage to no avail; that documentation said to contact the mailing lists if the topic was not listed. So: what's involved in making a new packaging type? Pointers to documentation heartily welcomed. Thanks, Laird - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
