Re: Maven in Linux environment
Hi you need to put it in the pom directory in which you run maven, not the parent dir. Regards Mark On Aug 10, 2011, at 5:39 PM, kalpeer wrote: > Thanks a lot. > > I created aol.properties in my root directory of the project. that is in the > location(/opt/project) where is my parent pom.xml is available. > aol.properties: > > i386.Linux.linker=CC > > i386.Linux.CC.cpp.compiler=CC > i386.Linux.CC.cpp.defines=Linux GNU_GCC f2cFortran > i386.Linux.CC.cpp.options= > i386.Linux.CC.cpp.includes=**/*.cc **/*.cpp **/*.cxx > i386.Linux.CC.cpp.excludes= > > i386.Linux.CC.c.compiler=suncc > i386.Linux.CC.c.defines=Linux GNU_GCC f2cFortran > i386.Linux.CC.c.options= > i386.Linux.CC.c.includes=**/*.c > i386.Linux.CC.c.excludes= > > i386.Linux.CC.fortran.compiler=sunf77 > i386.Linux.CC.fortran.defines=Linux GNU_GCC f2cFortran > i386.Linux.CC.fortran.options=-Wall > i386.Linux.CC.fortran.includes=**/*.f **/*.for > i386.Linux.CC.fortran.excludes= > > i386.Linux.CC.java.include=include;include/linux > i386.Linux.CC.java.runtimeDirectory=jre/lib/i386/client > > i386.Linux.CC.linker.systemLibs=pthread:shared > > i386.Linux.CC.lib.prefix=lib > i386.Linux.CC.shared.prefix=lib > i386.Linux.CC.static.extension=a > i386.Linux.CC.shared.extension=so > i386.Linux.CC.plugin.extension=so > i386.Linux.CC.jni.extension=so > i386.Linux.CC.executable.extension= > > But during pom.xml it is not picking up aol.properties from the new > location. > > do i need to add any tag in pom.xml to specify the new location of > aol.properties. > > I am new to the maven.please correct me if am wrong. > > Thanks > Kalai > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-in-Linux-environment-tp4681852p4686269.html > Sent from the Maven Developers 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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven in Linux environment
Hi you can just create an aol.properties file in the root directory of the project. Next to pom.xml regards Mark On Aug 9, 2011, at 4:55 PM, kalpeer wrote: > Thanks a lot. I have tried with nar plugin. But still I got the same error. > > On further study it looks like AOL property needs to be updated. > I need to override the i386.Linux.linker=g++ with i386.Linux.linker=CC. > Since I am using the SunStudio compiler for building. > > > Can any one help me in overriding this. > I used the below tag > > CC > > But I am got an error. > > If you have nay document on overriding AOL properties could you please share > with me. > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-in-Linux-environment-tp4681852p4682367.html > Sent from the Maven Developers 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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven in Linux environment
Hi you can try the latest version from github maven-nar-plugin Regards Mark Donszelmann On Aug 9, 2011, at 3:18 PM, kalpeer wrote: > > > We use the below maven-compiler-plugin > > true > org.apache.maven.plugins > maven-compiler-plugin > > -g:none > > > > > > > > org.freehep > freehep-nar-plugin > 2.0-alpha-10 > true > true > > >CC > > -xO3 > -c > > > > > > > this is working fine in Solaris environment.. We have issues only in RHEL > environment. > Also can you help me on how we can specify the Compiler path. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-in-Linux-environment-tp4681852p4681976.html > Sent from the Maven Developers 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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0
Hi +1 (non-binding) works for me. Regards Mark Donszelmann On Mon, Oct 4, 2010 at 2:16 PM, Benjamin Bentmann wrote: > Hi, > > feedback on the RCs seems to be decreasing and I am currently not aware of > any major regression so let's try and cross the finishing line of this > marathon. > > We solved 31 issues since 3.0-beta-3: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=13142 > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-004/ > > Staged source and binary distros: > > https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > +1 from me > > > Benjamin > > - > 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: Deployed attached snapshot artifacts have version number one higher than expected.
Hi Kenney, your solution worked fine (in 2.0.6). The problem also existed in 2.0.5. I must have created and attached the Artifact wrongly. bedankt Mark On Jun 15, 2007, at 11:19 PM, Kenney Westerhof wrote: Hi, haven't tested this myself with 2.0.6, but take a look at some other plugins that attach artifacts (javadoc, source, assembly:attached etc) to see what the differences are. Those plugins use the ProjectHelper to attach an artifact: /** * Used for attaching the artifact in the project * * @component */ private MavenProjectHelper projectHelper; projectHelper.attachArtifact( project, "javadoc", "javadoc", outputFile ); for instance. Perhaps the Artifact you created is not constructed properly. If you could try this approach and it still creates the wrong timestamp/buildnumber then you've found a bug. -- Kenney Mark Donszelmann wrote: Hi I am attaching artifacts to the main (jar) artifact in my plugin for maven. All works fine for versioned plugins, but for SNAPSHOTS I see the following behavior: 1. mvn install installs the SNAPSHOT correctly in my local repository (correctly). 2. mvn deploy -retrieves the latest build number from the remote repository (lets say 2). -deploys the main SNAPSHOT artifact with build number 3 (correctly). -deploys the pom SNAPSHOT with build number 3 (correctly). -retrieves the latest build number again (now 3, incorrectly, it should not have retrieved it). -deploys the attached SNAPSHOT artifact with build numb er 4 (should have been 3, but got confused with the previous call). this uses mvn 2.0.6 and attaches the extra artifact with a call to project.addAttachedArtifact(artifact); in the "package" phase. The standard deploy plugin and deploy goal is used. any idea why maven looks up the latest build number twice? Did I order some calls wrongly? Regards Mark Donszelmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deployed attached snapshot artifacts have version number one higher than expected.
Hi I am attaching artifacts to the main (jar) artifact in my plugin for maven. All works fine for versioned plugins, but for SNAPSHOTS I see the following behavior: 1. mvn install installs the SNAPSHOT correctly in my local repository (correctly). 2. mvn deploy -retrieves the latest build number from the remote repository (lets say 2). -deploys the main SNAPSHOT artifact with build number 3 (correctly). -deploys the pom SNAPSHOT with build number 3 (correctly). -retrieves the latest build number again (now 3, incorrectly, it should not have retrieved it). -deploys the attached SNAPSHOT artifact with build numb er 4 (should have been 3, but got confused with the previous call). this uses mvn 2.0.6 and attaches the extra artifact with a call to project.addAttachedArtifact(artifact); in the "package" phase. The standard deploy plugin and deploy goal is used. any idea why maven looks up the latest build number twice? Did I order some calls wrongly? Regards Mark Donszelmann
Re: [VOTE] Release Maven 2.0.7 - surefire problem
Hi Kenney, On Jun 13, 2007, at 8:12 AM, Kenney Westerhof wrote: Mark Donszelmann wrote: Hi Kenney, Hi Mark, I was using 2.1.3 for surefire. Changed it to 2.3, and still get error (slightly different): Hi, this is fixed later on; i think you're missing a dependency on junit. I had it in dependencyManagement. It did work with 2.1.3 (Surefire) and mvn 2.0.5. Moved it to dependencies, now works with surefire 2.3 and 2.0.7. VOTE +1 (non-binding). Regards Mark Let me know if this is the case. Can't be due to 2.0.7 though, unless this works in 2.0.6? If there's no released version (2.3) that works for 2.0.7 then we need to release 2.3.1 asap. -- Kenney java.lang.NullPointerException at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot er(SurefirePlugin.java:594) at org.apache.maven.plugin.surefire.SurefirePlugin.execute (SurefirePlugin.java:391) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) My pom (fragment): maven-surefire-plugin 2.3 pertest **/*TestSuite.java **/TestSuite.java Could not test SNAPSHOTs yet. Regards Mark Donszelmann On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote: Hi, can you find the surefire plugin version you're using? I've fixed this problem in the latest snapshots. Only the snapshots were faulty, latest release should be fine. If that one is broken too, can you try one of the latest snapshots (2.4-snapshot or 2.3.1-snapshot), so we can determine wheter it's a fault in surefire or in maven 2.0.7? Thanks, Kenney Mark Donszelmann wrote: Hi tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells me following in one case: RUN ABORTED java.lang.LinkageError org.apache.maven.surefire.Runner An exception or error caused a run to abort. Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints running with -e gives me: org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWith Lifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndH andleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegm ents(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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.invo
Re: [VOTE] Release Maven 2.0.7 - surefire problem
Hi Kenney,
I was using 2.1.3 for surefire. Changed it to 2.3, and still get
error (slightly different):
java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(
SurefirePlugin.java:594)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute
(SurefirePlugin.java:391)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
ycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
Failures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:
334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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)
My pom (fragment):
maven-surefire-plugin
2.3
pertest
**/*TestSuite.java
**/TestSuite.java
Could not test SNAPSHOTs yet.
Regards
Mark Donszelmann
On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote:
Hi,
can you find the surefire plugin version you're using? I've fixed this
problem in the latest snapshots. Only the snapshots were faulty,
latest release should be fine.
If that one is broken too, can you try one of the latest snapshots
(2.4-snapshot
or 2.3.1-snapshot), so we can determine wheter it's a fault in
surefire or in
maven 2.0.7?
Thanks,
Kenney
Mark Donszelmann wrote:
Hi
tried 2.0.7 on FreeHEP, seems to work on most parts, except it
tells me following in one case:
RUN ABORTED
java.lang.LinkageError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader
constraints
running with -e gives me:
org.apache.maven.lifecycle.LifecycleExecutionException: There are
test failures.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:564) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:459) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycleExecutor.java:143) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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)
Caused by: org.apache.maven.plugin.MojoExecutionException: There
are test failures.
at org.apache.maven.test.SurefirePlugin.execute
(SurefirePlugin.java:389)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManager.java:
Re: [VOTE] Release Maven 2.0.7
Hi tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells me following in one case: RUN ABORTED java.lang.LinkageError org.apache.maven.surefire.Runner An exception or error caused a run to abort. Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints running with -e gives me: org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: There are test failures. at org.apache.maven.test.SurefirePlugin.execute (SurefirePlugin.java:389) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:539) ... 16 more I have seen this error before on 2.0.6 which refrained me from using it. 2.0.5 works fine though. Any idea? Do ot let me hold up the release, I am sure it is a config error on my side, but if you have a hint, let me know. Regards Mark Donszelmann On Jun 12, 2007, at 10:12 PM, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500&styleName=Html&version=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects
Hi well, as far as I can conclude, an aggregated build will calculate the order in which to generate (and install) the artifacts, so that any module dependent on them is run later than the one generating them. I am still confused though about your command: mvn install release:prepare will just execute these in order, so the poms would not have been changed. Max suggests to use -DpreparationalGoals="clean install" which would change the goals as part of the release:prepare. Regards Mark On Jun 6, 2007, at 8:12 AM, Graham Leggett wrote: On Wed, June 6, 2007 4:50 pm, Mark Donszelmann wrote: The workaround for us to release aggregated projects is like this: mvn install release:prepare but this would do the install w/o the poms being changed from 3.3- SNAPSHOT to 3.3, so this would not help. And yet it does help. I suspect that in "aggregated mode" the versions are not changed, but the install is not done, it only goes as far as "integration-test". If the versions were changed to 3.3 before running the aggregated build, the aggregated build would always fail due to missing artifacts, and this doesn't happen in practise. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects
Hi On Jun 6, 2007, at 4:41 AM, Graham Leggett wrote: On Tue, June 5, 2007 9:06 pm, Brett Porter wrote: Right. The reason for not choosing to install by default is that you end up with a "release" in your local repository which is not the final one. We've run into this problem as well - the version being tested, as far as I am aware, is the SNAPSHOT version, meaning that at the end of this, an up to date build of snapshot will be included in the local repository, which is perfectly reasonable. The workaround for us to release aggregated projects is like this: mvn install release:prepare but this would do the install w/o the poms being changed from 3.3- SNAPSHOT to 3.3, so this would not help. Regards Mark Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects
Hi I am using an aggregate project such as: T -A -B -C where C and B have a dependency on A and A, B, C all use T as their parent pom. When I run "mvn install" the projects are run in the correct order: "T, A, B, C" and all works fine for lets say 3.3-SNAPSHOT. When I now run "mvn release: prepare" the projects are still run in order "T, A, B, C", but B fails to find A-3.3. Looking at the log it seems "mvn release:prepare" runs as goals "clean, verify" which does NOT install artifact A-3.3 in my local repository. A compiles fine, since it only depends on T, which is found in the parent directory. It looks to me that the release plugin should have run "clean, install". WORKAROUND I managed to release by doing the following: mvn release:prepare (fails at B, but leaves poms with version 3.3) mvn install (installs 3.3 libraries in local repository) mvn release:clean svn revert -R . (resets the poms to 3.3-SNAPSHOT) mvn release:prepare (now find 3.3 artifacts in local repository mvn release:perform -- But this cannot be the intended way of releasing. Am I missing something or is there maybe a problem with the release plugin. mvn 2.0.5 and maven-release-plugin-2.0-beta-6 Regards Mark Donszelmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
Hi Joerg, our test nar goal (which we call integration test nar, since it checks tests against the jar and the native libs, will put any native libs on the java.library.parth which are (transitive) dependencies. For libs that are dependencies but that we do not build, we just wrap them in a nar file and publish them locally, so that we can depend on them. Wrapping is no more that jar-ring up the file structure correctly (look in a produced nar file) and adding a nar.properties file. For a set of system libs, you should get a yourlib-version.jar file (w/o java files I guess), and some yourlib-version-aol-static.nar file. Regards Mark On Apr 9, 2007, at 3:54 PM, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hello Mark, the freehep-nar-plugin does exactly what you describe. http://java.freehep.org/freehep-nar-plugin Thanks for the hint. This sounds promising. Anyways I am not creating system libraries, I just want to use them in my project. From your documentation I could not really find how to get startet in putting the *.so and *.dll files in a NAR file and define this as dependency so my test-cases will have this available in java.library.path. Can you give me another hint how to archieve this? Regards Mark Donszelmann Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGsQ9mPuec2Dcv/8RAqHRAJ9XVaB/LpVdkMxo7A+F9m9UtT8K3gCfY4tI WP8yvDPbVyxDUD4lCCVLRtg= =Nu4R -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
We can change the license to something else, no problem. Regards Mark On Apr 7, 2007, at 12:37 AM, Jason Dillon wrote: Ah, I remember reading about this before, though it was a while ago. Too bad this is LGPL, as that is going to prevent a lot of folks from using it :-( --jason On Apr 6, 2007, at 7:21 PM, Mark Donszelmann wrote: Hi the freehep-nar-plugin does exactly what you describe. http://java.freehep.org/freehep-nar-plugin Regards Mark Donszelmann On Apr 6, 2007, at 5:33 PM, [EMAIL PROTECTED] wrote: Its probably better to zip the natives up and then use the zip file as the artifact, and then hook up support to extract them to some tmp dir for inclusion in the library path. Would also be nice to have a standard artifact type/ext to use for all share library types. And perhaps allow multipule arch files in the same artifact, probably including some descriptor to configure while bits get loaded for which platform. --jason -Original Message- From: Joerg Hohwiller <[EMAIL PROTECTED]> Date: Fri, 06 Apr 2007 21:24:53 To:Maven Developers List Subject: dependency on system library (java.library.path) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have already used SWT and GWT together with maven. Both need native system libraries at some specific point. This causes trouble when running code (e.g. test-cases) with maven. Are there any plans to add dependencies with dll (or so) to java.library.path? For system libraries however the name cares when it is loaded from something that I can not control (foo-1.0.jar loads foo.dll and it can not be named foo-1.0.dll). Is there a way to put various artifacts with different versions but the same file-name into a maven repository? In other words: The filename of an artifact is automatically derived from artifactId, version, classifier and type. Is there a way to override this default behaviour and specify an explicit name? Example: org/eclipse/swt/swt-win32/3.2.1/swt-win32.dll org/eclipse/swt/swt-win32/3.2.2/swt-win32.dll org.eclipse.swt swt-win32 3.2.2 dll runtime swt-win32.dll Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFp6EmPuec2Dcv/8RAoDjAKCJrr0xdI3iXUvYzLYiE2RLi45XLgCfThMo 1ecdAOdt55WlfcTYfE7AS+k= =W5G2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
Hi the freehep-nar-plugin does exactly what you describe. http://java.freehep.org/freehep-nar-plugin Regards Mark Donszelmann On Apr 6, 2007, at 5:33 PM, [EMAIL PROTECTED] wrote: Its probably better to zip the natives up and then use the zip file as the artifact, and then hook up support to extract them to some tmp dir for inclusion in the library path. Would also be nice to have a standard artifact type/ext to use for all share library types. And perhaps allow multipule arch files in the same artifact, probably including some descriptor to configure while bits get loaded for which platform. --jason -Original Message- From: Joerg Hohwiller <[EMAIL PROTECTED]> Date: Fri, 06 Apr 2007 21:24:53 To:Maven Developers List Subject: dependency on system library (java.library.path) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have already used SWT and GWT together with maven. Both need native system libraries at some specific point. This causes trouble when running code (e.g. test-cases) with maven. Are there any plans to add dependencies with dll (or so) to java.library.path? For system libraries however the name cares when it is loaded from something that I can not control (foo-1.0.jar loads foo.dll and it can not be named foo-1.0.dll). Is there a way to put various artifacts with different versions but the same file-name into a maven repository? In other words: The filename of an artifact is automatically derived from artifactId, version, classifier and type. Is there a way to override this default behaviour and specify an explicit name? Example: org/eclipse/swt/swt-win32/3.2.1/swt-win32.dll org/eclipse/swt/swt-win32/3.2.2/swt-win32.dll org.eclipse.swt swt-win32 3.2.2 dll runtime swt-win32.dll Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFp6EmPuec2Dcv/8RAoDjAKCJrr0xdI3iXUvYzLYiE2RLi45XLgCfThMo 1ecdAOdt55WlfcTYfE7AS+k= =W5G2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Delay in posting
Hi I just wondered why there is a ~5 hour delay between posting my message to this list and its appearance? Is the list that big, or is this on purpose to prevent spam? This was posted at 7:00 AM in California. Regards Mark Donszelmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating source from a plugin
Hi we use the FreeHEP-NAR-Plugin (http://java.freehep.org/freehep-nar-plugin) to wrap the SWIG (http://www.swig.org) compiler and make it usable (for java) in maven with the FreeHEP-SWIG-Plugin (http://java.freehep.org/freehep-swig-plugin). The SWIG plugin in collaboration with the NAR plugin handles the download of a platform dependent swig binary, unpacks it in maven's local repository, and calls the executable in te generate-sources phase. For configuration you can look at our G4Java project (http://java.freehep.org/sandbox/G4Java) which needs SWIG to create a Java wrapper around a C++ program. Regards Mark Donszelmann Stanford Linear Accelerator Center - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Monday, November 27, 2006 6:05 PM Subject: Re: Generating source from a plugin You could include the compiler in the plugin's jar, then extract it into /tmp (or something) to execute it. But, unless you include a bunch of platform binaries its not going to be very portable. Easier to expect the compiler to be on the system search path and execute it... or expose the location of the compiler as configuration (or both). --jason On Nov 27, 2006, at 5:54 PM, Crossley, Jim wrote: I'm in the midst of converting some fairly complex ant-based J2EE projects to Maven2. One thing I need to do is generate some Java source from some Flavor source files (http://flavor.sf.net) in the 'generate-sources' phase, so a Maven plugin for doing so seems the right course. But here's the rub: the Flavor compiler -- the thing that turns *.fl files into *.java -- doesn't have a Java interface. It's a C++ executable. So I have two questions... 1) Can I distribute the Flavor executable with my plugin? I'm pretty sure the license allows it, but I don't understand the Maven mechanism for distributing plugin resources. 2) How do I reference the location of the exe (in order to invoke it) from the plugin when the generate-sources phase fires? Thanks so much! Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
Hi System.load: - for the user we still need to make some assembly goal that grabs all the shared and jni like libs and puts them in a lib directory. A small setup script can then set the appropriate ld_library_path or the like. - for maven the nar plugin includes an integration test goal, which runs after packaging, and runs as part of maven, so it knows how to set the java.library.path to run the tests. The lava.library.path is set to the produced jni/ so file and all its dependencies. Naming: The artifactID and version are picked up from the "standard" maven properties file in the jar file. Regards Mark On Jun 19, 2006, at 8:18 AM, Richard van der Hoff wrote: Mark Donszelmann wrote: The NAR gets unpacked in the local repository under the directory where the jar file is stored, so underneath a parent directory with that version number. Ah ha, I see. In that case, how does your System.load() call know where to find the library? I guess it has knowledge of group, artifact, version built into the java jar? And if you have libraries which are linked at the native level, how does the os library loader know where to find the prerequisite libraries? Cheers, Richard -- Richard van der Hoff <[EMAIL PROTECTED]> Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
The jar file and its attached nar files share one pom, so are associated to one version. The NAR gets unpacked in the local repository under the directory where the jar file is stored, so underneath a parent directory with that version number. Nothing is currently done about locking the file system while unpacking, so running two mavens in parallel using the same local repository may not work correctly, but I have seen maven (with jars only) making mistakes in writing metafiles when two mavens run in parallel, so this may be a general problem still. Regards Mark On Jun 19, 2006, at 2:32 AM, Richard van der Hoff wrote: Mark Donszelmann wrote: Hi in the freehep-nar-plugin (for maven 1, being ported to maven 2) we have such a solution. > Hrm, I wish I'd heard about this sooner! Sounds very interesting. I have a couple of questions... Do you unpack all nar files into the same directory? If so, how do you deal with different projects needing different versions of nars? Cheers, Rich -- Richard van der Hoff <[EMAIL PROTECTED]> Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestions for handling native libraries
Hi in the freehep-nar-plugin (for maven 1, being ported to maven 2) we have such a solution. We build a generic jar file (with classes as needed and a special properties file). The properties file refers to native jar files (nar files), normally: the noarch file which has the include directories and a aol (architecture-os-linker) file which contains native libraries. The user in his pom just refers to the generic jar file for his dependency. The NAR plugin uses (for maven 2) its own packaging (nar) which resembles the jar packaging, but adds goals to several phases. Maven will download the generic jar file. The nar packing will look in the properties file and download any referred nar files (some of which are "aol" specific for the platform you run maven on). It will then unpack the nar files into a nar directory in the local repository. And add specific include paths and library settings to the local compiler/linker setup. This uses cpptasks to get the job done. In the end, the generated lib and include files for the project are wrapped up in a generic jar file and a noarch and aol nar file. These are installed/deployed as usual. The noarch and aol files are attached artifacts. Another project can thus rely on this (native) library. There is very little to configure by the user, apart from a reference to the nar plugin, the type (shared, static, ...) of library to be produced, and the nar packaging. The nar plugin exists for maven 1 (with a slightly different approach since there is no packaging in maven1) http://java.freehep.org/freehep-nar-plugin and we are porting it currently to maven2. Regards Mark Donszelmann On Jun 16, 2006, at 10:32 AM, Hiram Chirino wrote: On 5/9/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote: ... This brings me to my next thought, which is that the maven "artifact" probably ought to be a zip file (or similar) containing the correctly-named library. This is good because it means my artifacts have the same extension no matter what platform they were built for; I can distinguish between platforms using the classifier; and I can be sure that the name of the library itself is just right for the given platform. On the other hand, it means I now need to set up my assembly such that the zip files are unpacked. Ideally, I'd like for all such artifacts to be unpacked automatically, but there doesn't seem to be any way of doing so without configuring it in each assembly.xml. It's a property of the artifact, rather than the assembly, so it would be nice to somehow derive this from an ArtifactHandler rather than in the assembly descriptor. I can probably fudge this with a shared assembly descriptor, however. ... I think your on the right path here. Having the native artifacts in zip would very handy. But how about instead of the artifact being a zip, it's a directory? If maven could deploy and retrieve a whole directory as an artifact, it should make things easier for your use case correct? The reason I'm think this way, is that in the native world, if you want to distribute a native .dll (shared library), the library is more than just the dll, you also have to distribute the .h files the define the interfaces into that binary shared library. And if there were being pushed up into a maven repo, then when it was downloaded, the c++ compiler would need to add to the include path the directory where those .h files are at. So those .h files need to be in a directory, not in a .zip file. And note, if an artifact is a directory, I don't care is maven zip / tars that directory when it puts it on the remote repo, a long as when it puts it on the local repo it back to it's original directory form. -- Regards, Hiram Blog: http://hiramchirino.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1856) legacy layout tag in a profile does not show up in child pom.
legacy layout tag in a profile does not show up in child pom. - Key: MNG-1856 URL: http://jira.codehaus.org/browse/MNG-1856 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.1 Environment: Windows XP Reporter: Mark Donszelmann Priority: Minor Fix For: 2.0.3 the legacy layout tag in a profile does not show up in an inherited pom. Given the following pom.xml: 4.0.0 xxx yyy 1.0-SNAPSHOT pom maven-1 maven1 maven-1-repo Maven1 Repository sftp://... legacy gives for: mvn projecthelp:effective-pom -Dmaven1 the following result: ... maven-1-repo Maven1 Repository sftp://... legacy which is CORRECT, however if I inherit from this pom with the following pom.xml: xxx yyy 1.0-SNAPSHOT 4.0.0 uuu vvv 2.0-SNAPSHOT gives for: mvn projecthelp:effective-pom -Dmaven1 the following result: ... maven-1-repo Maven1 Repository sftp://... which is INCORRECT, the layout tag is missing. This issue may be related to: http://jira.codehaus.org/browse/MNG-731 http://jira.codehaus.org/browse/MNG-1756 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1707) eclipse:eclipse should execute in a later phase than "generate-sources"
[ http://jira.codehaus.org/browse/MNG-1707?page=comments#action_52354 ] Mark Donszelmann commented on MNG-1707: --- sorry, my misunderstanding of that tag. Please correct the subject of this issue, I do not seem to have privs to do so. Indeed the eclipsePlugin has this tag as well. However I do thing that it needs a later phase here, because other plugins may add paths to the compileSourceRoots and testCompileSourceRoots. phases such as process-sources, process-test-sources (which may filter some files and put the result elsewhere). should not be neglected. Looking at the default lifecycle I guess that the "test" phase (or just before) should be executed as part of the eclipse:eclipse goal, to make sure one has all the paths for sources, test-sources, resources and test-resources. I may be wrong... > eclipse:eclipse should execute in a later phase than "generate-sources" > --- > > Key: MNG-1707 > URL: http://jira.codehaus.org/browse/MNG-1707 > Project: Maven 2 > Type: Improvement > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Mark Donszelmann > Fix For: 2.0.1 > > > the eclipse:eclipse goal should run in a later phase than it currently does > (generate-sources) > as user defined plugins may add to the compileSourceRoots and > testCompileSourceRoots. > If it runs later, added paths will be written correctly to the .classpath. > Suggested phase is "test" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1708) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin - Key: MNG-1708 URL: http://jira.codehaus.org/browse/MNG-1708 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann Fix For: 2.0.1 The maven-compiler-plugin allows a configuration such as: maven-compiler-plugin **/idl/*Factory.java the generated .classpath file currently does not mention the excluded part: which should be: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1707) eclipse:eclipse should execute in a later phase than "generate-sources"
eclipse:eclipse should execute in a later phase than "generate-sources" --- Key: MNG-1707 URL: http://jira.codehaus.org/browse/MNG-1707 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Reporter: Mark Donszelmann Fix For: 2.0.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is "test" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1559) Error (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar) for clean goal.
Error (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar) for clean goal. -- Key: MNG-1559 URL: http://jira.codehaus.org/browse/MNG-1559 Project: Maven 2 Type: Bug Components: maven-clean-plugin Versions: 2.0 Reporter: Mark Donszelmann Priority: Minor Attachments: components.xml This may or may not be a bug. The attached "nar" packaging works fine for any other goal than "clean". The "clean" goal works, but outputs the error message: (Nonexistent component: org.apache.maven.lifecycle.mapping.LifecycleMappingnar) When run with the "clean:clean" goal the message does not appear. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1401) Dutch (NL) translation for site and reports plugins
[ http://jira.codehaus.org/browse/MNG-1401?page=all ] Mark Donszelmann updated MNG-1401: -- Attachment: site-plugin_nl.properties first file done, second on the way. > Dutch (NL) translation for site and reports plugins > --- > > Key: MNG-1401 > URL: http://jira.codehaus.org/browse/MNG-1401 > Project: Maven 2 > Type: Improvement > Components: maven-site-plugin, maven-project-info-reports-plugin > Versions: 2.0 > Reporter: Mark Donszelmann > Priority: Trivial > Fix For: 2.0.1 > Attachments: site-plugin_nl.properties > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1401) Dutch (NL) translation for site and reports plugins
Dutch (NL) translation for site and reports plugins --- Key: MNG-1401 URL: http://jira.codehaus.org/browse/MNG-1401 Project: Maven 2 Type: Improvement Components: maven-site-plugin, maven-project-info-reports-plugin Versions: 2.0 Reporter: Mark Donszelmann Priority: Trivial Fix For: 2.0.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1345) "No such file or directory" when resource targetdirectory contains "../" and target/classes does not exist.
[ http://jira.codehaus.org/browse/MNG-1345?page=comments#action_49478 ]
Mark Donszelmann commented on MNG-1345:
---
its "../" and not "./"
if I remove it, the filtered sources end up in
"target/classes/generated-sources/filter" rather than
"target/generated-sources/filter"
The whole problem is that targetPath is relative to "target/classes" rather
than "target", which is why I put "../"
I guess the maven-resources-plugin should just create "target/classes" by
default.
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> ---
>
> Key: MNG-1345
> URL: http://jira.codehaus.org/browse/MNG-1345
> Project: Maven 2
> Type: Bug
> Components: maven-resources-plugin
> Versions: 2.0
> Environment: Linux fails, Windows is fine.
> Reporter: Mark Donszelmann
> Assignee: Edwin Punzalan
> Priority: Minor
> Fix For: 2.0.1
>
>
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> example:
>
> ../generated-sources/filter
> true
> ${basedir}/src/main/java
>
> **/*
>
>
> since the targetdirectory is relative to "target/classes" (or whatever the
> setting is to put the class files)
> the plugin fails with a
> "No such file or directory:
> target/classes/../generated-sources/filter/."
> if target/classes does not exist.
> On Windows it works fine, on Unix it fails.
> Workaround: copy some resources to target/classes first, so that
> target/classes exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1345) "No such file or directory" when resource targetdirectory contains "../" and target/classes does not exist.
[ http://jira.codehaus.org/browse/MNG-1345?page=comments#action_49469 ]
Mark Donszelmann commented on MNG-1345:
---
Unix/AFS permissions are ok.
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> ---
>
> Key: MNG-1345
> URL: http://jira.codehaus.org/browse/MNG-1345
> Project: Maven 2
> Type: Bug
> Components: maven-resources-plugin
> Versions: 2.0
> Environment: Linux fails, Windows is fine.
> Reporter: Mark Donszelmann
> Assignee: Edwin Punzalan
> Priority: Minor
> Fix For: 2.0.1
>
>
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> example:
>
> ../generated-sources/filter
> true
> ${basedir}/src/main/java
>
> **/*
>
>
> since the targetdirectory is relative to "target/classes" (or whatever the
> setting is to put the class files)
> the plugin fails with a
> "No such file or directory:
> target/classes/../generated-sources/filter/."
> if target/classes does not exist.
> On Windows it works fine, on Unix it fails.
> Workaround: copy some resources to target/classes first, so that
> target/classes exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1345) "No such file or directory" when resource targetdirectory contains "../" and target/classes does not exist.
[ http://jira.codehaus.org/browse/MNG-1345?page=comments#action_49468 ]
Mark Donszelmann commented on MNG-1345:
---
Maven 2.0
maven-resources-plugin 2.1
checked on unix:
one cannot do:
ls non-existing-directory/../existing-directory
or even
mkdir non-existing-directory/../new-directory
though
mkdir -p non-existing-directory/../new-directory works.
below the real output:
--
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying resources
Embedded error:
/afs/slac.stanford.edu/u/ec/duns/w8/freehep-m2/freehep-tools/freehep-aid/target/classes/../generated-sources/filte$
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error copying resources
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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:324)
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 copying
resources
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:176)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:100)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
... 16 more
Caused by: java.io.FileNotFoundException:
/afs/slac.stanford.edu/u/ec/duns/w8/freehep-m2/freehep-tools/freehep-aid/target/classes/$
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at java.io.FileWriter.(FileWriter.java:73)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:228)
at
org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
... 19 more
[INFO]
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> ---
>
> Key: MNG-1345
> URL: http://jira.codehaus.org/browse/MNG-1345
> Project: Maven 2
> Type: Bug
> Components: maven-resources-plugin
> Versions: 2.0
> Environment: Linux fails, Windows is fine.
> Reporter: Mark Donszelmann
> Assignee: Edwin Punzalan
> Priority: Minor
> Fix For: 2.0.1
>
>
> "No such file or directory" when resource targetdirectory contains "../" and
> target/classes does not exist.
> example:
>
> ../generated-sources/filter
> true
> ${basedir}/src/main/java
>
> **/*
>
>
> since the targetdirectory is relative to "target/classes" (or whatever the
> setting is to put the class files)
> the plugin fails with a
> "No such file or directory:
> target/classes/../generated-sources/filter/."
> if target/classes does not exist.
> On Windows it works fine, on Unix it fails.
> Workaround: copy some resources to
[jira] Created: (MNG-1346) Add link to javadoc in configuration description page for user defined types of Mojos.
Add link to javadoc in configuration description page for user defined types of Mojos. -- Key: MNG-1346 URL: http://jira.codehaus.org/browse/MNG-1346 Project: Maven 2 Type: Improvement Components: maven-plugin-descriptor Versions: 2.0 Reporter: Mark Donszelmann The documentation page for the configuration of a Mojo, as currently generated, only documents basic types (booleans, Lists, Sets, Properties) but fails to say anything about User Defined types (for which a class is picked up from the Mojo directory). A link to the javadoc could be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1345) "No such file or directory" when resource targetdirectory contains "../" and target/classes does not exist.
"No such file or directory" when resource targetdirectory contains "../" and
target/classes does not exist.
---
Key: MNG-1345
URL: http://jira.codehaus.org/browse/MNG-1345
Project: Maven 2
Type: Bug
Components: maven-resources-plugin
Versions: 2.0
Environment: Linux fails, Windows is fine.
Reporter: Mark Donszelmann
Priority: Minor
Fix For: 2.0.1
"No such file or directory" when resource targetdirectory contains "../" and
target/classes does not exist.
example:
../generated-sources/filter
true
${basedir}/src/main/java
**/*
since the targetdirectory is relative to "target/classes" (or whatever the
setting is to put the class files)
the plugin fails with a
"No such file or directory:
target/classes/../generated-sources/filter/."
if target/classes does not exist.
On Windows it works fine, on Unix it fails.
Workaround: copy some resources to target/classes first, so that target/classes
exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPARTIFACT-53) plugin ends up in wrong directory when deployed with sftp
plugin ends up in wrong directory when deployed with sftp - Key: MPARTIFACT-53 URL: http://jira.codehaus.org/browse/MPARTIFACT-53 Project: maven-artifact-plugin Type: Bug Versions: 1.5.1 Reporter: Mark Donszelmann Fix For: 1.5.2 > when trying to deploy my plugin on my plugin on my own maven repository > using the latest 1.5.1 Artifact Plugin using sftp and a private key, > all seems to go well: > > plugin:repository-deploy: > [echo] Deploying... > Will deploy to 1 repository(ies): freehep > Deploying to repository: freehep > Uploading to freehep/poms/freehep-jas-plugin-1.0.pom: > (6K) > Will deploy to 1 repository(ies): freehep > Deploying to repository: freehep > Uploading to freehep/plugins/freehep-jas-plugin-1.0.jar: > (2K) > BUILD SUCCESSFUL > > however, the pom and jar files (including the md5 and sha1) ended up in: > > 'freehep' rather than in the subdirs 'freehep/plugins' and 'freehep/poms' > > it seems the type is forgotten... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
