Re: Julia Antonova/Tumlare is out of the office.
Is there any chance of unsubscribing Ms Antonova? I think we are now all aware just when she's back from vacation... Julia Antonova wrote: I will be out of the office starting 18-07-2007 and will not return until 01-08-2007. I will respond to your message when I return. Pls. forward all messages to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't commit because of a locked dir
On Jul 12, 2007, at 10:36 AM, Fabrice Bellingard wrote: Today, I've tried several times to commit code in the maven-assembly-plugin, and I always get the same message: --- Attempted to lock an already-locked dir svn: Working copy 'C:\Maven\workspace\maven-assembly-plugin\src' locked --- That's a lock on the working copy, no? Try svn cleanup. -- 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: dependency version ignored
Ecker Severin wrote: Hi, Unfortunately removing the exclusion clause didn't help ;/ is there anything wrong with my pom file? I can't find a problem there but maybe I'm missing something. Can't see anything obviously wrong. You might try running mvn with -X which will give you lots of debug, including a bit about how it's resolving dependencies. I don't think it's causing your problem, but one thing to note is that if you are only using junit for testing, you should specify it with scopetest/scope to avoid it ending up on your runtime classpath. -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:[EMAIL PROTECTED] Gesendet: Montag, 14. Mai 2007 17:32 An: Maven Developers List Betreff: Re: dependency version ignored Remove the junit exclusion under axis2-kernel and try again. Wayne On 5/14/07, Ecker Severin [EMAIL PROTECTED] wrote: Hi, I've tried both, version 2.0.5 and 2.0.6, equal results. Best regards, severin -Ursprüngliche Nachricht- Von: Ralph Goers [mailto:[EMAIL PROTECTED] Gesendet: Montag, 14. Mai 2007 16:00 An: Maven Developers List Betreff: Re: dependency version ignored What version of maven are you using? Ecker Severin wrote: Hi, There seems to be no one who can help me in the users list so I hope that someone around here does haven an idea: My problem is as follows: I'm not sure whether I'm not using dependencies correctly or this is a bug, but the situation is as follows: I have a junit 4.1 dependency in my project (and also xmlbeans). Now xmlbeans happens to have a dependency on junit 3.8. The problem is that my project uses junit 4 annotations BUT maven simply ignores my dependency and is totally content with junit3.8 on the classpath. Needless to say that the compilation fails. //this fails mvn clean test //all of these work, the first line always fails because of the missing junit4 of course mvn clean compile mvn compile test mvn clean compile mvn compiler:testCompile mvn clean compile mvn test A simple example looks like this: I've stripped some dependencies and all the repositories to keep the pom as simple and short as possible: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdmygroup/groupId artifactIdmyart/artifactId packagingjar/packaging version1.0/version build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdxmlbeans-maven-plugin/artifactId executions execution goals goalxmlbeans/goal /goals phasegenerate-sources/phase /execution /executions /plugin plugin groupIdorg.apache.axis2/groupId artifactIdaxis2-wsdl2code-maven-plugin/artifactId versionPATCHED/version executions execution goals goalwsdl2code/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0/version configuration source1.5/source target1.5/target /configuration /plugin /plugins /build dependencyManagement dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.1/version /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.apache.axis2/groupId artifactIdaxis2-kernel/artifactId versionSNAPSHOT/version scopecompile/scope exclusions exclusion groupIdjunit/groupId artifactIdjunit/artifactId /exclusion /exclusion /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.1/version /dependency /dependencies /project Thanks in advance and best regards, Severin - 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] -- 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: Remove auto-resolution of plugin versions from Maven 2.1
Carlos Sanchez wrote: I think every maven release should use a defined set of plugin versions. That would be reproducible and close to what it's happening now. I can't really agree with this; if maven provides a set of default plugin versions, people will continue to not specify explicit versions. Then, when a new version of maven is released, we have the same problem as we do now - people will upgrade and wonder why their build broke. Either that, or they will be in mortal fear of upgrading the maven core for fear of breaking something. Plugin version should definitely be tied to your project, not your maven version. Making the user list all plugins it's gonna be killer for newbies. I agree with this part. There does need to be some way of tying down the versions of plugins used in the default lifecycle, other than forcing the pom writer to specify each one individually. Perhaps could be done by having a centralised base-pom which people could inherit from? Or by having packagings specify default plugin versions - and then you would only need to specify the version of the plugin providing the packaging. Regards, Richard, who so far has only found one build which broke as a result of the assembly-plugin release... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
Yes! Please! Oh god, yes John Casey wrote: Hi everyone, I wanted to call a vote to release a beta version of the new assembly plugin. There are still some outstanding issues (though not as many as jira would have you believe; they just need tests), but I think we're at around 95-99% backward compatibility and the new features seem to be working well. It's been just sitting in SVN for quite awhile now, and many people are using it directly from there. I'd like to provide better support for those people, and start getting more feedback on exactly what's still broken. The change list is pretty large, but is mainly concerned with refactoring the plugin away from the old monolithic approach to one that uses phases to handle the different descriptor sections, along with common task classes to handle behavior shared between phases. Road Map: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repo Also, since this is just a beta, and there are some folks out there waiting on this release to release some of their own components, I'd like to make this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we agree to do this in short order, I would like to get this release out on this vote, so don't let the timing affect your +1...if people complain, I'll just let it sit for the standard 72h. So, let's try for 24hrs. Please vote +1/+0/-1. Here's my +1. -john -- 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]
maven-assembly-plugin release?
Hi guys, Is there any possibility I can prod you for a release of maven-assembly-plugin 2.2? As far as I can tell, all the SNAPSHOTs it depends on have now been released, it fixes about a bazillion bugs, and the docs on the site have referred to the SNAPSHOT for ages. 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: Why is prerequisites not inherited?
Brian E. Fox wrote: Now? Works fine for me. Thanks for sorting that, Brian! -- 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: JIRA ID for plugins run twice when parent defines execution?
Jason van Zyl wrote: On 15 Feb 07, at 9:32 AM 15 Feb 07, Jason Dillon wrote: This does not appear to be fixed in 2.0.5... I'm still seeing duplicate plugin executions when parent and child both define executions of a plugin :-( If you augment or create an issue with a test project (and yes, the hard part is making the test project that stands alone) then we can put it in for the next round of releases. There's a testcase in the patch on MNG-2297, no? And I thought this had gone into 2.0.5... It's possible there's another bug lurking somewhere. Jason D, Can you try out the testcase in http://jira.codehaus.org/secure/attachment/20899/maven-project-plugins.patch? PS: Richards changes work well, hope this is will be activated with 2.05 I hoped so too... 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]
Mail client [was Re: JIRA ID for plugins run twice when parent defines execution?]
Brian E. Fox wrote: Isn't that because the default plugins don't use an execution? Ie their configuration tag is outside the executions tags. Brian, is there any chance I could persuade you to use a mail client which supports In-Reply-To: or References: headers? You've just created three new threads. :/ -- 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: [maven-eclipse-plugin] addVersionToProjectName
Jason van Zyl wrote: We're going to be releasing a new version (looking like tomorrow) so you can take a look at the roadmap after that. Wasn't there a release made like last week? What's changed this time? [I'd like to put in a bid for MECLIPSE-151's patch to be applied]. 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: versioning
Carlos Sanchez wrote: Sound like a lot of added complexity that will cause trouble to all tooling on top of Maven Can you justify that with an example, at all? What about forcing the xml schema to a standard versioning system. If it's used then you'll benefit from all Maven goodies. If you just use a String Maven will do its best. For instance version major1/major minor2minor bug1/bug buildnumber123/buildnumber /version The problem is basically that this simply isn't powerful enough to cover all the various versioning schemes there are in the wild. Suggesting forcing everybody to conform to your idea of versioning isn't at all helpful; similarly imposing a complex mapping between upstream and maven versions for a project is unattractive. Furthermore you don't leave any scope for extension such as might be required for local modifications of a project. Stéphane also suggested forcing a particular versioning convention on everybody - the same argument applies. Regarding Kenney's proposal: as discussed on #maven, all sounds very sensible to me. I'm still fishing for, and failing to find, examples of failures for projects where people invert the precedence of . and -; however anyone doing that probably deserves what they get. I don't think it would be unreasonable to expect a project's maven versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping through hoops to make this work may not be worthwhile. Is it a given that we want SNAPSHOT alpha beta gamma rc ga ? What happens when we've released an alpha, but want to continue hacking on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and ga, no? Also, does unknown(lexical sort) '' not conflict with In my sample implementation, 2.0.1-xyz is newer than 2.0.1.? I may just be misunderstanding your explanation, but if you could clarify what exactly happens when a given component isn't present, and for unrecognised qualifiers, that would be useful. I've found the current scheme quite limited, and certainly capable of producing unexpected results, so I'm definitely in favour of making some changes here. Best regards, 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: versioning
Carlos Sanchez wrote: and almost all artifacts in repo can be expressed as 4 different alphanumeric sections, so no problem there, And the ones that can't? We don't care about those? And the ones in peoples private repositories? -- 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: versioning
Kenney Westerhof wrote: Richard van der Hoff wrote: Hi, Carlos Sanchez wrote: Regarding Kenney's proposal: as discussed on #maven, all sounds very sensible to me. I'm still fishing for, and failing to find, examples of failures for projects where people invert the precedence of . and -; however anyone doing that probably deserves what they get. Still waiting.. ;) Did we discuss this one: 1.0-2.3 = 1.0-2-3, which is newer? My algorithm would say 1.0-2.3. I don't think we discussed exactly that. I think your algorithm is probably right here. However, you've now helped me find the problem I was fishing for. My imaginary project separates versions with - and build numbers with .; so I have 1-0.193 1-0.204 1-1.897 Oops! I need to release a bugfix to 1-0: 1-0-1.596 With your algorithm, we have (I think) 1-0-1.596 1-0.193, which is wrong for my (crazy) versioning system. But, as I said, I deserve what I get for doing this. There will always be some corner case we don't quite cover correctly; I don't think we should let this worry us or act as an argument against improving the status quo, provided we get most sane cases covered. We just need to make sure the exact algorithm is documented :). I don't think it would be unreasonable to expect a project's maven versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping through hoops to make this work may not be worthwhile. True. But as others suggested, when project leads are replaced, version schemes may change also. Though I think that if that's the case, then they'll probably stick to the current scheme until a final (bugfix) release has been made, so you will probably never find 1.0alpha2 = 1.0-alpha-3, but rather 1.0alpha2 = 1.1-alpha-2. I think this is a limitation we could easily impose. Agreed. Is it a given that we want SNAPSHOT alpha beta gamma rc ga ? What happens when we've released an alpha, but want to continue hacking on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and ga, no? Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an alpha or beta or rc has been released yet. I'd say: 1.0-SNAPSHOT 1.0-alpha-1-SNAPSHOT 1.0-alpha-2-SNAPSHOT ... 1.0-rc1 1.0-rc2-SNAPSHOT. Snapshots also have to be possible before the first alpha (which is pretty common to do), and if we allow SNAPSHOT's to be present everywhere (and use it as a qualifier, so: SNAPSHOT alpha SNAPSHOT beta ..), we can never compare with snapshots. SNAPSHOT is a bit special anyway... If we have alpha beta SNAPSHOT ga, then people who want a SNAPSHOT will get the last snapshot before the main release (regardless of the presence of alphas), and people who don't will get the latest non-SNAPSHOT? I don't quite understand what you mean here. From experience I'd say people start out with 1.0-SNAPSHOT, and later do 1.0-rc-1. Then before the ga is released, they don't revert back to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This produces unpredictable results. So your recommendation is, once you want to make the final release, to go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing 1.0-rc-N (and similarly for transition into alpha, beta and rc stages)? That's fine, provided it's documented :). Also, does unknown(lexical sort) '' not conflict with In my sample implementation, 2.0.1-xyz is newer than 2.0.1.? No it doesn't. The current implementation assumes 2.0.1 is newer than 2.0.1-xyz. So '' unknown(lexical sort) ? Anyway, you say this is up for debate, fine. -- 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: versioning
Carlos Sanchez wrote: the repository has some rules and you have to follow them to be manageable, eg. you name jars artifactId-version.jar and not otherwise. If there are version rules you'd have to follow, and I don't see the problem in having a standardized version convention, as we have standardized folder names. As I said before: The problem is basically that this simply isn't powerful enough to cover all the various versioning schemes there are in the wild. Suggesting forcing everybody to conform to your idea of versioning isn't at all helpful; similarly imposing a complex mapping between upstream and maven versions for a project is unattractive. Which part do you disagree with? -- 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: [m2] New pre-package phase?
Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. 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: Closing bugs [was Re: siteDirectory and site.xml]
Brett Porter wrote [and Dennis Lundberg said similar things]: Given this, I don't see any need to change the way we use the closed state or reintroduce the resolved workflow step. Hrm, yes, fair enough, you're probably right. It was just a thought... -- 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]
Closing bugs [was Re: siteDirectory and site.xml]
Dennis Lundberg wrote: Graham Leggett wrote: Dennis Lundberg wrote: [MSITE-91] There has not been any official release of the site-plugin yet, that incorporates this fix. You can build the plugin yourself from source, by downloading it from SVN. Then you just run mvn install. You alse need to bump the version number for the site-plugin in your pom to 2.0-SNAPSHOT. Is there any chance of a release soon? The bug was fixed in April/May, and it's now November :( Are there any showstoppers outstanding on this plugin? Regards, Graham The bug was fixed this weekend :) So, no it hasn't been released yet. Just my opinion here, but it seems wrong to 'close' a bug when there's no release on the horizon, because: (a) it might be closed to you, but if the fix depends on maven 2.1 it's as good as useless to real-world users. I think that you're not giving an accurate representation of the quality of the current release version (and hence the urgency of a release) by closing bugs as soon as the fix is committed to svn. (b) if I see a bug, I want to be able to search jira for it, whether it's going to be fixed in the next release or not. You need a distinction between bugs which were fixed before the current release, and those which will only be fixed in the next release. Isn't this what Status: Resolved is for? -- 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: How to ssh remote machine
Jakob Vad Nielsen wrote: Sorry that I answer you with URL's. A little busy today :) http://www.ece.uci.edu/~chou/ssh-key.html This should be on the users list anyway, no? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review javadoc plugin documentation
Maria Odea Ching wrote: Okay, will do :) Thanks.. Could you also fix your clock? It seems to be set for the wrong timezone, or something ... either way, it's about 15 hours fast. 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
Mark Donszelmann wrote: Hi in the freehep-nar-plugin (for maven 1, being ported to maven 2) we have such a solution. snip 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
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
Mark Donszelmann wrote: 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. I see. Well, this has all been very interesting - thanks Mark! It seems that we've both considered the same set of problems, and come up with slightly different solutions. I only wish I'd heard about this a month ago - I'd much rather have worked with you on the nar plugin than made my own version. I'll watch development of your plugin with interest :). 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
Hi Dan,
dan tran wrote:
Hi Richard,
The native-maven-plugin JNI example shows that you can have your native
project depends on a java jar project that has
java jni interfaces. This way you can use native plugin to generate jni
native include files before building the native artifacts.
This is the same behavior in maven1.
Not sure why it is a blocking to you since it works
The question is, how do you then arrange for another project (maybe with
more JNI, maybe not) to depend on that {native,java} project pair? It
all gets incredibly messy. And believe me, I tried.
Furthermore, what do you do about unit tests with the
native-maven-plugin? They have to run after the native artifacts are
built, obviously.
I don't mean to step on your toes by setting up an alternative to the
native-maven-plugin; it's just that the native-maven-plugin really
didn't suit my needs at all.
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
A while ago, I posted here asking for help with using Maven to handle projects which make use of JNI code. I was met by a stony wall of silence at that time... Anyway, a month later, and after quite a lot of thinking, hacking and tweaking, I've come up with a solution I'm reasonably happy with. I've written it all up at http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI, in the hope that it may be useful to others. Feedback is welcome, although bear in mind that I've spent long enough on this now that I may be reluctant to do much more work :). 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]
