Re: maven-nar-plugin (version?)
I will setup the hudson/jenkins to build and setup a small repository for new versions on the github project. Give me some days. :) However this wont perform the test cases yet (the need native build on various platforms). But as soon as possible this will solved. I think as soon as we finished merging all the branches and forks we can start to bring up new versions to maven central. Please contact me directly if you want to have configuration permissions on the hudson (those that are already comitters on the maven-nar group at github). On Fri, Jan 18, 2013 at 7:35 PM, Curtis Rueden wrote: > Hi Tim, > > > http://duns.github.com/maven-nar-plugin/ > > That is the old site, and it is up to Mark whether he has time to update > it. (Mark, if you do have time, it would solve a lot of confusion to update > some of the information in your GitHub space, since there are still an > overwhelming number of links to duns.github.com as the definitive > maven-nar-plugin site.) > > > FYI, I subscribed to the google mailing list. Certainly don't mind > > assisting in the project. > > Great, thanks! > > Regards, > Curtis > > > On Thu, Jan 17, 2013 at 9:02 PM, Tim Astle wrote: > > > Thanks for the clarification. > > > > I posted to this mailing list because that's what is listed on the > > maven-nar-plugin site. > > http://duns.github.com/maven-**nar-plugin/mail-lists.html< > http://duns.github.com/maven-nar-plugin/mail-lists.html> > > > > Can that be updated as well? > > > > Is this the correct issue tracker: http://duns.github.com/maven-** > > nar-plugin/mail-lists.html< > http://duns.github.com/maven-nar-plugin/mail-lists.html> > > > > FYI, I subscribed to the google mailing list. Certainly don't mind > > assisting in the project. > > > > Tim > > > > > > > > On 1/16/2013 4:17 PM, Curtis Rueden wrote: > > > >> Hi all, > >> > >> We are still unifying the various forks of maven-nar-plugin, so there is > >> no > >> new official release version yet. > >> > >> The maven-nar mailing list is at: > >> https://groups.google.com/**forum/?fromgroups#!forum/**maven-nar< > https://groups.google.com/forum/?fromgroups#!forum/maven-nar> > >> > >> It seems that all of the involved people are very busy, so progress is > >> rather slow. We welcome any additional help! > >> > >> To avoid confusion, I updated the project readme (at > >> https://github.com/maven-nar/**maven-nar-plugin< > https://github.com/maven-nar/maven-nar-plugin>) > >> to reflect the current > >> project status and links, including a link to the mailing list. > >> > >> Regards, > >> Curtis > >> > >> > >> On Wed, Jan 16, 2013 at 8:53 AM, Mark Donszelmann < > >> mark.donszelm...@gmail.com> wrote: > >> > >> Hi > >>> > >>> I wrote the NAR plugin, but have no longer time to maintain it. > >>> > >>> I donated it (with approval of Sonatype) to a bunch of people who would > >>> like to maintain it. > >>> > >>> Its under > >>> > >>> https://github.com/maven-nar > >>> > >>> I guess with mailing lists and doc > >>> > >>> Regards > >>> Mark Donszelmann (duns) > >>> On Jan 16, 2013, at 3:44 PM, Wayne Fay wrote: > >>> > >>> Nar is not a product of the Maven PMC, and so will never be an > >> official org.apache.maven.plugin anything. > >> > > Right, but whose product is it today and how do we find the latest > > official release? > > > The groupId suggests that would be codeswarm.org. But there may be > other parties who have their own branches etc. > > Wayne > > --**--** > - > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > > > >>> --**--** > >>> - > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > >>> > > > > --**--**- > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: Maven 3 does not manage to deploy nar artifact on Linux
To explain it. We are currently merging several forks at github. So you are welcome to contribute your customizations there :) On Wed, Nov 14, 2012 at 2:07 PM, Eyal Goren wrote: > Hi, > > Problem resolved- I forgot to tell it to use the profile for Linux, and the > definitions of the nar plugin were in the profile. > > I used the most updated code (I think it was 2.0-SNAPSHOT). any how- I took > the most updated code. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-3-does-not-manage-to-deploy-nar-artifact-on-Linux-tp5730943p5730959.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven 3 does not manage to deploy nar artifact on Linux
And which maven-nar-plugin do you use? There are many forks around. We are currently merging them at github (http://github.com/maven-nar). The merged one that is also working with maven3 is not yet present in maven central. I do not know if some early version is working with maven3. On Wed, Nov 14, 2012 at 12:27 PM, Eyal Goren wrote: > Also- I am using maven 3.0.3 > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-3-does-not-manage-to-deploy-nar-artifact-on-Linux-tp5730943p5730946.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven 3 does not manage to deploy nar artifact on Linux
Which version of maven-nar-plugin are you using? On Wed, Nov 14, 2012 at 12:19 PM, Eyal Goren wrote: > One line was not written well- > > [ERROR] Unknown packaging: nar @ line 14, column 14 > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Maven-3-does-not-manage-to-deploy-nar-artifact-on-Linux-tp5730943p5730944.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Unifying maven-nar-plugin implementations
> > > Also, rather than migrating a fork directly, perhaps (if Mark agrees) we > could migrate the @duns repo, then push all of Greg's changes back on top? > That way, existing GitHub forks will all state "forked from > maven-nar/maven-nar-plugin" afterward, which would be ideal. And to > preserve old links Mark could fork it back into @duns again and update the > README to state what happened. Thoughts? > > Sounds like a good plan. However I did not compare the forks so I do not have an idea how many work has to be done. But I will have a look in the next days. > Presumably we would also want to similarly migrate cpptasks-parallel? > > I think so. It isn't maintained too (correct me if I am wrong). > > > Technical features can be discussed in the github wiki at the moment. > > Martin, shall we create a mailing list for the project? Perhaps a Google > group? Then we can migrate this discussion there instead. > > Feel free to create it an invite the people :) > > Regarding cross-compilation: I know it is of interest (wouldn't it be > great to build for multiple target platforms all from the CloudBees Jenkins > on Linux?). My colleague has done quite a lot of work in that area, but > there are some substantial obstacles. Shall we discuss further on our shiny > new maven-nar-plugin mailing list, once it exists? > > Yeah, we should discuss it in a working group with experience on this topic. Setting up cross compilation and having a maven-nar-plugin supporting it is not that easy.
Re: Unifying maven-nar-plugin implementations
> > > My employers (CloudBees) will give free jenkins instance to any Open Source > project that asks for one. > Thanks for your support. Is your jenkins aware of native builds for win, linux, sunosx, macosx and aware of doing cross-compiles? However please let us talk directly. Maybe we need more than one jenkins to ensure the tests will work on various platforms.
Re: Unifying maven-nar-plugin implementations
OK. Thanks four your responses, Mark and Jason. Lets sum up. We have the agreement of the authors to build up a new "working group". I recently created a new organization at github: https://github.com/maven-nar (just to give this a kickstart) Please tell me who wants to become a project owner. I have added the three active fork users (richardkerr, grogdomjahn and 1spatial). I suggest to now vote on one fork to be moved to the organization and merging all the pull requests, solving issues etc. Unperiodical users can always create pull requests on the project. New regular users are welcome :) Technical features can be discussed in the github wiki at the moment. I will create website and other things too, the website and repository can be hosted by github. After doing this homework with merging all the forks we can discuss the future of this project. As long as there is no organization selected I will use my jenkins to push the website to a github repository. > That said if you were going to take it to a foundation, in the long run I > would take it to the Eclipse Foundation. They have just converted the whole > platform build to Maven and there is a large native component to that for > SWT and the launchers. Redhat has done a lot of the work there lately and > I'm sure they would be interested as they do their own builds of the > Eclipse Platform for their users and customers. > > I happy to talk any of the groups as Sonatype would have to make a > donation of code to move it to a foundation, but honestly I really think > Github is the best place for you to spark up the project again. > I do not preferr any of the codehaus, mavens core or eclipse foundation. All three solutions are fine for me as well as having a lonesome project group using github and publishing to maven central. For eclipse: This should be discussed with an eclipse foundation guru and with an eclipse cdt guru. As soon as we are ready with the project team and voted for an active project lead I would be happy to contact them. I am already involved in eclipse pdt (commiting patches) and already had some contact to some of the gurus.
Re: Unifying maven-nar-plugin implementations
Do we actually need the agreement of all authors to become a maven core project? The sources are already licensed under terms of ASF. The original authors seem not respond for months or the email addresses are no longer valid. Would it be fine if there is a new (active) project group filling up the CLA? http://www.apache.org/licenses/#clas Actually duns code is not the original code. There was some other author (freehep). For me personally I do not care if this is becoming a maven-ocre component or not. I am fine with codehaus and other variants too. My personal interest is to remove all the forks and having an active project roup I can discuss and commit my work :) On Sun, Oct 7, 2012 at 12:23 PM, Jörg Schaible wrote: > Hi, > > Benson Margulies wrote: > > > Adding plugins to the core is not so much a matter of 'strategy'. > > > > The nar plugin is a non-trivial amount of code. So, for it to come to > > Apache, it would have to pass IP clearance. That means understanding > > the provenance of all of the code and that the people contributing it > > have sufficient rights to grant a license to the ASF. > > > > That having been said, the existing Maven community is rather thinly > > spread across the many org.apache.maven.plugins. Adding another big, > > complex, plugin should, at least, lead to a pause for reflection. > > Nonetheless, If the authors are interested in contributing it, please > > join the dev list and start a discussion. > > another option is mojo.codehaus.org, especially since the devs discuss > about > moving the SCM for individual plugins to git. > > - Jörg > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Unifying maven-nar-plugin implementations
Hi. However the first topic is to group a team that will be well active and that will be adoting all forks. I suggest to choose one github project and declare it to be the new main project. One fork by one should be merged and than deleted. Maybe we should choose richards or gregs project (that one that is the most recent) and create a wiki. Within the wiki we should dicuss some things because we all have experiences and want to customize maven-nar-plugin. Deploying to maven central or even becoming a core plugin could be the second topic after having an established project group. Let us say we have to do some homework. :) Greg, Richard? Fine for you to choose one of your forks being the "official" one? So I suggest to sum up the topics for our homeworks. However I do not know the current merge status. But I would like to work on the following three topics: 1) multiple compiles on one invocation (f.e. win-32 plus win-64) 2) cross compilation with gcc 3) adding new platforms after already having a release. Greetings On Fri, Oct 5, 2012 at 6:09 PM, Curtis Rueden wrote: > Greetings maven-nar-plugin hackers! > > I am writing to gauge interest in a unified implementation of > maven-nar-plugin. It seems there are several active (and not-so-active) > forks. It seems the original implementation (@duns) is no longer active, > but both @GregDomjan and @richardkerr have active forks (the latter forked > from the former), and merge improvements from other forks too. > > Before we were aware of this, my colleague (Johannes Schindelin) & I > started another fork (@scijava) to address some issues we had. which have > since been merged into the @GregDomjan fork (although I could not find a > cherry-picked commit... it must have been done in some non-standard way?). > > I would be happy to deprecate the @scijava fork in favor of the > @GregDomjan code, if we can agree to standardize on one officially > maintained repository. If we do go that route, it should not be too > difficult to start releasing versions to Maven Central. Can all agree to > start submitting PRs to Greg for any future patches, rather than silently > maintaining our own forks? Greg, what do you think? Others? > > Apache/Sonatype/Codehaus developers: It appears that there was once a push > for Apache to adopt maven-nar-plugin as a core plugin. Is that effort > abandoned now? Is a unified GitHub project the best way forward for > maven-nar-plugin? Or would it make more sense for one of the big Maven > umbrella groups to adopt it instead? > > Thanks, > Curtis > > > On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt < > martin.eisenga...@gmail.com> wrote: > >> The author (@duns) seems to be not actve any more. However I failed >> contacting him for a while. >> >> https://github.com/GregDomjan/maven-nar-plugin >> And there is a second one being active: >> https://github.com/richardkerr/maven-nar-plugin (do not know how to >> contact this guy) >> >> However both try to merge the forks being around. And they like any kind >> of help. If there are some people around that want to give it a new try >> that would be nice. >> I guess the original plugin was some kind of sandbox @ sonatype. I do not >> know if we should simply group up some people that officially will maintain >> it and I do not know if even sonatype or others are interested. >> >> However for being pragmatic I would say to choose one of the active >> forks, grouping a new team and granting commit rights to the people that >> want to maintain it. >> I am able to provide both, a repository and a hudson as long as this is >> not moved to maven central. >> >> However I am personally focused on compiling php/php-extensions and using >> maven-nar-plugin to access them with maven. Multi-Platform compiles/ >> Cross-Platform compiles >> I will come back to the project as soon as our build server knows how to >> do cross compiles for various platforms. >> >> >> On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden wrote: >> >>> Hi Martin, >>> >>> >>>> There is a problem with the [maven-nar-plugin] project because there >>>> are tens of orks on github. If you have any questions about it please ask. >>>> I have contact to one of the ative authors and we try to merge all the >>>> forks. >>> >>> >>> I am guilty of one of those forks. We submitted a PR ( >>> https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, >>> so we had no choice. >>> >>> It looks like the canonical version at duns/maven-nar-plugin has not >>> been updated for nearly two years. Is that going to change? It would be >>> great for this very valuable plugin to be maintained! >>> >>> Thanks, >>> Curtis >>> >> >
Re: maven-nar-plugin status [was: Re: JNI jars dependencies]
The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden wrote: > Hi Martin, > > >> There is a problem with the [maven-nar-plugin] project because there are >> tens of orks on github. If you have any questions about it please ask. I >> have contact to one of the ative authors and we try to merge all the forks. > > > I am guilty of one of those forks. We submitted a PR ( > https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so > we had no choice. > > It looks like the canonical version at duns/maven-nar-plugin has not been > updated for nearly two years. Is that going to change? It would be great > for this very valuable plugin to be maintained! > > Thanks, > Curtis > > > On Fri, Sep 14, 2012 at 8:26 AM, Martin Eisengardt < > martin.eisenga...@gmail.com> wrote: > >> Ask google about maven-nar-plugin. >> >> It introduces nar dependencies (nar) and internally tries to >> find out the correct qualifier depending on the current >> machine/architecture. >> >> I am playing around with it because I have a similar situation. There is a >> problem with the project because there are tens of orks on github. If you >> have any questions about it please ask. I have contact to one of the ative >> authors and we try to merge all the forks. >> >> On Fri, Sep 14, 2012 at 3:13 PM, Simone Tripodi > >wrote: >> >> > Hi all guys, >> > >> > I have the task of managing a 3rd party forest of dependencies which >> > contain JNI code, so let's immagine that the provided library >> > directory tree is as shown below: >> > >> > linux-i386 >> > ├── a.jar >> > ├── b.jar (depends from a.jar) >> > └── c.jar (depends from a.jar and b.jar) >> > >> > linux-x86_64 >> > ├── a.jar >> > ├── b.jar (depends from a.jar) >> > └── c.jar (depends from a.jar and b.jar) >> > >> > mac-x86_64 >> > ├── a.jar >> > ├── b.jar (depends from a.jar) >> > └── c.jar (depends from a.jar and b.jar) >> > >> > I was going to put all that jar in my Nexus installation, when I just >> > realized I need classifiers to manage each platform... While manage a >> > single dependency would be really easy, managing transitive >> > dependencies per platform is not trivial, should be profiled... >> > >> > Do you have any suggestion on how that situation could be handled? >> > >> > Many thanks in advance, all the best! >> > -Simo >> > >> > http://people.apache.org/~simonetripodi/ >> > http://simonetripodi.livejournal.com/ >> > http://twitter.com/simonetripodi >> > http://www.99soft.org/ >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> > >
Re: JNI jars dependencies
Ask google about maven-nar-plugin. It introduces nar dependencies (nar) and internally tries to find out the correct qualifier depending on the current machine/architecture. I am playing around with it because I have a similar situation. There is a problem with the project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. On Fri, Sep 14, 2012 at 3:13 PM, Simone Tripodi wrote: > Hi all guys, > > I have the task of managing a 3rd party forest of dependencies which > contain JNI code, so let's immagine that the provided library > directory tree is as shown below: > > linux-i386 > ├── a.jar > ├── b.jar (depends from a.jar) > └── c.jar (depends from a.jar and b.jar) > > linux-x86_64 > ├── a.jar > ├── b.jar (depends from a.jar) > └── c.jar (depends from a.jar and b.jar) > > mac-x86_64 > ├── a.jar > ├── b.jar (depends from a.jar) > └── c.jar (depends from a.jar and b.jar) > > I was going to put all that jar in my Nexus installation, when I just > realized I need classifiers to manage each platform... While manage a > single dependency would be really easy, managing transitive > dependencies per platform is not trivial, should be profiled... > > Do you have any suggestion on how that situation could be handled? > > Many thanks in advance, all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Inherit parent version?
Yes. You need it. And this is not a bug so there is nothing to fix. On Sat, Aug 18, 2012 at 2:41 PM, Billy Newman wrote: > No, by fixed I mean do you need to include the version in the parent tag? > > Sent from my iPhone > >
Re: Inherit parent version?
IMHO this solution is very bad because of one reason: It influences already released versions. IMHO mavens "deploy" goal does not put the correct resolved version into the parent tag. Thus all versions you ever deploy will resolut in corrupt poms because they lead to newer parent poms as soon as there is a new release an thus receive a newer version name on themselves. following scenario: Parent V1.0.0 --> Child V1.0.0 resolves to parent 1.0.0 and uses version 1.0.0 for itself Parent V1.0.1 --> Child V1.0.1 resolves to parent 1.0.1 and uses version 1.0.1 for itself But what happens to original V1.0.0 as soon as the V1.0.1 parent is present in any repository? It will resolv V1.0.1 because this is the newest. And know you have to childs, both of them telling you that they are V1.0.1. No thats really bad. Maybe I am wrong and deploy-goal does more I am knowing of :)
Re: Inherit parent version?
No, it is not possible. This is henn-egg-problem. The first thing maven does is: resolve the parent pom. So in the parent section there is neither a way to comment out the version number nor a way to use properties.
Re: MavenProject/MavenSession not injected when executing plugin from a plugin
> > > > As I understood from Martin Eisengardt this has to with the fact that the > PlexusContainer does not have maven related information since Maven 3. > > Right now I'm looking into the source code of Maven to see how plugins are > executed. > > > Actually some plugins are aware of this. For example maven-site-plugin generates other mojos to execute the reportings. And thus it should use some other method to receive mojo objects. Something that is not the plexus container.
Re: MavenProject/MavenSession not injected when executing plugin from a plugin
I noticed this too. The main reason is the plexus container does not know anything about the maven sessions. Maven sessions and other things are no valid plexus components (in the meaning they do not prefer to be a singleton). However the current solution for me was to have some little wrapper that is able to inject maven session on request. The magic happens in org.apache.maven.plugin.PluginParameterExpressionEvaluator. Whenever receiving an object from plexus that requires maven session and others you should not try to receive it via @required/@Requirement directly. Instead access the plexus container and use this expression evaluator. It does everything that is normally injected to mojos and their requirements only. See https://github.com/php-maven/maven-php-plugin/blob/master/branches/2.0-SNAPSHOT/maven-php-core/src/main/java/org/phpmaven/core/ComponentFactory.java#L175 for an example. Whatever you are doing there may be other solutions. Maven itself has some utilities to receive a plugin in the correct way. The above scenario is only related with scenarios you mix up with "the maven way" and "the plexus way". And maybe I was totally wrong to write this utility :) However if there is need it is possible to merge my configurationfactory utility class to a more common maven project and push it to central. On Wed, Aug 15, 2012 at 7:31 AM, Kinai User wrote: > Hi Martin, > > Plugin A has several executions defined with different configurations. > Here's an example of such a configuration (from the -part): > > > aspectJ-weaving-execution > compile > > executePlugin > > > > aspectJ-weaving > > > jar > war > ejb > > > > doAspectJWeaving > true > > > > > > Plugin A will check the current project to see whether it is of > pomPackaging > type jar/war or ejb or if the project contains the property > doAspectJWeaving > with the value true. If one of these conditions is met plugin A decides to > execute the aspectJ-weaving. > > Here's the configuration for the pluginExecution = aspectJ-weaving from the > -part: > > > org.codehaus.mojo > aspectj-maven-plugin > 1.4 > > 1.5 > true > true > false > > > org.springframework > spring-aspects > > > > > > *aspectJ-weaving* > > compile > > > > > > However plugin B needs access to the MavenProject or MavenSession instance > to retrieve some maven info but since these dependencies are not injected a > NullPointerException (or if @required was defined a missing parameter) will > be thrown. > > Beware that I used an example for Plugin B which is an existing plugin > where > we do not have the sources of. But this also holds for plugin that we > created ourselves. > > Any help appreciated. > > Regards, > Richard > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/MavenProject-MavenSession-not-injected-when-executing-plugin-from-a-plugin-tp5716570p5717095.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: pom
Either install an eclipse plugin that is aware how to handle it or use the eclipse quickfix. The quickfix will add some build plugin configuration that tells eclipse what to do. You should choose action "execute" to simply execute the goal. Or ignore to let eclipse silently drop it (and invoke it only manually from command line). See http://wiki.eclipse.org/M2E_plugin_execution_not_covered for detail. On Mon, Aug 13, 2012 at 11:13 AM, redsdh wrote: > ** > Hi, > > I import a maven project with the pom file which is included in > attach. eclipse report this error : > > Plugin execution not covered by lifecycle configuration: > org.mule.tools:maven-mule-plugin:1.7:attach-test-resources (execution: > default-attach-test-resources, phase: validate) > > > Plugin execution not covered by lifecycle configuration: > org.mule.tools:maven-mule-plugin:1.7:filter-resources (execution: > default-filter-resources, phase: process-resources) > > > Please tell how to resolve it . Thank you ! > > Best regards ! > > -- > > lake shen > red...@gmail.com > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: Is Maven only for Java?
On Stackoverflow there is a small list: http://stackoverflow.com/questions/1168960/maven-for-other-languages Maybe incomplete. And maybe some support is not as you need it. However it should be better to start with a whitelist or features/languages and not declaring "all languages" and "all operating systems". Anyhow there are several exotic or old languages, for example I do not know of any cobol plugin. But maybe you won't ever need cobol support. On Mon, Jul 9, 2012 at 5:55 PM, hujirong wrote: > Hi > > I am about to start a new project to setup enterprise SCM for all open > systems, Windows, Unix, etc, in all languages, not only Java. We use IBM > Rational ClearCase, ClearQuest and BuildForge. > > I am wondering if I can introduce Maven. > > Thanks > Jirong > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Is-Maven-only-for-Java-tp5713445.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How does Maven download the latest snapshot from Nexus?
The magic is inside maven-metadata.xml that will be generated while uploading.
Re: How to set src-folder correctly
I am using php and I am one of the developers of php-maven.org. As this is the only php to maven project I found I don't think someone solved it (for php). The source folders should be src/main/php and src/test/php. Packaging is "php" introduced by our maven extension. The only php extension I found is using packaging "pom" and introduces some ant scripts. That's not what I want since I could use ant directly So I decided to support the php-maven community as developer. The other languages I tried to search for either use the corresponding entries in the pom.xml or they need to declare the source folder in a parent pom. I do understand if this is the recommended way. And we will recommend it if this is the only way you can manipulate the source folders. But maybe there is another way we could use so that the users of php-maven do not need to specifiy the source folders in their poms. IMHO the packaging "pom" should be enough for maven to load some defaults on the project. Maybe you know another language that introduces their source folders without need of inherit a parent pom or without the need to manually specify it in the projects pom? I did not find any. Currently we are introducing a small goal: https://github.com/php-maven/maven-php-plugin/blob/maven3/src/main/java/org/phpmaven/plugin/build/SetSources.java It is executed very early and hopefully it will be executed for every common phase: https://github.com/php-maven/maven-php-plugin/blob/maven3/src/main/resources/META-INF/plexus/components.xml[https://github.com/php-maven/maven-php-plugin/blob/maven3/src/main/resources/META-INF/plexus/components.xml] However it works but feels some kind of "bad hacking". -Ursprüngliche Nachricht- Von: "Ron Wheeler" Gesendet: 08.11.2011 15:42:40 An: users@maven.apache.org Betreff: Re: How to set src-folder correctly "not using java" is not too much help. What language are you using? What are you trying to build. Perhaps you will find that your problem is already solved for your language of choice. It is always better to state you problem in the context of what you are trying to do. We waste lots of time in this forum and delay the resolution of problems because the original problem is stated very narrowly and the solution is very simple but at a higher level. If you explain what you are trying to build, you might get a better answer - plug-in for that language, assembly plug-in to build an archive file from pre-compiled code and configuration files. If you are doing it, chances are many others are already using Maven to build it. Ron On 08/11/2011 5:20 AM, Martin Eisengardt wrote: > Hi. > > I was adviced to send this to the users mailing list and not the dev mailing > lists. However I got an answer. > > --- original question --- > > We are using maven for own project types. However the source folders > (src/main/java and src/test/java) are not the same since we are not using > java. To let some plugins work correctly we need to ovrwrite them with the > correct folders. > > For know we created a small goal that will be executed early. It will > overwrite the source folders directly. It works but I don't feel it is the > correct way. Do you recommend another way, for example some hint in > components.xml I did not see yet? How do we tell maven that the source > folders for our own packaging are not the java ones? > > If having an early goal setting the source folders programtically, what goal > should we choose? The "validate" goal is the first one and so the best one to > set the new source folders but it is focused of "validation" of the project > and not focused on "hack project pom to fit the best needs". > > --- answer from wayne fay --- > > What you are requesting is trivially accomplished via various entries in > your pom.xml files. This is documented on the Maven website. Ideally you > would have a single top parent pom that all your projects inherit from, and > set the proper values there (in the top parent). > > --- my remarks --- > > I hoped that we do not need all of the plugin users to rely on a parent-pom > we are serving. In other word: I hoped to find a way other than using the > pom.xml in every project. Is there no way saying "packaging xxx uses > different source folders", f.e. in components.xml? All I am seeing is that > maven hard-coded the java related super pom as a mixin. But the super pom > should be customized or another mixin should be automatically added in our > use case. > The uses of our plugin already have to add it to the build plugin lists to > activate the packaging. But thats really fair and ok. > > Of course redeclaring in pom will work. > > > Greetings > Martin > &g
How to set src-folder correctly
Hi. I was adviced to send this to the users mailing list and not the dev mailing lists. However I got an answer. --- original question --- We are using maven for own project types. However the source folders (src/main/java and src/test/java) are not the same since we are not using java. To let some plugins work correctly we need to ovrwrite them with the correct folders. For know we created a small goal that will be executed early. It will overwrite the source folders directly. It works but I don't feel it is the correct way. Do you recommend another way, for example some hint in components.xml I did not see yet? How do we tell maven that the source folders for our own packaging are not the java ones? If having an early goal setting the source folders programtically, what goal should we choose? The "validate" goal is the first one and so the best one to set the new source folders but it is focused of "validation" of the project and not focused on "hack project pom to fit the best needs". --- answer from wayne fay --- What you are requesting is trivially accomplished via various entries in your pom.xml files. This is documented on the Maven website. Ideally you would have a single top parent pom that all your projects inherit from, and set the proper values there (in the top parent). --- my remarks --- I hoped that we do not need all of the plugin users to rely on a parent-pom we are serving. In other word: I hoped to find a way other than using the pom.xml in every project. Is there no way saying "packaging xxx uses different source folders", f.e. in components.xml? All I am seeing is that maven hard-coded the java related super pom as a mixin. But the super pom should be customized or another mixin should be automatically added in our use case. The uses of our plugin already have to add it to the build plugin lists to activate the packaging. But thats really fair and ok. Of course redeclaring in pom will work. Greetings Martin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
