Re: Merging with XWiki and WikiModel
Hi there, On Jan 31, 2009, at 12:04 AM, Vincent Siveton wrote: Hi Jason, 2009/1/29 Jason van Zyl ja...@maven.org: Howdy, I've been looking at reporting in Maven 3.x and I've been following the work that Vincent Massol has been doing over at XWiki where he has made some attempts at melding Doxia, the XWiki rendering engine, and WikiModel. You can see the proposal here: http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence I am looking to remove the Doxia dependency from Maven 3.x so that reporting is removed from core and just becomes another set of components. Having I definitely agree to decouple Maven from Doxia, or conversely :) We actually have a lot of problems due to this coupling, see MNG-3402. Doxia coupled to Maven is not very nice so in the next couple releases of the Maven 3.x alphas the hard dependency on Doxia will be removed. This will open the door for anyone who wants to add a different mechanism. Doxia reports will still work, I'm not planning on removing the functionality just unbinding it from the core. But that opens the door for something new! Some questions to clarify what you have in mind: - how do you plan to integrate reporting concretely to Maven 3? - what about the backward compatibility in the reporting plugins? What I personally think the best path would be is to help what Vincent has started. There are really only three people here who work on Doxia, the releases are very slow in coming and I think you would immediately double or Agree but we work when we have time :) @Dennis: what are your availabilities to release the version 1.0? After this release, 1.1 could be out, IMHO all stuffs are there. triple the size of the team merging with the XWiki folks and getting the WikiModel developer as well. This is what the XWiki folks do all the time and I think you would get some more velocity in the progress of the project as a whole. Vincent is using Plexus for his stuff so it's not that wildly different but I think you would get more visibility over there and a higher The xwiki proposal seems to move the Doxia code to the xwiki umbrella, so do you plan to do it? @Vincent, could you clarify why a fork is not possible for you? Let me explain the point of view of the xwiki community (I hope I'm summarizing it well here): * XWiki is not a wiki. It's a platform offering wiki components to develop any type of content-centric web application based on the wiki paradigm. * We've started reorganizing ourselves to implement this vision back in 2007. We've started by decoupling our monolithic code into modules and components (using Plexus). * We're not finding that there are some important pieces that we want to make top level projects, independent of the other xwiki modules/ components. For the moment we have identified 2 pieces: - the rendering engine - our brand new GWT-based WYSIWYG editor * We could propose these under new projects at the ASF for example. These are the reasons preventing us from doing so right now: - we'd like to promote the XWiki project name as the place where to get wiki components. If we start splitting the rendering engine or the wysiwyg editor we won't achieve this - having to implement and support several projects (the xwiki one + the engine one at ASF + the wysiwyg one wherever else (@code.google.org for ex)) is going to spread our committer base thin achieving the opposite as what we want to achieve which is making all people interested on working on wiki components together. - we have a very good infrastructure team and we completely host all our tools. We like it this way since it's real fast and it works real well and we can only complain to ourselves if something is not right and we can fix it right away. Note that the infra is paid by XWiki SAS (a company offering services on top of the xwiki oss project - See http://tinyurl.com/7c488p for more details) - basically we can work faster if the code is on the xwiki svn It's possible that one day we'll propose the whole project to the ASF but I don't think we're ready for that yet. For the moment we like it the way we are able to progress fast and we don't feel the need. Note that xwiki projects are currently under the LGPL but we can discuss making the new rendering engine (which would be the merge between doxia, xwiki and wikimodel ) under the ASL if you feel this is better. Now why are we interested in merging them all? Actually that wasn't our idea. It was Jason's. We were fine developing and progressing fast on our own xwiki rendering engine. But at the same time it's true that I've realized it was a pity that XWiki/WikiModel and Doxia are re- developing the same things instead of collaborating and working on building something together. So I see 2 win-win advantages for us all: - for Doxia this can be a way to make it live on and be active again, with
Re: releasing 2.0.10?
So there will be 2.0.x 2.1.x and 3.0 ? 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: There's a new 2.1 cut from the 2.0.x branch that provides a space to put features. We did this back in Aug/Sept but there's been little forward progress, so a release should get it started. When we planned it out, there was a lot of interest in new features but I don't think much has been done in the last 5 months, so I don't see the point in waiting for future features, lets get 2.1 out so people will start to use it. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Friday, January 30, 2009 8:39 AM To: Maven Developers List Subject: Re: releasing 2.0.10? I was thinking : 2.0.x is the current Maven 2 2.1 deprecated and will became 3.0 But what is 2.2 ? or 2.1 ? I'm puzzled 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: My original intent was to shift the focus to 2.1 and bring that quickly to GA. The development on it has stalled so it's irrelevant if it's feature complete or not, it's stable and usable as it is. Future features can go into 2.1.x or 2.2. -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Thursday, January 29, 2009 10:58 PM To: Maven Developers List Subject: Re: releasing 2.0.10? I don't think it's wise to EOL a product without a GA replacement. It's true that because 2.1 is in milestone releases it is not usable by many people in an approved managerial environment, but, to the same token, it's not feature complete either. Personally speaking, I definitely am eagerly awaiting the issues scheduled in 2.0.11. Please continue releasing 2.0.x until 2.1/3.0 has a GA. Paul On 28/01/2009, at 9:03 AM, Brian E. Fox wrote: Normally I would agree on the late change, but it's entirely optional usage so it wouldn't affect existing builds and I'd like to start thinking about 2.0.10 being the EOL for 2.0.x. Given there's already been a good number of fixes for 2.0.11 that haven't been rolled up to 2.0.10-RC, maybe pushing 2.0.10 out as is and having .11 as the EOL is a better way to go - wdyt? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven 3.0-alpha-2 tagged
binaries available ? 2009/1/31 Jason van Zyl jvan...@sonatype.com: Shane/Benjamin, Go ahead and roll your changes into trunk. The alpha-2 is tagged. No messages about the vote because of a problem with the upgrade on people.apache.org which is preventing me from deploying. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: pde build with maven
Christopher, Although I can't help you with pde-maven-plugin (I remember some discussion here about retiring it, see [1]), I am working on another maven-based tool called Tycho that should be able to build Eclipse RCP applications. You can read more about Tycho goals and scope in [2] and RCP specific mini-howto is here [3]. You can also find couple of sample RCP projects we use in Tycho integration tests in [4]. [1] http://www.nabble.com/Retiring-pde-maven-plugin%2C-any-active-alternative-out-there--td19534297.html#a19534297 [2] http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview [3] http://docs.codehaus.org/display/M2ECLIPSE/Tycho+Product+Export [4] http://svn.sonatype.org/m2eclipse/tycho/trunk/tycho-its/projects/tycho109/ Christopher Klewes wrote: Hi, i want to setup my rcp project with a maven build. so first i want to build succesfully the example from the pde-maven-plugin site. i started by downloading the following eclipse sdk and delta pack: - eclipse-3.4.1-delta-pack.zip - eclipse-RCP-SDK-3.4.1-win32.zip i read through the examples from pde-maven-plugin mojo and found a tutorial that builds a product. this tutorial can be found here: http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-plugin/ i downloaded this one: pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an SSCCE (http://pscode.org/sscce.html)) after i imported the project to my eclipse ide i have done som changes to build.properties and pom.xml to ensure the paths are well formed. (the name of the plugin is: test.pde_maven_plugin.simple_application) now i tried the pde build to be sure its running without maven: 1) launch the application (SUCCESSFUL) 2) launch the product (SUCCESSFUL) 3) export as product and launch (SUCCESSFUL) everything works fine! now i tried to do the maven install, but this failed: BUILD FAILED D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:25: The following error occurred while executing this line: D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:53: Unable to find plug-in: test.pde_maven_plugin.simple_application. Please check the error log for more details. as you can see, the pde build (i think) can't found the application i want to export, it seems that maven doesn't calls the pde build for the application first, it assumes that the plugin has already be there? if i change the maven packaging to jar, do the install, copy this jar to my target.env into plugins change packaging back to zip, do the install again. everything runs fine, but this isn't a great solutions or? in my pov i think this should be done by pde build? please correct me if i am wrong if you need more informartions just let me know -- or if you got time have a look inside the maven-pde-plugin tutorial. thank you chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: releasing 2.0.10?
Who knows. Maybe, maybe not depending on the timing and uptake of 3.x -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, February 02, 2009 10:11 AM To: Maven Developers List Subject: Re: releasing 2.0.10? I agree. But no 2.2.x is planned ? 2009/2/2 Brian E. Fox bri...@reply.infinity.nu: Yes, but hopefully 2.0.x is end of life with either 2.0.10 or 2.0.11 and 2.1.x becomes the active line. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, February 02, 2009 3:36 AM To: Maven Developers List Subject: Re: releasing 2.0.10? So there will be 2.0.x 2.1.x and 3.0 ? 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: There's a new 2.1 cut from the 2.0.x branch that provides a space to put features. We did this back in Aug/Sept but there's been little forward progress, so a release should get it started. When we planned it out, there was a lot of interest in new features but I don't think much has been done in the last 5 months, so I don't see the point in waiting for future features, lets get 2.1 out so people will start to use it. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Friday, January 30, 2009 8:39 AM To: Maven Developers List Subject: Re: releasing 2.0.10? I was thinking : 2.0.x is the current Maven 2 2.1 deprecated and will became 3.0 But what is 2.2 ? or 2.1 ? I'm puzzled 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: My original intent was to shift the focus to 2.1 and bring that quickly to GA. The development on it has stalled so it's irrelevant if it's feature complete or not, it's stable and usable as it is. Future features can go into 2.1.x or 2.2. -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Thursday, January 29, 2009 10:58 PM To: Maven Developers List Subject: Re: releasing 2.0.10? I don't think it's wise to EOL a product without a GA replacement. It's true that because 2.1 is in milestone releases it is not usable by many people in an approved managerial environment, but, to the same token, it's not feature complete either. Personally speaking, I definitely am eagerly awaiting the issues scheduled in 2.0.11. Please continue releasing 2.0.x until 2.1/3.0 has a GA. Paul On 28/01/2009, at 9:03 AM, Brian E. Fox wrote: Normally I would agree on the late change, but it's entirely optional usage so it wouldn't affect existing builds and I'd like to start thinking about 2.0.10 being the EOL for 2.0.x. Given there's already been a good number of fixes for 2.0.11 that haven't been rolled up to 2.0.10-RC, maybe pushing 2.0.10 out as is and having .11 as the EOL is a better way to go - wdyt? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: releasing 2.0.10?
That's the plan. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, February 02, 2009 11:09 AM To: Maven Developers List Subject: Re: releasing 2.0.10? 2009/2/2 Brian E. Fox bri...@reply.infinity.nu: Who knows. Maybe, maybe not depending on the timing and uptake of 3.x Well if 2.1.0 is quickly stable and you need to add more stuff, 2.2.0 could be a good idea. But 2.x.y should stop at some time when 3.0 will be available or users will be stuck by so many differents versions (and a pain for developpers to check / fix so many branches). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
NPE in MapperUtil
Hi,
I'm trying to use file mappers inside a maven plugin with the
file-management shared project.
I've added a fileset definition in the plugin's configuration as follow :
plugin
groupIdinfo.flex-mojos/groupId
artifactIdflex-compiler-mojo/artifactId
extensionstrue/extensions
version2.0M11-SNAPSHOT/version
configuration
includeSources
param${basedir}/src/param
/includeSources
fileset
directory${basedir}/src/directory
includes
include**/*.mxml/include
/includes
mapper
typeflatten/type
/mapper
/fileset
/configuration
/plugin
Unfortunately, I get a NPE while trying to retrieve my mapper :
java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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:585)
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)
I've checked current trunk on shared/file-management, it seems that the
initializeBuiltIns call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix this.
Am I missing something ? Is there a better way to handle mappers ?
Jerome.
Index: D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java
===
--- D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java (revision 728728)
+++ D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java (working copy)
@@ -67,6 +67,7 @@
try
{
props.load( stream );
+implementations = props;
}
catch ( IOException e )
{
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Building from source
Did that, yeah. Thanks for the hint.
Georgy
On Mon, Feb 2, 2009 at 4:57 PM, Brian E. Fox bri...@reply.infinity.nu wrote:
Can you turn of the checksum checking?
-Original Message-
From: Georgy Bolyuba [mailto:boly...@gmail.com]
Sent: Monday, February 02, 2009 10:39 AM
To: dev@maven.apache.org
Subject: Building from source
Hi,
I am following this:
http://maven.apache.org/guides/development/guide-building-m2.html.
Checkout from trunk:
svn checkout http://svn.apache.org/repos/asf/maven/components/trunk .
Trying to build:
ant
Result:
BUILD FAILED
D:\tests\maven\build.xml:82: Unable to resolve artifact: Missing:
--
1) org.codehaus.plexus:plexus-lang:jar:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven:maven:pom:3.0-SNAPSHOT
2) org.apache.maven.mercury:mercury-artifact:jar:1.0.0-alpha-2
3) org.codehaus.plexus:plexus-lang:jar:1.1
--
1 required artifact is missing.
for artifact:
org.apache.maven:maven:pom:3.0-SNAPSHOT
We use Artifactory in our company. This is from the log files:
2009-02-02 10:23:12,286 [ERROR] (o.a.c.c.C.[.[.[.[default]:260) -
Servlet.service() for servlet default threw exception
java.lang.RuntimeException: Failed to save resource
'repo1:org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:588)
[artifactory-core-1.3.0-rc-1.jar:na]
...skipped...
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
[tomcat-util.jar:5.1]
at java.lang.Thread.run(Thread.java:595) [na:1.5.0_12]
Caused by: org.artifactory.api.repo.exception.RepositoryRuntimeException:
Failed to create file node resource at
'/repositories/repo1-cache/org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:178)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:567)
[artifactory-core-1.3.0-rc-1.jar:na]
... 56 common frames omitted
Caused by: org.artifactory.io.checksum.policy.ChecksumPolicyException:
Checksum policy
'org.artifactory.io.checksum.policy.checksumpolicygenerateifabs...@5fb185'
rejected the artifact 'plexus-lang-1.1.jar'. Checksums info:
[ChecksumInfo{type=SHA-1,
original='da39a3ee5e6b4b0d3255bfef95601890afd80709',
actual='0fe38d248d8c98518ddf8173d9152c10d0a8be0c'},
ChecksumInfo{type=MD5, original='d41d8cd98f00b204e9800998ecf8427e',
actual='f1df611b48adbe87129bb397a58f5979'}]
at org.artifactory.jcr.fs.JcrFile.fillJcrData(JcrFile.java:721)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.setResourceNode(JcrFile.java:679)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:175)
[artifactory-core-1.3.0-rc-1.jar:na]
... 57 common frames omitted
I looked at both repo1 and codehaus repo
(http://repository.codehaus.org/org/codehaus/plexus/plexus-lang/1.1/).
Same thing - MD5 and SHA1 do not match calculated from jar.
Any help on what to do in this situation? (Except installing it
manually to our local repo)
Have a great rest of the day,
Georgy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Beginner with Maven
please check your firewall setting On Mon, Feb 2, 2009 at 9:50 PM, amrorabi amror...@gmail.com wrote: Please, I am a beginner with the Maven apache-maven-2.0.9, and I installed it and set the environment variables, then I tried to run just the command mvn clean but on plugins jars are downloaded as I read in the tutorials The picture show the error http://www.nabble.com/file/p21793246/untitled.jpeg Please HELP me, Thanks in advance. -- View this message in context: http://www.nabble.com/Beginner-with-Maven-tp21793246p21793246.html Sent from the Maven - Issues mailing list archive at Nabble.com.
Re: [vote] release mercury-1.0.0-alpha-4
+3 binding votes, I proceed moving mercury-1.0.0-alpha-4 to production Thanks, Oleg Oleg Gusakov wrote: This is iterative improvements release of Mercury. The major change: - timestamped artifacts can now have dependencies - a bug was fixed 1 issue fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14889 Staged release in repository at http://people.apache.org/~ogusakov/repos/staging/ Site at http://people.apache.org/~ogusakov/sites/mercury Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Beginner with Maven
I guess runing mvn clean -e will give mor info. For starters, I think it is possible that he does not have a pom.xml in C:\Documents and Settings\Administrator folder. I assume he needs to change the current folder (cd path_to_project_here) Georgy On Mon, Feb 2, 2009 at 6:32 PM, Roshan Gunoo roshan.gu...@gmail.com wrote: please check your firewall setting On Mon, Feb 2, 2009 at 9:50 PM, amrorabi amror...@gmail.com wrote: Please, I am a beginner with the Maven apache-maven-2.0.9, and I installed it and set the environment variables, then I tried to run just the command mvn clean but on plugins jars are downloaded as I read in the tutorials The picture show the error http://www.nabble.com/file/p21793246/untitled.jpeg Please HELP me, Thanks in advance. -- View this message in context: http://www.nabble.com/Beginner-with-Maven-tp21793246p21793246.html Sent from the Maven - Issues mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: releasing 2.0.10?
2009/2/2 Brian E. Fox bri...@reply.infinity.nu: Who knows. Maybe, maybe not depending on the timing and uptake of 3.x Well if 2.1.0 is quickly stable and you need to add more stuff, 2.2.0 could be a good idea. But 2.x.y should stop at some time when 3.0 will be available or users will be stuck by so many differents versions (and a pain for developpers to check / fix so many branches). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: password encryption in 2.1.x trunk
Any reason not to use a new field in settings.xml? I think 2.1.x can be capable of updating the model version. Why introduce a bunch of new work for this? Also, we wanted to make it work in 2.0.x if possible. Since it's completely optional to use, there should be little downside risk to porting it back. What's left before this is releasable as part of 2.1.x? Just some manual testing and docs updates for the site when it's ready. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Skinny War
I'm surprised no one has commented. Since it's an important issue in my work or anyone that packages ears I would think. I'll comment below. 1. add a new scope called application that is exposed as application dependencies Having a scope for these seems to be a better approach in my mind. The term application jars ear libs is what I use in day-to-day conversation. I believe the specification uses the term bundled optional classes and very likely why the dependency attribute is called optional. I have no affinity to a particular name. 2. modify the maven-ear-plugin to utilize application dependencies (as found applicable by maven) and package them into the bundled lib directory. So this realizes the benefit of promoting the attribute to a proper scope? Where are these dependencies declared? I think this question is the major sticking point. I've found that I need to build the J2EE parent, or ear project or war projects separately at times. I see two choices wrt where the dependencies are declared (maybe other ways exist) - 1) declare these dependencies in the parent project, 2) create a pom dependency aggregation project / a pattern described and debated on the mailing lists - I think some folks object to it but as the saying goes a layer of indirection solves every IT problem. The solution in my opinion should allow both ways and in the end the dilemma is really about the build order. I think your solution is reasonable so long as the reactor (if it's even still called that) can determine the appropriate build order. Are there any recommendations, thoughts or critics on the problem and solution as I have proposed? I'm not a maven committer so those guys would have much better insight about the merit of the proposal and what it would mean exactly to the war and ear plugins and the latest changes in dependency resolution and build ordering. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release mercury-1.0.0-alpha-4
Hi, I am new here, so, might be missing something. I am trying to build maven from trunk and: Missing: -- 1) org.apache.maven.mercury:mercury-event:jar:1.0.0-alpha-4-SNAPSHOT So, I am kinda confused. Is it or is it not available (mercury-1.0.0-alpha-4)? Georgy On Mon, Feb 2, 2009 at 6:44 PM, Oleg Gusakov oleg.subscripti...@gmail.com wrote: +3 binding votes, I proceed moving mercury-1.0.0-alpha-4 to production Thanks, Oleg Oleg Gusakov wrote: This is iterative improvements release of Mercury. The major change: - timestamped artifacts can now have dependencies - a bug was fixed 1 issue fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14889 Staged release in repository at http://people.apache.org/~ogusakov/repos/staging/ Site at http://people.apache.org/~ogusakov/sites/mercury Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: releasing 2.0.10?
I agree. But no 2.2.x is planned ? 2009/2/2 Brian E. Fox bri...@reply.infinity.nu: Yes, but hopefully 2.0.x is end of life with either 2.0.10 or 2.0.11 and 2.1.x becomes the active line. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, February 02, 2009 3:36 AM To: Maven Developers List Subject: Re: releasing 2.0.10? So there will be 2.0.x 2.1.x and 3.0 ? 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: There's a new 2.1 cut from the 2.0.x branch that provides a space to put features. We did this back in Aug/Sept but there's been little forward progress, so a release should get it started. When we planned it out, there was a lot of interest in new features but I don't think much has been done in the last 5 months, so I don't see the point in waiting for future features, lets get 2.1 out so people will start to use it. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Friday, January 30, 2009 8:39 AM To: Maven Developers List Subject: Re: releasing 2.0.10? I was thinking : 2.0.x is the current Maven 2 2.1 deprecated and will became 3.0 But what is 2.2 ? or 2.1 ? I'm puzzled 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: My original intent was to shift the focus to 2.1 and bring that quickly to GA. The development on it has stalled so it's irrelevant if it's feature complete or not, it's stable and usable as it is. Future features can go into 2.1.x or 2.2. -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Thursday, January 29, 2009 10:58 PM To: Maven Developers List Subject: Re: releasing 2.0.10? I don't think it's wise to EOL a product without a GA replacement. It's true that because 2.1 is in milestone releases it is not usable by many people in an approved managerial environment, but, to the same token, it's not feature complete either. Personally speaking, I definitely am eagerly awaiting the issues scheduled in 2.0.11. Please continue releasing 2.0.x until 2.1/3.0 has a GA. Paul On 28/01/2009, at 9:03 AM, Brian E. Fox wrote: Normally I would agree on the late change, but it's entirely optional usage so it wouldn't affect existing builds and I'd like to start thinking about 2.0.10 being the EOL for 2.0.x. Given there's already been a good number of fixes for 2.0.11 that haven't been rolled up to 2.0.10-RC, maybe pushing 2.0.10 out as is and having .11 as the EOL is a better way to go - wdyt? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Building from source
Can you turn of the checksum checking?
-Original Message-
From: Georgy Bolyuba [mailto:boly...@gmail.com]
Sent: Monday, February 02, 2009 10:39 AM
To: dev@maven.apache.org
Subject: Building from source
Hi,
I am following this:
http://maven.apache.org/guides/development/guide-building-m2.html.
Checkout from trunk:
svn checkout http://svn.apache.org/repos/asf/maven/components/trunk .
Trying to build:
ant
Result:
BUILD FAILED
D:\tests\maven\build.xml:82: Unable to resolve artifact: Missing:
--
1) org.codehaus.plexus:plexus-lang:jar:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven:maven:pom:3.0-SNAPSHOT
2) org.apache.maven.mercury:mercury-artifact:jar:1.0.0-alpha-2
3) org.codehaus.plexus:plexus-lang:jar:1.1
--
1 required artifact is missing.
for artifact:
org.apache.maven:maven:pom:3.0-SNAPSHOT
We use Artifactory in our company. This is from the log files:
2009-02-02 10:23:12,286 [ERROR] (o.a.c.c.C.[.[.[.[default]:260) -
Servlet.service() for servlet default threw exception
java.lang.RuntimeException: Failed to save resource
'repo1:org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:588)
[artifactory-core-1.3.0-rc-1.jar:na]
...skipped...
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
[tomcat-util.jar:5.1]
at java.lang.Thread.run(Thread.java:595) [na:1.5.0_12]
Caused by: org.artifactory.api.repo.exception.RepositoryRuntimeException:
Failed to create file node resource at
'/repositories/repo1-cache/org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:178)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:567)
[artifactory-core-1.3.0-rc-1.jar:na]
... 56 common frames omitted
Caused by: org.artifactory.io.checksum.policy.ChecksumPolicyException:
Checksum policy
'org.artifactory.io.checksum.policy.checksumpolicygenerateifabs...@5fb185'
rejected the artifact 'plexus-lang-1.1.jar'. Checksums info:
[ChecksumInfo{type=SHA-1,
original='da39a3ee5e6b4b0d3255bfef95601890afd80709',
actual='0fe38d248d8c98518ddf8173d9152c10d0a8be0c'},
ChecksumInfo{type=MD5, original='d41d8cd98f00b204e9800998ecf8427e',
actual='f1df611b48adbe87129bb397a58f5979'}]
at org.artifactory.jcr.fs.JcrFile.fillJcrData(JcrFile.java:721)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.setResourceNode(JcrFile.java:679)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:175)
[artifactory-core-1.3.0-rc-1.jar:na]
... 57 common frames omitted
I looked at both repo1 and codehaus repo
(http://repository.codehaus.org/org/codehaus/plexus/plexus-lang/1.1/).
Same thing - MD5 and SHA1 do not match calculated from jar.
Any help on what to do in this situation? (Except installing it
manually to our local repo)
Have a great rest of the day,
Georgy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven 3.0-alpha-2 tagged
I ran into a snag deploying the binaries due to a change in one of the Apache machines. Everything is fine now but that's why I didn't deploy it. On 2-Feb-09, at 12:36 AM, Henri Gomez wrote: binaries available ? 2009/1/31 Jason van Zyl jvan...@sonatype.com: Shane/Benjamin, Go ahead and roll your changes into trunk. The alpha-2 is tagged. No messages about the vote because of a problem with the upgrade on people.apache.org which is preventing me from deploying. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Skinny War
Hi, 1. You are correct - it is up to the ear plugin and the war plugin to package these dependencies correctly. 2. The purpose of having an application dependency would be to remove the need to specify every dependency within your ear pom and also remove the need to have an aggregation pom*. Maven finds application dependencies applicable for compile and test classpaths ensuring that test execution and compilation occurs correctly. The ear plugin treats ejb modules correctly by automatically putting the ejb dependencies in the ear lib folder. The war pluging would typically put dependencies into its WEB-INF/lib but by declaring the scope of the war dependencies as application the ear-plugin should pick up these dependencies as transitive and package them in the ear unless the war is marked as standalone application. A standalone war would have application dependencies packaged inside its WEB-INF/lib because it is the application. For a skinny war it is part of a larger application and therefore the application dependencies are transitive. application dependencies can be declared in anywhere normal compile dependencies may be declared. It may not make sense to define an application dependency within a normal jar project but this still has reasonable use cases with results that make sense. * The aggregation pom, as i understand it, solves the problem of ensuring that a set of libraries are all used together and is something that I have wanted for some time. Thank you for your feedback. From: Timothy Reilly trei...@prolifics.com To: Maven Developers List dev@maven.apache.org Sent: Monday, 2 February, 2009 21:13:41 Subject: RE: Skinny War I'm surprised no one has commented. Since it's an important issue in my work or anyone that packages ears I would think. I'll comment below. 1. add a new scope called application that is exposed as application dependencies Having a scope for these seems to be a better approach in my mind. The term application jars ear libs is what I use in day-to-day conversation. I believe the specification uses the term bundled optional classes and very likely why the dependency attribute is called optional. I have no affinity to a particular name. 2. modify the maven-ear-plugin to utilize application dependencies (as found applicable by maven) and package them into the bundled lib directory. So this realizes the benefit of promoting the attribute to a proper scope? Where are these dependencies declared? I think this question is the major sticking point. I've found that I need to build the J2EE parent, or ear project or war projects separately at times. I see two choices wrt where the dependencies are declared (maybe other ways exist) - 1) declare these dependencies in the parent project, 2) create a pom dependency aggregation project / a pattern described and debated on the mailing lists - I think some folks object to it but as the saying goes a layer of indirection solves every IT problem. The solution in my opinion should allow both ways and in the end the dilemma is really about the build order. I think your solution is reasonable so long as the reactor (if it's even still called that) can determine the appropriate build order. Are there any recommendations, thoughts or critics on the problem and solution as I have proposed? I'm not a maven committer so those guys would have much better insight about the merit of the proposal and what it would mean exactly to the war and ear plugins and the latest changes in dependency resolution and build ordering. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Building from source
Hi,
I am following this:
http://maven.apache.org/guides/development/guide-building-m2.html.
Checkout from trunk:
svn checkout http://svn.apache.org/repos/asf/maven/components/trunk .
Trying to build:
ant
Result:
BUILD FAILED
D:\tests\maven\build.xml:82: Unable to resolve artifact: Missing:
--
1) org.codehaus.plexus:plexus-lang:jar:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.codehaus.plexus
-DartifactId=plexus-lang -Dversion=1.1 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven:maven:pom:3.0-SNAPSHOT
2) org.apache.maven.mercury:mercury-artifact:jar:1.0.0-alpha-2
3) org.codehaus.plexus:plexus-lang:jar:1.1
--
1 required artifact is missing.
for artifact:
org.apache.maven:maven:pom:3.0-SNAPSHOT
We use Artifactory in our company. This is from the log files:
2009-02-02 10:23:12,286 [ERROR] (o.a.c.c.C.[.[.[.[default]:260) -
Servlet.service() for servlet default threw exception
java.lang.RuntimeException: Failed to save resource
'repo1:org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:588)
[artifactory-core-1.3.0-rc-1.jar:na]
...skipped...
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
[tomcat-util.jar:5.1]
at java.lang.Thread.run(Thread.java:595) [na:1.5.0_12]
Caused by: org.artifactory.api.repo.exception.RepositoryRuntimeException:
Failed to create file node resource at
'/repositories/repo1-cache/org/codehaus/plexus/plexus-lang/1.1/plexus-lang-1.1.jar'.
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:178)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.repo.jcr.JcrRepoBase.saveResource(JcrRepoBase.java:567)
[artifactory-core-1.3.0-rc-1.jar:na]
... 56 common frames omitted
Caused by: org.artifactory.io.checksum.policy.ChecksumPolicyException:
Checksum policy
'org.artifactory.io.checksum.policy.checksumpolicygenerateifabs...@5fb185'
rejected the artifact 'plexus-lang-1.1.jar'. Checksums info:
[ChecksumInfo{type=SHA-1,
original='da39a3ee5e6b4b0d3255bfef95601890afd80709',
actual='0fe38d248d8c98518ddf8173d9152c10d0a8be0c'},
ChecksumInfo{type=MD5, original='d41d8cd98f00b204e9800998ecf8427e',
actual='f1df611b48adbe87129bb397a58f5979'}]
at org.artifactory.jcr.fs.JcrFile.fillJcrData(JcrFile.java:721)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.setResourceNode(JcrFile.java:679)
[artifactory-core-1.3.0-rc-1.jar:na]
at org.artifactory.jcr.fs.JcrFile.fillData(JcrFile.java:175)
[artifactory-core-1.3.0-rc-1.jar:na]
... 57 common frames omitted
I looked at both repo1 and codehaus repo
(http://repository.codehaus.org/org/codehaus/plexus/plexus-lang/1.1/).
Same thing - MD5 and SHA1 do not match calculated from jar.
Any help on what to do in this situation? (Except installing it
manually to our local repo)
Have a great rest of the day,
Georgy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Plugin - Artifact.getFile() not set.
Hello,
I try to get the artifact name in a home-made plugin. I use the code below
based on the maven-install-plugin.
I am expecting the plugin name to be set after the package phase but it is not
the case.
I probably did not get a concept, could you let me know if something obvious is
missing ?
Regards,
import org.apache.maven.artifact.Artifact;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
/**
* Goal to get the artifact filename
*
* @goal filename
* @execute phase=package
*/
public class ArtifactNameTest extends AbstractMojo
{
/**
* @parameter expression=${project.artifact}
* @required
* @readonly
*/
private Artifact artifact;
public void execute() throws MojoExecutionException {
File file = artifact.getFile();
if (file == null) {
getLog().error(artifact.getFile() == null);
} else {
getLog().info(artifact.getFile() == +
file.getAbsolutePath());
}
}
}
Maven version: 2.1.0-M1
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non- classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app-domain:jar:clover:1.0- SNAPSHOT and com.app:app-domain:jar:1.0-SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Precedence of direct dependencies with equal conflict id
On Mon, 26 Jan 2009, Brett Porter wrote: On 26/01/2009, at 12:17 PM, Brian E. Fox wrote: It should be a validation error if we find duplicated entries. +1 when building a project. Probably not when encountered in the repository (but changing the first would reduce the impact over time). will relocated artifacts be taken into consideration as well - or is that too fancy? -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
pde build with maven
Hi, i want to setup my rcp project with a maven build. so first i want to build succesfully the example from the pde-maven-plugin site. i started by downloading the following eclipse sdk and delta pack: - eclipse-3.4.1-delta-pack.zip - eclipse-RCP-SDK-3.4.1-win32.zip i read through the examples from pde-maven-plugin mojo and found a tutorial that builds a product. this tutorial can be found here: http://snapshots.repository.codehaus.org/org/codehaus/mojo/pde-maven-plugin/ i downloaded this one: pde-maven-plugin-1.0-20080304.235354-2-tutorials.zip (if you want an SSCCE (http://pscode.org/sscce.html)) after i imported the project to my eclipse ide i have done som changes to build.properties and pom.xml to ensure the paths are well formed. (the name of the plugin is: test.pde_maven_plugin.simple_application) now i tried the pde build to be sure its running without maven: 1) launch the application (SUCCESSFUL) 2) launch the product (SUCCESSFUL) 3) export as product and launch (SUCCESSFUL) everything works fine! now i tried to do the maven install, but this failed: BUILD FAILED D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:25: The following error occurred while executing this line: D:\Programme\EclipseGanymede\plugins\org.eclipse.pde.build_3.4.0.v20080604\scripts\productBuild\productBuild.xml:53: Unable to find plug-in: test.pde_maven_plugin.simple_application. Please check the error log for more details. as you can see, the pde build (i think) can't found the application i want to export, it seems that maven doesn't calls the pde build for the application first, it assumes that the plugin has already be there? if i change the maven packaging to jar, do the install, copy this jar to my target.env into plugins change packaging back to zip, do the install again. everything runs fine, but this isn't a great solutions or? in my pov i think this should be done by pde build? please correct me if i am wrong if you need more informartions just let me know -- or if you got time have a look inside the maven-pde-plugin tutorial. thank you chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: releasing 2.0.10?
Yes, but hopefully 2.0.x is end of life with either 2.0.10 or 2.0.11 and 2.1.x becomes the active line. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Monday, February 02, 2009 3:36 AM To: Maven Developers List Subject: Re: releasing 2.0.10? So there will be 2.0.x 2.1.x and 3.0 ? 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: There's a new 2.1 cut from the 2.0.x branch that provides a space to put features. We did this back in Aug/Sept but there's been little forward progress, so a release should get it started. When we planned it out, there was a lot of interest in new features but I don't think much has been done in the last 5 months, so I don't see the point in waiting for future features, lets get 2.1 out so people will start to use it. -Original Message- From: Henri Gomez [mailto:henri.go...@gmail.com] Sent: Friday, January 30, 2009 8:39 AM To: Maven Developers List Subject: Re: releasing 2.0.10? I was thinking : 2.0.x is the current Maven 2 2.1 deprecated and will became 3.0 But what is 2.2 ? or 2.1 ? I'm puzzled 2009/1/30 Brian E. Fox bri...@reply.infinity.nu: My original intent was to shift the focus to 2.1 and bring that quickly to GA. The development on it has stalled so it's irrelevant if it's feature complete or not, it's stable and usable as it is. Future features can go into 2.1.x or 2.2. -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Thursday, January 29, 2009 10:58 PM To: Maven Developers List Subject: Re: releasing 2.0.10? I don't think it's wise to EOL a product without a GA replacement. It's true that because 2.1 is in milestone releases it is not usable by many people in an approved managerial environment, but, to the same token, it's not feature complete either. Personally speaking, I definitely am eagerly awaiting the issues scheduled in 2.0.11. Please continue releasing 2.0.x until 2.1/3.0 has a GA. Paul On 28/01/2009, at 9:03 AM, Brian E. Fox wrote: Normally I would agree on the late change, but it's entirely optional usage so it wouldn't affect existing builds and I'd like to start thinking about 2.0.10 being the EOL for 2.0.x. Given there's already been a good number of fixes for 2.0.11 that haven't been rolled up to 2.0.10-RC, maybe pushing 2.0.10 out as is and having .11 as the EOL is a better way to go - wdyt? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: password encryption in 2.1.x trunk
On 28/01/2009, at 5:48 AM, Oleg Gusakov wrote: After a long and interesting discussion last August (http://docs.codehaus.org/display/MAVEN/Secured+Passwords ) and several meetings with users, I felt it's overdue to do the actual implementation. I massaged my old, vintage 2007 code and put it into 2.1.x trunk. Great! Been much anticipated :) * user encrypts a master password with CLI and stores it in ~/.m2/ sec.xml ** there is an option to store it on a removable drive and reference that from ~/.m2/sec.xml Any reason not to use a new field in settings.xml? I think 2.1.x can be capable of updating the model version. * user encrypts server password with CLI ans stores it in settings.xml * Maven decrypts the password in memory and everything works like it was before ** help:effective-settings (tested) and other tools (did not test though) still show encrypted passwords Sounds good. BTW, how is the encryption key configured? What's left before this is releasable as part of 2.1.x? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
RE: Issue with ArtifactHandler in reactor builds
I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has it's own packaging type and creates a file of it's own extension type. This only happens if I run a reactor build. If run maven in that project, it works correctly. For example, packagingmy-bundle/packaging will create artifactId-version.exe However, with maven-2.0.9 it creates the file correcting in the target directory but it installs it and deploys it as artifactId-version.my-bundle. Here is an example output: [INFO] Installing C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe to C:\Documents and Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle I wrote a similar plugin with a previous company and it worked fine. That was on maven-2.0.7 though. Here is my component.xml snippet? component-set components ... component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintmy-bundle/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration extensionexe/extension typemy-bundle/type packagingmy-bundle/packaging languagejava/language addedToClasspathtrue/addedToClasspath /configuration /component /components /component-set Does anyone have any ideas what could be happening here or have a good way to debug this?
Re: [vote] release mercury-1.0.0-alpha-4
The mercury-1.0.0-alpha-4 has been deployed to the sync directory. It will show up in central as soon as sync is run - may be several hours. Where are you getting 1.0.0-alpha-4-SNAPSHOT? What are you building? Thanks, Oleg Georgy Bolyuba wrote: Hi, I am new here, so, might be missing something. I am trying to build maven from trunk and: Missing: -- 1) org.apache.maven.mercury:mercury-event:jar:1.0.0-alpha-4-SNAPSHOT So, I am kinda confused. Is it or is it not available (mercury-1.0.0-alpha-4)? Georgy On Mon, Feb 2, 2009 at 6:44 PM, Oleg Gusakov oleg.subscripti...@gmail.com wrote: +3 binding votes, I proceed moving mercury-1.0.0-alpha-4 to production Thanks, Oleg Oleg Gusakov wrote: This is iterative improvements release of Mercury. The major change: - timestamped artifacts can now have dependencies - a bug was fixed 1 issue fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14889 Staged release in repository at http://people.apache.org/~ogusakov/repos/staging/ Site at http://people.apache.org/~ogusakov/sites/mercury Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
Thanks for the clarification, Brett. What can the maven-clover2-plugin do to ensure that only classified artifacts are resolved if they are available? On 03/02/2009, at 9:17 AM, Brett Porter wrote: Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non- classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app-domain:jar:clover: 1.0-SNAPSHOT and com.app:app-domain:jar:1.0-SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
You can't modify the resolution, but you can filter the artifacts it gets from the project. There are a few utility classes for that (you'll see them used in the dependency plugin, assembly plugin for example). - Brett On 03/02/2009, at 12:14 PM, Nick Pellow wrote: Thanks for the clarification, Brett. What can the maven-clover2-plugin do to ensure that only classified artifacts are resolved if they are available? On 03/02/2009, at 9:17 AM, Brett Porter wrote: Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non- classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app-domain:jar:clover: 1.0-SNAPSHOT and com.app:app-domain:jar:1.0-SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release mercury-1.0.0-alpha-4
Georgy Bolyuba wrote: Hi, I am new here, so, might be missing something. I am trying to build maven from trunk and: I guess, I phrased my question incorrectly: maven trunk depends on mercury 1.0.0-alpha-2, where did you get that error? Building what? Thanks, Oleg Missing: -- 1) org.apache.maven.mercury:mercury-event:jar:1.0.0-alpha-4-SNAPSHOT So, I am kinda confused. Is it or is it not available (mercury-1.0.0-alpha-4)? Georgy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: password encryption in 2.1.x trunk
On 03/02/2009, at 1:24 AM, Brian E. Fox wrote: Any reason not to use a new field in settings.xml? I think 2.1.x can be capable of updating the model version. Why introduce a bunch of new work for this? I'm just concerned that we make this exception here and suddenly we have multiple files springing up in ~/.m2, and then having to duplicate work like supporting $M2_HOME/conf/settings.xml. It's not a showstopper. Also, we wanted to make it work in 2.0.x if possible. Since it's completely optional to use, there should be little downside risk to porting it back. I'd really prefer we focused on getting 2.1 out, as you said, rather than allow another excuse not to. What's left before this is releasable as part of 2.1.x? Just some manual testing and docs updates for the site when it's ready. In the mean time, can someone please release the dependency so that we can move forward with the next milestone release? I think it's ready to go. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
Will the filtering be applied to the artifacts resolved by the maven- compiler-plugin, and the maven-surefire-plugin? My understanding is that: 1) the maven-clover2-plugin creates a classified artifact with the - clover classifier. it also looks for -clover classified artifacts of project dependencies and sets those on the MavenProject. 2) any other plugins called as part of the build lifecycle then resolve both the classified and the non-classified versions of the same artifact 3) certain plugins assert that the classpath contains only a distinct set of classes. if more than one class is found on the classpath they fail the build. AFAICT, the maven-clover2-plugin is setting a distinct set of artifacts on the project via: http://svn.atlassian.com/fisheye/browse/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java?r=27752#l325 . I think however that when the classpath is built by the maven-compiler- plugin, say, it is resolving all transitive dependencies, and finding the non-classified clovered artifact. Does this sound plausible? Should clover be swizzling dependencies transitively ? Cheers, Nick On 03/02/2009, at 12:24 PM, Brett Porter wrote: You can't modify the resolution, but you can filter the artifacts it gets from the project. There are a few utility classes for that (you'll see them used in the dependency plugin, assembly plugin for example). - Brett On 03/02/2009, at 12:14 PM, Nick Pellow wrote: Thanks for the clarification, Brett. What can the maven-clover2-plugin do to ensure that only classified artifacts are resolved if they are available? On 03/02/2009, at 9:17 AM, Brett Porter wrote: Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non- classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app-domain:jar:clover: 1.0-SNAPSHOT and com.app:app-domain:jar:1.0-SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
The dependency artifacts should already be transitive. I'm not quite sure how you are seeing the results you are. Have you tracked the output of the swizzling process? Does -X show what is then fed into the compiler plugin in the forked lifecycle? - Brett On 03/02/2009, at 3:26 PM, Nick Pellow wrote: Will the filtering be applied to the artifacts resolved by the maven- compiler-plugin, and the maven-surefire-plugin? My understanding is that: 1) the maven-clover2-plugin creates a classified artifact with the - clover classifier. it also looks for -clover classified artifacts of project dependencies and sets those on the MavenProject. 2) any other plugins called as part of the build lifecycle then resolve both the classified and the non-classified versions of the same artifact 3) certain plugins assert that the classpath contains only a distinct set of classes. if more than one class is found on the classpath they fail the build. AFAICT, the maven-clover2-plugin is setting a distinct set of artifacts on the project via: http://svn.atlassian.com/fisheye/browse/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java?r=27752#l325 . I think however that when the classpath is built by the maven- compiler-plugin, say, it is resolving all transitive dependencies, and finding the non-classified clovered artifact. Does this sound plausible? Should clover be swizzling dependencies transitively ? Cheers, Nick On 03/02/2009, at 12:24 PM, Brett Porter wrote: You can't modify the resolution, but you can filter the artifacts it gets from the project. There are a few utility classes for that (you'll see them used in the dependency plugin, assembly plugin for example). - Brett On 03/02/2009, at 12:14 PM, Nick Pellow wrote: Thanks for the clarification, Brett. What can the maven-clover2-plugin do to ensure that only classified artifacts are resolved if they are available? On 03/02/2009, at 9:17 AM, Brett Porter wrote: Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non-classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app-domain:jar:clover: 1.0-SNAPSHOT and com.app:app-domain:jar:1.0-SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: classified artifact resolution
You're right. the dependency artifacts are already transitive. e.g. the -X output shows: [DEBUG] [Clover] List of dependency artifacts after changes: [DEBUG] [Clover] Artifact [com.fidelity.shares:shares- domain:jar:clover:1.0-SNAPSHOT], scope = [compile] [DEBUG] [Clover] List of artifacts after changes: [DEBUG] [Clover] Artifact [com.fidelity.shares:shares- domain:jar:clover:1.0-SNAPSHOT], scope = [compile] The full list of artifacts 'after changes' only includes shares- domain:jar:clover .ie - the correctly resolved and classified artifact. This is in both the dependency artifacts and the artifacts list. ie: getProject ().setDependencyArtifacts (swizzleCloverDependencies( getProject().getDependencyArtifacts() ) ); getProject ().setArtifacts (swizzleCloverDependencies( getProject().getArtifacts() ) ); This seems to not be the case when resources:resources runs? A -X log file showing this is attached to our forum: output.txt . The tests fail with a: DuplicateMappingException: Duplicate class/entity mapping com.fidelity.shares.domain.simple.SimpleThing at the end of that file. Just above this, you can see that both the classified and non-classified versions of the shares-domain artifact are on the classpath. The full post is: http://forums.atlassian.com/thread.jspa?threadID=22387tstart=0 On 03/02/2009, at 3:33 PM, Brett Porter wrote: The dependency artifacts should already be transitive. I'm not quite sure how you are seeing the results you are. Have you tracked the output of the swizzling process? Does -X show what is then fed into the compiler plugin in the forked lifecycle? - Brett On 03/02/2009, at 3:26 PM, Nick Pellow wrote: Will the filtering be applied to the artifacts resolved by the maven-compiler-plugin, and the maven-surefire-plugin? My understanding is that: 1) the maven-clover2-plugin creates a classified artifact with the - clover classifier. it also looks for -clover classified artifacts of project dependencies and sets those on the MavenProject. 2) any other plugins called as part of the build lifecycle then resolve both the classified and the non-classified versions of the same artifact 3) certain plugins assert that the classpath contains only a distinct set of classes. if more than one class is found on the classpath they fail the build. AFAICT, the maven-clover2-plugin is setting a distinct set of artifacts on the project via: http://svn.atlassian.com/fisheye/browse/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java?r=27752#l325 . I think however that when the classpath is built by the maven- compiler-plugin, say, it is resolving all transitive dependencies, and finding the non-classified clovered artifact. Does this sound plausible? Should clover be swizzling dependencies transitively ? Cheers, Nick On 03/02/2009, at 12:24 PM, Brett Porter wrote: You can't modify the resolution, but you can filter the artifacts it gets from the project. There are a few utility classes for that (you'll see them used in the dependency plugin, assembly plugin for example). - Brett On 03/02/2009, at 12:14 PM, Nick Pellow wrote: Thanks for the clarification, Brett. What can the maven-clover2-plugin do to ensure that only classified artifacts are resolved if they are available? On 03/02/2009, at 9:17 AM, Brett Porter wrote: Yes, that's expected - artifacts with a particular classifier are considered different to artifacts with a different or no classifier. On 02/02/2009, at 5:44 PM, Nick Pellow wrote: Hi, The maven-clover2-plugin creates both a classified and a normal jar artifact for each sub-module it builds. I have a problem, where I am seeing both a classified _and_ a non-classified artifact being put on the classpath under certain circumstances. e..g [INFO] Compiling 3 source files to target\clover\test-classes [DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null) [DEBUG]com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile (selected for compile) ... and ... [DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile (selected for compile) This debug output shows that both com.app:app- domain:jar:clover:1.0-SNAPSHOT and com.app:app-domain:jar:1.0- SNAPSHOT:compile are on the compile time classpath. Is this expected behavior? Is there something possibly misconfigured that will cause this? Cheers, Nick Pellow Atlassian Clover. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail:
Re: Issue with ArtifactHandler in reactor builds
2009/2/3 Jason Chaffee jason.chaf...@zilliontv.tv I am having an issue on 2.0.9. Basicallly, I have a custom plugin that has it's own packaging type and creates a file of it's own extension type. This only happens if I run a reactor build. If run maven in that project, it works correctly. For example, packagingmy-bundle/packaging will create artifactId-version.exe However, with maven-2.0.9 it creates the file correcting in the target directory but it installs it and deploys it as artifactId-version.my-bundle. Here is an example output: [INFO] Installing C:\workspace\server\manager\project\bundle\target\project-1.0.0-SNAPSHOT.exe to C:\Documents and Settings\jason.chaffee\.m2\repository\com\foo\project\project\1.0.0-SNAPSHOT\project-1.0.0-SNAPSHOT.my-bundle I wrote a similar plugin with a previous company and it worked fine. That was on maven-2.0.7 though. Here is my component.xml snippet? component-set components ... component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintmy-bundle/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration extensionexe/extension typemy-bundle/type packagingmy-bundle/packaging languagejava/language addedToClasspathtrue/addedToClasspath /configuration /component /components /component-set Does anyone have any ideas what could be happening here or have a good way to debug this? hmm, sounds like http://jira.codehaus.org/browse/MNG-2426 (see also MNG-1682) as a workaround you could try to reset the handler extension in your code before installing the artifact, but this might require messing around with Maven internals -- Cheers, Stuart
Re: [vote] release mercury-1.0.0-alpha-4
Well, I was just trying to build maven trunk :) Nothing else. Georgy On Tue, Feb 3, 2009 at 4:20 AM, Oleg Gusakov oleg.subscripti...@gmail.com wrote: Georgy Bolyuba wrote: Hi, I am new here, so, might be missing something. I am trying to build maven from trunk and: I guess, I phrased my question incorrectly: maven trunk depends on mercury 1.0.0-alpha-2, where did you get that error? Building what? Thanks, Oleg Missing: -- 1) org.apache.maven.mercury:mercury-event:jar:1.0.0-alpha-4-SNAPSHOT So, I am kinda confused. Is it or is it not available (mercury-1.0.0-alpha-4)? Georgy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
