Re: AW: Re: AW: Re: RE : AW: RE: AW: Re: AW: Re: Maven for Non-Java Projects
Hi Mark, Donszelmann Mark wrote at Dienstag, 18. August 2009 13:53: [snip] >> However, I >> cannot remember currently what that was and JIRA for the plugin >> seems no >> longer available. > > it is under: > > http://bugs.freehep.org/browse/NARPLUGIN Thanks, pointer at http://java.freehep.org/freehep-nar-plugin/issue-tracking.html links to nowhere ;-) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Re: AW: Re: RE : AW: RE: AW: Re: AW: Re: Maven for Non-Java Projects
Hi Jan, all answers below of the top of my head and without looking into the code... so no guarantees: On Aug 18, 2009, at 10:08 AM, Jan Wedel wrote: Hi Mark! It's good to hear something from the original "source" of the plug- in. I am currently evaluating whether we are using maven for C projects or not. I tried your plug-in by using the helloworldexe project and immediately got a "build failure" ([INFO] NAR: Please specify as part of , or for x86.Windows.gcc.cpp.). I know I changed the POM to gcc but it should also compile well. I am afraid changing compilers is not very well tested. It is something that one should be able to do, as long as the compiler is in the list. No matter if you can help me with this issue or not, I can tell you some requirements for my company of which I am not sure if NAR already supports it or not and which you might implement if the latter is the case. sure. We want to build C project with embedded compilers such as gcc or IAR. The output could be a intel-hex file, e.g. or other microcontroller specific formats. We need to specify different compile settings for release, debug, test and factory-test e.g. That means using cpptest for test and specifying precompiler defines by using the pom configuration, if possible (e.g. USE_UART, USE_DISPLAY etc.). As part of the lifecycle, it would be nice if the "deployment" could mean to upload the binary to a microcontroller (which would be just a parametrizable call to an executable). cross compilation is not standard possible, but should be an option in the future. Having different settings, release, debug has crossed my mind but we never really got that far. It should be a requirement. Deploying is done by the standard deploy plugin. One should be able to replace that one by something that calls an executable. I am not sure one can just replace it, some maven specialist may know. In nar there is currently not such a provision, but maybe there should be. Maybe, you could give some comments or advises if its already possible or if it can be achieved by just changing configuration file etc. Regards Mark Thanks, Jan -Ursprüngliche Nachricht- Von: Donszelmann Mark [mailto:mark.donszelm...@gmail.com] Gesendet: Dienstag, 18. August 2009 09:44 An: Maven Users List Betreff: Re: AW: Re: RE : AW: RE: AW: Re: AW: Re: Maven for Non-Java Projects Hi I am the original author of the freehep-nar-plugin. It was made at SLAC, Stanford Linear Accelerator Center, when I worked there. In my current job, which terminates on september 15, I hade no time to support this and the other Native code related plugins. I am planning to pick things up again middle of september. I would be interested in your lists of things that fail to work with NAR, though I can think of a few myself. Any patches you have created can be applied if they work fine for NAR. I plan to build some good test cases, and some better examples so that things run out of the box. Let me know Regards Mark Donszelmann - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org PGP.sig Description: This is a digitally signed message part
Re: AW: Re: AW: Re: RE : AW: RE: AW: Re: AW: Re: Maven for Non-Java Projects
Hi On Aug 18, 2009, at 10:29 AM, Jörg Schaible wrote: Jan Wedel wrote at Dienstag, 18. August 2009 09:40: So, you just have to include the DUMMY part, but the resulting file name does not include it? Actually it does, but it's the name of the library type: jni, shared or static. So your repo will contain in the end: com/acme/demo/1.0/demo-dll-1.0.pom com/acme/demo/1.0/demo-dll-1.0-x86-Windows-msvc-shared.pom I cannot remember exactly what was the problem using the real name of the part, but the nar:unpack simply needs this 4th part. IIRC according the docs you should only specify the AOL part as classifier, but it fails then. Anyhow, as you have some experience in studying the code, what would you say how difficult is it to include a new compiler that is not currently supported by the nar? I read that NAR is using the ant cpptasks for calling the native compilers. Is it just adding a new xml entry somewhere or do I have to modify the plugin itself? Well, when I looked into the code it was some older release of the plugin (2.0-alpha-7). In the later versions the compiler support has been completely refactored, so I cannot say much anymore. We're actually using a private version 2.0-beta-10 with the patch of NARPLUGIN-171. However, I cannot remember currently what that was and JIRA for the plugin seems no longer available. it is under: http://bugs.freehep.org/browse/NARPLUGIN Greetings Mark - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org PGP.sig Description: This is a digitally signed message part
Re: AW: Re: AW: Re: RE : AW: RE: AW: Re: AW: Re: Maven for Non-Java Projects
Jan Wedel wrote at Dienstag, 18. August 2009 09:40: > So, you just have to include the DUMMY part, but the resulting file name > does not include it? Actually it does, but it's the name of the library type: jni, shared or static. So your repo will contain in the end: com/acme/demo/1.0/demo-dll-1.0.pom com/acme/demo/1.0/demo-dll-1.0-x86-Windows-msvc-shared.pom I cannot remember exactly what was the problem using the real name of the part, but the nar:unpack simply needs this 4th part. IIRC according the docs you should only specify the AOL part as classifier, but it fails then. > Anyhow, as you have some experience in studying the code, what would you > say how difficult is it to include a new compiler that is not currently > supported by the nar? I read that NAR is using the ant cpptasks for > calling the native compilers. Is it just adding a new xml entry > somewhere or do I have to modify the plugin itself? Well, when I looked into the code it was some older release of the plugin (2.0-alpha-7). In the later versions the compiler support has been completely refactored, so I cannot say much anymore. We're actually using a private version 2.0-beta-10 with the patch of NARPLUGIN-171. However, I cannot remember currently what that was and JIRA for the plugin seems no longer available. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
