Re: Use native tar to unpack? good/bad idea?
I think that generally code reuse is a good idea. ;-) In this case the code even stays within the Apache family, so if anyone cares about my humble opinion, I think it makes sense. As for testing, I think Jason lately talked about Maven's integration test bed. Maybe it makes sense to add an appropriate number of cases to that, if necessary. -- Alexander Kriegisch Am 03.06.2014 um 07:53 schrieb Kristian Rosenvold kristian.rosenv...@gmail.com: I know I have a couple of branches that at least convert all the plexus-archiver zip stuff to use commons-compress, which is reasonably simple to plug into plexus-archiver. I have been a bit reluctant to push these changes since I've been mildly concerned about fallout. I think it should be fairly simple to convert the remaining plexus-archiver code to use commons-compress too, including the tar stuff. I am more concerned about the testing aspect of this change, it would require extensive testing and probably some community effort. Is there any interest in this ? Commons-compress is at least maintained; which is a Good Thing ;) Kristian 2014-06-03 6:20 GMT+02:00 Dan Tran dant...@gmail.com: Looks like it is worth a try to get maven-dependency-plugin having an option to use native tar during unpack. Thanks Jason -Dan On Mon, Jun 2, 2014 at 6:32 PM, Jason van Zyl ja...@takari.io wrote: I have had many problems with Java-based TAR solutions. I often use this where I can: https://github.com/airlift/airship/blob/master/airship-shared/src/main/java/io/airlift/airship/shared/FileUtils.java On Jun 2, 2014, at 7:15 PM, Dan Tran dant...@gmail.com wrote: BTW, I never have good luck with plexus-archiver, and always ended up to implement my own 'unpack' using native tar to speed up the build and also reserve the softlinks in the archive. So am asking the user list to see if there any interests in this feature to give enough incentive to implement it Thanks -D On Mon, Jun 2, 2014 at 4:08 PM, Dan Tran dant...@gmail.com wrote: Hi Alex, I will find a good sample file for you. Thanks -D On Mon, Jun 2, 2014 at 3:57 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Oh, I see, multiple options. Okay, then yes - maintenance nightmare. I think we should not easily give up Java's idea of platform independence and Maven's whole point: creating standardised, repeatable builds. If your idea is a reaction on your latest tar.gz problems, maybe we can find another solution for it. You have not reacted on my offer to inspect your files and see if I have an idea how to fix that in Java. :-) -- Alexander Kriegisch Am 03.06.2014 um 00:48 schrieb Dan Tran dant...@gmail.com: correct, I would expect user to install tar.exe or cygwin with tar on windows and activate the option. By default, it still uses plexus-archiver to unpack -D On Mon, Jun 2, 2014 at 3:42 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Windows does not have tar by default. You need to install Git (incl. Git Bash), Cygwin, GnuWin32 or similar. I would not expect any user to have tar installed at all or if so then in any predictable location or even reachable via PATH. -- Alexander Kriegisch Am 03.06.2014 um 00:36 schrieb Dan Tran dant...@gmail.com: I am think of enhancing maven-dependency-plugin by adding option to unpack 'tar' like artifact using native tar since it is faster and reserve soft links (?) Thoughts? would it be a maintaining night mare?? Thanks -Dan - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe - 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
Re: question about sharing assembly descriptor
Create a third modul with just the assembly descriptor: http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html /Anders On Mon, Jun 2, 2014 at 11:16 PM, Mingliang Qi qmlm...@gmail.com wrote: Hello *, I have a problem when using the sharing assembly descriptors. Let’s say i have a directory structure loos like: module-A +-- src | `-- main | `-- resources | `-- assemblies | `-- myassembly.xml `— pom.xml module-B `—pom.xml module-B’s pom.xml wants to use the descriptor in module-A, which could be done by adding module-A as a dependency on the assembly plugin then use the descriptorRefs. But the problem is I already has module B as a dependency in module-A. so this will lead to a cyclic reference. If i do without the dependency and just use the descriptor directly will also lead to wrong base directory for the descriptor.(the base directory for myassembly.xml will be module-B) How can i use the shared assembly descriptor in this case properly? Best, Mingliang
Re: Use native tar to unpack? good/bad idea?
I filed an Jira at https://jira.codehaus.org/browse/MDEP-447 . Let's see how much interests it can gather -D On Mon, Jun 2, 2014 at 10:40 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: I disagree, even though I could live with it. How about putting the effort in improving the Java implementation if something is wrong with symlink extraction? And BTW, your archives in this case (see other thread) just had the wrong extension because you packed them without the z option, which is a simple user mistake. I can also create an Excel file and rename it to myfile.txt, which does not make it readable in a normal text editor. ;-) -- Alexander Kriegisch Am 03.06.2014 um 06:20 schrieb Dan Tran dant...@gmail.com: Looks like it is worth a try to get maven-dependency-plugin having an option to use native tar during unpack. Thanks Jason -Dan On Mon, Jun 2, 2014 at 6:32 PM, Jason van Zyl ja...@takari.io wrote: I have had many problems with Java-based TAR solutions. I often use this where I can: https://github.com/airlift/airship/blob/master/airship-shared/src/main/java/io/airlift/airship/shared/FileUtils.java On Jun 2, 2014, at 7:15 PM, Dan Tran dant...@gmail.com wrote: BTW, I never have good luck with plexus-archiver, and always ended up to implement my own 'unpack' using native tar to speed up the build and also reserve the softlinks in the archive. So am asking the user list to see if there any interests in this feature to give enough incentive to implement it Thanks -D On Mon, Jun 2, 2014 at 4:08 PM, Dan Tran dant...@gmail.com wrote: Hi Alex, I will find a good sample file for you. Thanks -D On Mon, Jun 2, 2014 at 3:57 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Oh, I see, multiple options. Okay, then yes - maintenance nightmare. I think we should not easily give up Java's idea of platform independence and Maven's whole point: creating standardised, repeatable builds. If your idea is a reaction on your latest tar.gz problems, maybe we can find another solution for it. You have not reacted on my offer to inspect your files and see if I have an idea how to fix that in Java. :-) -- Alexander Kriegisch Am 03.06.2014 um 00:48 schrieb Dan Tran dant...@gmail.com: correct, I would expect user to install tar.exe or cygwin with tar on windows and activate the option. By default, it still uses plexus-archiver to unpack -D On Mon, Jun 2, 2014 at 3:42 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Windows does not have tar by default. You need to install Git (incl. Git Bash), Cygwin, GnuWin32 or similar. I would not expect any user to have tar installed at all or if so then in any predictable location or even reachable via PATH. -- Alexander Kriegisch Am 03.06.2014 um 00:36 schrieb Dan Tran dant...@gmail.com: I am think of enhancing maven-dependency-plugin by adding option to unpack 'tar' like artifact using native tar since it is faster and reserve soft links (?) Thoughts? would it be a maintaining night mare?? Thanks -Dan - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Use native tar to unpack? good/bad idea?
I am interested, may be it should be 3.0-alpha? -D On Mon, Jun 2, 2014 at 10:53 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I know I have a couple of branches that at least convert all the plexus-archiver zip stuff to use commons-compress, which is reasonably simple to plug into plexus-archiver. I have been a bit reluctant to push these changes since I've been mildly concerned about fallout. I think it should be fairly simple to convert the remaining plexus-archiver code to use commons-compress too, including the tar stuff. I am more concerned about the testing aspect of this change, it would require extensive testing and probably some community effort. Is there any interest in this ? Commons-compress is at least maintained; which is a Good Thing ;) Kristian 2014-06-03 6:20 GMT+02:00 Dan Tran dant...@gmail.com: Looks like it is worth a try to get maven-dependency-plugin having an option to use native tar during unpack. Thanks Jason -Dan On Mon, Jun 2, 2014 at 6:32 PM, Jason van Zyl ja...@takari.io wrote: I have had many problems with Java-based TAR solutions. I often use this where I can: https://github.com/airlift/airship/blob/master/airship-shared/src/main/java/io/airlift/airship/shared/FileUtils.java On Jun 2, 2014, at 7:15 PM, Dan Tran dant...@gmail.com wrote: BTW, I never have good luck with plexus-archiver, and always ended up to implement my own 'unpack' using native tar to speed up the build and also reserve the softlinks in the archive. So am asking the user list to see if there any interests in this feature to give enough incentive to implement it Thanks -D On Mon, Jun 2, 2014 at 4:08 PM, Dan Tran dant...@gmail.com wrote: Hi Alex, I will find a good sample file for you. Thanks -D On Mon, Jun 2, 2014 at 3:57 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Oh, I see, multiple options. Okay, then yes - maintenance nightmare. I think we should not easily give up Java's idea of platform independence and Maven's whole point: creating standardised, repeatable builds. If your idea is a reaction on your latest tar.gz problems, maybe we can find another solution for it. You have not reacted on my offer to inspect your files and see if I have an idea how to fix that in Java. :-) -- Alexander Kriegisch Am 03.06.2014 um 00:48 schrieb Dan Tran dant...@gmail.com: correct, I would expect user to install tar.exe or cygwin with tar on windows and activate the option. By default, it still uses plexus-archiver to unpack -D On Mon, Jun 2, 2014 at 3:42 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: Windows does not have tar by default. You need to install Git (incl. Git Bash), Cygwin, GnuWin32 or similar. I would not expect any user to have tar installed at all or if so then in any predictable location or even reachable via PATH. -- Alexander Kriegisch Am 03.06.2014 um 00:36 schrieb Dan Tran dant...@gmail.com: I am think of enhancing maven-dependency-plugin by adding option to unpack 'tar' like artifact using native tar since it is faster and reserve soft links (?) Thoughts? would it be a maintaining night mare?? Thanks -Dan - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Nexus / Maven repository artifact handling
Jason, William, Thanks for the clarifications. The information will certainly help in setting up for the next release cycle. cheers, mehul On Tue, Jun 3, 2014 at 12:29 AM, William Ferguson william.fergu...@xandar.com.au wrote: Mehul, this is the wrong pattern to use. It goes against the entire Maven dependency mechanism. Each GAV (aside from snapsghots) should represent a unique build. You should be creating new RC GAVs for each release candidate. eg groupX-artifactX-versionZ.rc1 William On Tue, Jun 3, 2014 at 12:27 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: We use SNAPSHOT during development, say 1.1.0-SNAPSHOT. At code freeze, we branch off from main line to a version specific branch and remove SNAPSHOT from the version string, so it becomes 1.1.0. Between code freeze and release we have RC builds. Its at that point that when a newer build of the same artifact is uploaded, so the GAV is identical, maven will not download the newest build. So its the same JAR file being uploaded, with the same version. The only thing changing is the file size and time stamp of the uploaded artifact. So I have fubar-1.1.0.jar uploaded to Nexus. The consumer picks up this jar file and downloads to ~/.m2. Now we find some problems with it, and there is an update. So a newer fubar-1.1.0.jar is uploaded, over-writing the old one. Then next time a build of the consuming project is run, it does not download the newly built fubar-1.1.0.jar. Based on what you're saying, this is a feature and the right way to do things, correct ? Than, how do folks handle RC versions ? cheers, mehul On Mon, Jun 2, 2014 at 6:54 PM, Jason van Zyl ja...@takari.io wrote: Are you deploying different artifacts with the same version? Release versions are expected to be immutable and Maven will not try to download a released artifact again because it's not expected to change. If you are deploying different artifacts using the same version you are using Maven incorrectly. On Jun 2, 2014, at 6:06 PM, mehul.sang...@gmail.com wrote: We have a Nexus server to which various projects upload artifacts. The artifacts are uploaded to a release repository, not a snapshot repository. One project is just a consumer of the artifacts. It does not upload anything. Even though we have an updated artifact available, the consuming project does not download the artifacts from nexus until we clear out the local repo in ~/.m2. How does Nexus / Maven determine that a new artifact needs to be downloaded from the remote repo? The timestamp reflects the time of upload of the artifact. So what am I missing ? The GAV is of the form: group:artifact.id:group.artifact.id-11.1.0.jar When a new group.artifact.id-11.1.0.jar is uploaded, it won't get downloaded by the consuming project. cheers, mehul -- Sent from my smart phone Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - -- Mehul N. Sanghvi email: mehul.sang...@gmail.com -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Use native tar to unpack? good/bad idea?
On Mon, Jun 02, 2014 at 04:15:15PM -0700, Dan Tran wrote: BTW, I never have good luck with plexus-archiver, and always ended up to implement my own 'unpack' using native tar to speed up the build and also reserve the softlinks in the archive. If plexus-archiver needs work, maybe they would accept a patch. Then everybody wins. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Maven repository management systems
Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com: Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven repository management systems
There are quite a few discussions of this topic, please search -D On Tue, Jun 3, 2014 at 10:49 AM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com: Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven repository management systems
Points well taken. No offence taken. :) On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com: Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com: Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
I would not recommend Archiva. It's intended to be mainly a reference implementation of the repository and, personally, i find it's UI to be a bit clunky. Whats moving you off Nexus? On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com : Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Controlling order of plugin execution
I'm trying to set up a Maven build for CI/CD, and one of the requirements for testing is to create, populate and tweak a database schema. This involves interleaving various executions of maven-dependency-plugin, sql-maven-plugin and exec-maven-plugin, and there aren't enough lifecycle phases *-test-[re]sources to accommodate all the steps. I'd like to bind six executions as follows: 1 maven-dependency-plugin:unpack - generate-test-resources 2 sql-maven-plugin:execute - generate-test-resources 3 sql-maven-plugin:execute - generate-test-resources 4 exec-maven-plugin:exec - process-test-resources 5 exec-maven-plugin:exec - process-test-resources 6 sql-maven-plugin:execute - process-test-resources But this doesn't work as Maven wants to execute sql-maven-plugin (steps 2 3) before step 1 and I can't find a way to make it do things in the desired sequence. There's a bug in Jira for this http://jira.codehaus.org/browse/MNG-3522 but it was closed as part of the great Jira cleanup of 2014. This has been an issue for several years but seems to get no attention. I don't think I should be required to write my own plugin to do what should be a common requirement. Can someone explain if there's an approved way to accomplish this? I know Maven is supposed to be declarative in nature, but sequencing steps seems like a basic requirement. From the lack of attention, and from reading other posts in places like StackOverflow, it appears there may be a philosophical objection to explicitly ordering executions. Can someone explain the reasoning for this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Controlling order of plugin execution
Jim, I reopened the issue for you, but, please note, this was closed because the issue was created 6 years ago and no one ever submitted a patch. Hopefully, someone has the incentive to work on this or it will be closed again. If you find this feature critical to your own work, do you have time to take a detour and submit a patch? Cheers, Paul On Tue, Jun 3, 2014 at 2:48 PM, Jim Garrison jim.garri...@nwea.org wrote: I'm trying to set up a Maven build for CI/CD, and one of the requirements for testing is to create, populate and tweak a database schema. This involves interleaving various executions of maven-dependency-plugin, sql-maven-plugin and exec-maven-plugin, and there aren't enough lifecycle phases *-test-[re]sources to accommodate all the steps. I'd like to bind six executions as follows: 1 maven-dependency-plugin:unpack - generate-test-resources 2 sql-maven-plugin:execute - generate-test-resources 3 sql-maven-plugin:execute - generate-test-resources 4 exec-maven-plugin:exec - process-test-resources 5 exec-maven-plugin:exec - process-test-resources 6 sql-maven-plugin:execute - process-test-resources But this doesn't work as Maven wants to execute sql-maven-plugin (steps 2 3) before step 1 and I can't find a way to make it do things in the desired sequence. There's a bug in Jira for this http://jira.codehaus.org/browse/MNG-3522 but it was closed as part of the great Jira cleanup of 2014. This has been an issue for several years but seems to get no attention. I don't think I should be required to write my own plugin to do what should be a common requirement. Can someone explain if there's an approved way to accomplish this? I know Maven is supposed to be declarative in nature, but sequencing steps seems like a basic requirement. From the lack of attention, and from reading other posts in places like StackOverflow, it appears there may be a philosophical objection to explicitly ordering executions. Can someone explain the reasoning for this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Controlling order of plugin execution
Agree sequencing is a pain. You may be able to get this working if you move your sql plugin delaration below exec-m-p -D On Tue, Jun 3, 2014 at 12:54 PM, Paul Benedict pbened...@apache.org wrote: Jim, I reopened the issue for you, but, please note, this was closed because the issue was created 6 years ago and no one ever submitted a patch. Hopefully, someone has the incentive to work on this or it will be closed again. If you find this feature critical to your own work, do you have time to take a detour and submit a patch? Cheers, Paul On Tue, Jun 3, 2014 at 2:48 PM, Jim Garrison jim.garri...@nwea.org wrote: I'm trying to set up a Maven build for CI/CD, and one of the requirements for testing is to create, populate and tweak a database schema. This involves interleaving various executions of maven-dependency-plugin, sql-maven-plugin and exec-maven-plugin, and there aren't enough lifecycle phases *-test-[re]sources to accommodate all the steps. I'd like to bind six executions as follows: 1 maven-dependency-plugin:unpack - generate-test-resources 2 sql-maven-plugin:execute - generate-test-resources 3 sql-maven-plugin:execute - generate-test-resources 4 exec-maven-plugin:exec - process-test-resources 5 exec-maven-plugin:exec - process-test-resources 6 sql-maven-plugin:execute - process-test-resources But this doesn't work as Maven wants to execute sql-maven-plugin (steps 2 3) before step 1 and I can't find a way to make it do things in the desired sequence. There's a bug in Jira for this http://jira.codehaus.org/browse/MNG-3522 but it was closed as part of the great Jira cleanup of 2014. This has been an issue for several years but seems to get no attention. I don't think I should be required to write my own plugin to do what should be a common requirement. Can someone explain if there's an approved way to accomplish this? I know Maven is supposed to be declarative in nature, but sequencing steps seems like a basic requirement. From the lack of attention, and from reading other posts in places like StackOverflow, it appears there may be a philosophical objection to explicitly ordering executions. Can someone explain the reasoning for this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Controlling order of plugin execution
I agree with Dan. Last I check, IIRC, the order of operations of plugins is defined by their sequential order in the POM. However, I also find this a bit problematic with inheritance -- I don't know off the top of my head what happens then. Cheers, Paul On Tue, Jun 3, 2014 at 3:01 PM, Dan Tran dant...@gmail.com wrote: Agree sequencing is a pain. You may be able to get this working if you move your sql plugin delaration below exec-m-p -D On Tue, Jun 3, 2014 at 12:54 PM, Paul Benedict pbened...@apache.org wrote: Jim, I reopened the issue for you, but, please note, this was closed because the issue was created 6 years ago and no one ever submitted a patch. Hopefully, someone has the incentive to work on this or it will be closed again. If you find this feature critical to your own work, do you have time to take a detour and submit a patch? Cheers, Paul On Tue, Jun 3, 2014 at 2:48 PM, Jim Garrison jim.garri...@nwea.org wrote: I'm trying to set up a Maven build for CI/CD, and one of the requirements for testing is to create, populate and tweak a database schema. This involves interleaving various executions of maven-dependency-plugin, sql-maven-plugin and exec-maven-plugin, and there aren't enough lifecycle phases *-test-[re]sources to accommodate all the steps. I'd like to bind six executions as follows: 1 maven-dependency-plugin:unpack - generate-test-resources 2 sql-maven-plugin:execute - generate-test-resources 3 sql-maven-plugin:execute - generate-test-resources 4 exec-maven-plugin:exec - process-test-resources 5 exec-maven-plugin:exec - process-test-resources 6 sql-maven-plugin:execute - process-test-resources But this doesn't work as Maven wants to execute sql-maven-plugin (steps 2 3) before step 1 and I can't find a way to make it do things in the desired sequence. There's a bug in Jira for this http://jira.codehaus.org/browse/MNG-3522 but it was closed as part of the great Jira cleanup of 2014. This has been an issue for several years but seems to get no attention. I don't think I should be required to write my own plugin to do what should be a common requirement. Can someone explain if there's an approved way to accomplish this? I know Maven is supposed to be declarative in nature, but sequencing steps seems like a basic requirement. From the lack of attention, and from reading other posts in places like StackOverflow, it appears there may be a philosophical objection to explicitly ordering executions. Can someone explain the reasoning for this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven repository management systems
The majority of developers seem to be using Nexus according to http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/ Slides 2 and 19 manfred PS: I am part of the Nexus team.. but was not involved in that survey. Glenn Brown wrote on 03.06.2014 12:22: I would not recommend Archiva. It's intended to be mainly a reference implementation of the repository and, personally, i find it's UI to be a bit clunky. Whats moving you off Nexus? On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com : Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven repository management systems
My question was what use case was making you think of no longer using nexus? On Tue, Jun 3, 2014 at 3:05 PM, Manfred Moser manf...@mosabuam.com wrote: The majority of developers seem to be using Nexus according to http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/ Slides 2 and 19 manfred PS: I am part of the Nexus team.. but was not involved in that survey. Glenn Brown wrote on 03.06.2014 12:22: I would not recommend Archiva. It's intended to be mainly a reference implementation of the repository and, personally, i find it's UI to be a bit clunky. Whats moving you off Nexus? On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com : Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven repository management systems
Perhaps Artifactory is cheaper and support repos like NPM? 100$ per seat for nexus professional is way expensive? :-) -D On Tue, Jun 3, 2014 at 1:10 PM, Glenn Brown ghbrown60...@gmail.com wrote: My question was what use case was making you think of no longer using nexus? On Tue, Jun 3, 2014 at 3:05 PM, Manfred Moser manf...@mosabuam.com wrote: The majority of developers seem to be using Nexus according to http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/ Slides 2 and 19 manfred PS: I am part of the Nexus team.. but was not involved in that survey. Glenn Brown wrote on 03.06.2014 12:22: I would not recommend Archiva. It's intended to be mainly a reference implementation of the repository and, personally, i find it's UI to be a bit clunky. Whats moving you off Nexus? On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: With all due respect: Can you ask in an even more general way? You do not expect someone to write a full review and comparison of those systems plus migration guide for you, do you? For such general information there are web search engines and tutorials. Constructive hint: Maybe if you explain which concrete problems or shortcomings you see in Nexus OSS, why you consider migration and what you want to achieve with the migration, someone will be glad to help you. I do not mean to be rude, but this is not a very smart way to ask a question on any mailing list. -- Alexander Kriegisch Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi mehul.sang...@gmail.com : Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with maven
Dear Sir,
I have installed maven 3. In jenkins it shows error while building.
errors are as below. Please do needful.
___
Started by user Amit Dhanani Building in workspace
/var/lib/jenkins/jobs/game-of-lifte-default/workspace /usr/bin/git rev-parse
--is-inside-work-tree
Fetching changes from the remote Git repository /usr/bin/git config
remote.origin.url https://github.com/amitdhanani2012/game-of-life.git Fetching
upstream changes from https://github.com/amitdhanani2012/game-of-life.git
/usr/bin/git --version /usr/bin/git fetchStarted by user Amit Dhanani
Building in workspace /var/lib/jenkins/jobs/game-of-lifte-default/workspace
/usr/bin/git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository /usr/bin/git config
remote.origin.url https://github.com/amitdhanani2012/game-of-life.git Fetching
upstream changes from https://github.com/amitdhanani2012/game-of-life.git
/usr/bin/git --version /usr/bin/git fetch --tags --progress
https://github.com/amitdhanani2012/game-of-life.git
+refs/heads/*:refs/remotes/origin/* /usr/bin/git rev-parse
origin/master^{commit}
Checking out Revision 29d7829dfe22387774d7e3ad92a18c7d319735ce (origin/master)
/usr/bin/git config core.sparsecheckout /usr/bin/git checkout -f
29d7829dfe22387774d7e3ad92a18c7d319735ce /usr/bin/git rev-list
29d7829dfe22387774d7e3ad92a18c7d319735ce
[workspace] $ /usr/share/maven3/bin/mvn clean install -o
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] gameoflife
[INFO] gameoflife-build
[INFO] gameoflife-core
[INFO] gameoflife-web
[INFO]
[INFO] Using the builder
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
with a thread count of 1
[INFO]
[INFO]
[INFO] Building gameoflife 1.0-SNAPSHOT
[INFO]
[WARNING] The POM for org.easyb:maven-easyb-plugin:jar:1.4 is missing, no
dependency information available [INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] gameoflife FAILURE [ 0.005 s]
[INFO] gameoflife-build .. SKIPPED
[INFO] gameoflife-core ... SKIPPED
[INFO] gameoflife-web SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.937 s
[INFO] Finished at: 2014-06-03T19:06:51+05:30
[INFO] Final Memory: 4M/11M
[INFO]
[ERROR] Plugin org.easyb:maven-easyb-plugin:1.4 or one of its dependencies
could not be resolved: Cannot access central
(http://repo.maven.apache.org/maven2) in offline mode and the artifact
org.easyb:maven-easyb-plugin:jar:1.4 has not been downloaded from it before. -
[Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
full debug logging. [ERROR] [ERROR] For more information about the errors and
possible solutions, please read the following articles: [ERROR] [Help 1]
httpStarted by user Amit Dhanani Building in workspace
/var/lib/jenkins/jobs/game-of-lifte-default/workspace /usr/bin/git rev-parse
--is-inside-work-tree
Fetching changes from the remote Git repository /usr/bin/git config
remote.origin.url https://github.com/amitdhanani2012/game-of-life.git Fetching
upstream changes from https://github.com/amitdhanani2012/game-of-life.git
/usr/bin/git --version /usr/bin/git fetch --tags --progress
https://github.com/amitdhanani2012/game-of-life.git
+refs/heads/*:refs/remotes/origin/* /usr/bin/git rev-parse
origin/master^{commit}
Checking out Revision 29d7829dfe22387774d7e3ad92a18c7d319735ce (origin/master)
/usr/bin/git config core.sparsecheckout /usr/bin/git checkout -f
29d7829dfe22387774d7e3ad92a18c7d319735ce /usr/bin/git rev-list
29d7829dfe22387774d7e3ad92a18c7d319735ce
[workspace] $ /usr/share/maven3/bin/mvn clean install -o
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] gameoflife
[INFO] gameoflife-build
[INFO] gameoflife-core
[INFO] gameoflife-web
[INFO]
[INFO] Using the builder
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
with a thread count of 1
[INFO]
[INFO]
Re: Problem with maven
On 4 June 2014 00:12, amit dhanani amit.dhan...@yahoo.com.invalid wrote: Dear Sir, I have installed maven 3. In jenkins it shows error while building. Did you try building this from the command line? You need to make sure you use the same command line that jenkins is doing or you will have environmental issues to deal with too. It may also help to purge your local ~/.m2/repo cache to mirror having a clean environment. [del] [workspace] $ /usr/share/maven3/bin/mvn clean install -o [del] [ERROR] Plugin org.easyb:maven-easyb-plugin:1.4 or one of its dependencies could not be resolved: Cannot access central ( http://repo.maven.apache.org/maven2) in offline mode and the artifact org.easyb:maven-easyb-plugin:jar:1.4 has not been downloaded from it before. Did you read the error message? Your maven invocation is using the -o option. mvn --help will show you that -o means --offline Work offline The error message shows that you have not downloaded this plugin before and because you are offline it will not download it for you. Maven can't work when it is missing stuff.
