Maven 3.1.0 not adding assemblies to reactor
During rebuild of our Java packages for Fedora 20 we have encountered an interesting issue with Maven 3.1.0[1] When pom.xml is referencing assemblies in other module they are not resolved unless they are already in local or remote repository (i.e. reactor resolution of assemblies fails). Maven 3.0.5 works fine. I couldn't see anything in the release notes that would suggest this change was intentional, but before I file a bug maybe someone can correct me. Attached is a simple reproducer prepared by Mikolaj Izdebski [1] https://bugzilla.redhat.com/show_bug.cgi?id=991454 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com rep-1.0.0.tar.bz2 Description: BZip2 compressed data signature.asc Description: signature
Re: Maven 3.1.0 not adding assemblies to reactor
Adding -llr switch makes no difference in this case. To expand a bit on my initial explanation the issue is not related just to the assemblies but to any attached artifacts apparently. Quoting Baptiste Mathus (2013-08-09 13:34:51) Hi, Just a thought, could you please retry with -llr mvn option and see how it goes? Thanks 2013/8/9 Stanislav Ochotnicky sochotni...@redhat.com During rebuild of our Java packages for Fedora 20 we have encountered an interesting issue with Maven 3.1.0[1] When pom.xml is referencing assemblies in other module they are not resolved unless they are already in local or remote repository (i.e. reactor resolution of assemblies fails). Maven 3.0.5 works fine. I couldn't see anything in the release notes that would suggest this change was intentional, but before I file a bug maybe someone can correct me. Attached is a simple reproducer prepared by Mikolaj Izdebski [1] https://bugzilla.redhat.com/show_bug.cgi?id=991454 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! http://cz.redhat.com -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [1/2] git commit: Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven
I have another suggestion related to commit messages. Generally git commit messages follow following template: - First line contains summary of the change After one empty line there is more or less free-form text describing the commit in more detail. This can include: * lists * urls * basically anything But commiters should always treat first line of commit message the same way they treat subjects of emails: Try to summarize the commit in 80 characters. No bullet points, no dashes in the beginning etc. - git format-patch sort of assumes this template when generating patches. I am not sure where this might be written down, but I believe it would improve readability of commit logs slightly :-) Quoting Olivier Lamy (2012-11-30 09:04:51) In the future could we avoid those non necessary commit ? I have started a git convention page here: http://maven.apache.org/developers/conventions/git.html See the workflow section. All fixes/improvements for this doc will be appreciate :-) 2012/11/30 jvan...@apache.org: Updated Branches: refs/heads/master 1fe432b5d - af88f8500 Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven Project: http://git-wip-us.apache.org/repos/asf/maven/repo Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/af88f850 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/af88f850 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/af88f850 Branch: refs/heads/master Commit: af88f8500d5ba23a6b68773e12f38e832d0d7ea9 Parents: 97e8ae2 1fe432b Author: Jason van Zyl ja...@tesla.io Authored: Thu Nov 29 15:08:30 2012 -0800 Committer: Jason van Zyl ja...@tesla.io Committed: Thu Nov 29 15:08:30 2012 -0800 -- -- -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Git as the canonical SCM
Quoting Olivier Lamy (2012-09-04 22:23:11) ... Due to lack of support of sparse checkout in git, I (perso) don't want we have to create a git repo per plugin etc... IMHO That will be a pain to manage. No longer true, git has sparse checkout support (I believe since 1.7.0). See http://git-scm.com/docs/git-read-tree.html (search for Sparse checkout section). There are multiple examples spread through the interwebs, one would be: http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ And there's always shallow clones which are fine for sending format-patch(es). That said, the code should IMHO be split into repositories depending on their releases (i.e. code that gets releases simultaneously should be in one repo, code that has multiple parts which get their own release tags should be in separate repos) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Jason van Zyl (2012-07-30 17:43:13) On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: The only reason to do this from my PoV is if the plugin requires features only available in Maven 3. There are still a significant number of users who use Maven 2.2.1, yeah I would love to get them to jump up to 3.0.4, but I acknowledge that is something that may be beyond their control. Forcing plugin dependencies up without a valid driving requirement is just forcing unnecessary pain on the end users. IMHO features should drive the upgrading of dependencies, nothing else. +1 There is little value in updating plugins to use Maven 3.x components for the sake of it. The reason we spent so much time making sure that 3.x runs older components was to ensure no one has to do this. Apparently sending out inquiries before leaving for 2 week vacation was not ideal :-) So my view was somewhat different. I would hope you would like to get rid of direct dependencies on old Maven 2.x code. And as you've said Maven 3.x runs older components just fine, so this wouldn't have to be Let's switch tomorrow. Instead it could be a gradual maintenance cleanup. Removing dead and/or unmaintained code. But I understand people using Maven 2.2.1 would be unable to upgrade their dependencies to new versions using Maven 3.x artifacts (or at least it's not a supportable use-case even though it might work). In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Chris Graham (2012-07-30 15:43:31) I work with a lot of older (sometimes out of service software [customers pay a fortune but are prepared to live with it]) so I'm generally a fan of the lowest common denominator. Indeed nothing wrong with it What do you hope to achieve by the? Each released version still using Maven 2.x code prolongs its life. If you never stop supporting it, people will never start moving to new versions :-) I would expect people who want to live with old (or even out-of-service) software don't need (or want) to live with new plugins. Or so I would guess. But I understand they can give you task which requires feature of a new plugin, but new plugin would then need new Maven which they don't want to update not to break their other builds. There are solutions for that though (parallel installation being one) Are there any specific outstanding issues that need this change to solve? Nothing specific, just looking 10 years into the future where Maven 2.x still lives happily. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Quoting Stephen Connolly (2012-08-17 13:32:54) If in 50 years time that means that there is still some Maven plugins that depend on some of the published Maven APIs from Maven 2.0 then that is a success on behalf of the Maven developers, not a failure to force people to upgrade. I honestly didn't mean to make this into fail/win type scenario. In any case, you've made your opinion clear so I have a different question then :-) Is there any timeframe you have in mind for this transition to happen? 2 years? 5 years? 10 years? Never? I *assume* there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not be featured as download options). I would guess the transition would start at least then. Apache releases never die (which is why we cannot stop people (a.k.a. fools) downloading Maven 2.1.0) I'll try to be less metaphorical next time. I meant when they will stop to be supported by their developers. The links are there to help users that have specific requirements for Maven versions, but there is absolutely nothing stopping anyone from going and downloading the older versions, e.g. http://archive.apache.org/dist/maven/binaries/ I am aware of archive, but having download available does not mean that version is alive. Or should I try bugreporting against those old versions? My guess is that those bugs would be just closed as won't fix. So in that sense, I believe 3.x is basically the only alive version of Maven. 2.2.x and 2.0.x branches will likely not receive any security or any major fixes. For you they are done, and there's nothing wrong with that really, but for me it means those versions have no active upstream (pretty please take this with a grain of salt). Hence the curiosity. We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or Maven 4.0 (depends on how big a change we think things are) I would suspect that a 3.1 or 4.0 might consider dropping support for JRE 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain a link to the last version that only requires JRE 1.5 such as we are currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop the 2.0.11 link at that point in time is a different question. OK. I can live with uncertainty and speculations. This is enough for me. Thank you! -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Hi everyone, I am wondering what is general feeling about updating maven plugins from depending on Maven 2.x artifacts to their Maven 3.x counterparts. I am aware not all m2 artifacts have equivalents in m3 (i.e. maven-project, maven-artifact-manager and few others). Things have moved around somewhat (i.e. few classes from maven-artifact moved to -core or -compat). However, if someone provided patches, with builds and unit tests working and all that jazz, would there be willingness to work on making this transition happen? Or is the time not right just yet? Note that we've been running maven-3.0.4 and ~60 maven plugins without maven-core,maven-artifact and quite few other 2.x artifacts, for about a year and everything works as far as we are concerned (limited use case of Fedora Linux apply of course) For the record full list of maven 2.x artifacts we still keep is: * maven-artifact-manager * maven-error-diagnostics * maven-model * maven-monitor * maven-plugin-descriptor * maven-plugin-registry * maven-profile * maven-project * maven-toolchain -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How do I reply to an old message on the ml ?
Quoting Barrie Treloar (2012-07-23 23:33:41) On Tue, Jul 24, 2012 at 5:06 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: i finally got round to looking at http://mail-archives.apache.org/mod_mbox/maven-users/201207.mbox/%3c4FACC6C66D4D47538E474B2C75294A99@OlegF23S%3e and it turns out to be a bug and I'd like to respond to the users list. The problem is that I no longer have this thread in my mailbox and I think i've spent more time trying to coax ezmlm into sending me the original message in a format I can 'reply' to than I have on locating the race condition in question. If i do Users-Get.128170@m.a.o I Get a digest format that I cannot reply to How do I do this ?? I am not sure you can, or that its worth trying to figure it out. Either create a new message with a re: subject or you could work out how to reply from within Nabble (not sure this is the best idea) This is ugly way to do it and requires mail clients to use heuristics for threading. Instead what you can do is: 1. Look at raw output of message you want to reply to 2. Find Message-ID header (in this case 4FACC6C66D4D47538E474B2C75294A99@OlegF23S) 3. Start new message, ideally with RE: original subject (but not required, since threading is done by headers in this case) 4. Add a new header In-Reply-To: 4FACC6C66D4D47538E474B2C75294A99@OlegF23S 5. Send message Most email clients allow you to add additional headers (at least Thunderbird used to last time I checked), but for specifics you'll have to look at docs for your client. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Quoting Brett Porter (2012-03-21 21:06:05) http://svn.apache.org/repos/asf/maven/sandbox/trunk/rpm $ mvn install $ sudo rpm -ivh ~/.m2/repository/org/apache/maven/rpm/maven/3.0.4/maven-3.0.4.rpm Tested on CentOS 6.0. It installs to /usr/local/maven and /usr/local/bin/mvn. It also adds /etc/profile.d/maven.sh to add the bin directory to the PATH and M2_HOME variable, though neither are strictly necessary. Open to suggestions on improvements. I've had a look at the produced spec file and file layout and I do have a few suggestions: 1. Put maven into /usr/share/maven instead of /usr/local/maven. Or if you really want to put it into /usr/local subtree then /usr/local/share/maven. /usr/local/maven is...at least weird from FHS perspective. And then just symlink scripts into /usr/[local/]bin. 2. Your license tag doesn't state license, just copyright. In most RPM Linux distributions this would probably contain ASL 2.0. Full license name would be OK as well I guess 3. URL should probably be maven.apache.org instead of plain apache.org 4. Put settings.xml into /etc/ subtree (/etc/maven/ possibly) and symlink it back to M2_HOME (possibly same thing for m2.conf). It should also be marked as config file. 5. Handling of license/readme etc is different on different distros so I guess that can stay inside M2_HOME 6. A nice sensible %description copied from main site would be nice :-) I removed and requirement on a JDK package, to avoid requiring one alternative over another. Open to suggestions if there is a better way to express that in the spec file. 7. I have asked around a bit and it might make sense to add Requires: java (or java-devel) to the resulting RPM/spec. It would work at least on Fedora/SuSE/Mageia stack I would assume that works as well. But proprietary Oracle JDK rpm doesn't have this provides so it means we'd still pull in additional jdk. Oh well.. All in all seems we've both chosen to produce rpms of maven. I've taken the approach from RPM side and you from Maven side, both producing workable RPMS. Your approach could work in Jenkins more easily I guess to produce new builds of maven. By the time I got here I realized I could have just prepared a patch for your pom.xml instead of writing all this :-/ Anyway, I if you want to help with this feel free to get in touch off-list and I'll help when I can. If nothing else I believe I have pretty good idea what Linux distributions prefer/expect when dealing with rpms. On 22/03/2012, at 6:29 AM, Brett Porter wrote: On 22/03/2012, at 1:01 AM, Brian Fox wrote: Has anyone considered making an rpm/deb bundle that essentially contains a script which can fetch the associated tar.gz from the apache site and unpack it? We've had one at MaestroDev for a while. I'll clean it up, give it a spin, and put it in the sandbox. Interested users can at least build their own then. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. I like your approach. Kudos for handling this conversation in a civilized manner even though you were (more-less) turned down. Let's see if we can ease your pain a little bit... -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
I would *really* like for maven to produce RPMs as alternative dist output, but I understand your position. I had a quick look into rpm-maven-plugin and I believe a reasonable RPM output could be achieved by using it in with non-default profile. That should also prevent any problems with building for Windows users (or all that don't really care about rpm output). Or do you consider even this approach unviable? It's OK if you do, just want to know if I should keep looking for some compromise or if it's really out of the question. One way or the other I created a simple spec/srpm based on binary maven release: Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec SRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm BINRPM URL: http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm I should note that I don't really intend to support this solution. But I might update this together with maven releases since I assume it should be fairly easy. Another request: would you consider adding bash-completion[1] to maven sources someplace? We have a slightly modified version in Fedora. [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion Quoting Jason van Zyl (2012-03-20 13:33:32) Stanislav, If you're going to attempt something do it as an external action that takes the output of the primary build. Don't make something that augments the standard build process. That's invasive and for people building on Windows if problems arise they can't really fix it. If you make an entirely separate build that can consume the output of the standard build then people who are interested can take a look, those who don't care aren't affected. I don't want any specific modifications made to the existing build process to accommodate RPMs. I think a separate build would be more useful as it will be specific to the task at hand and people can use it as they like to produce RPMs for themselves if they so choose. On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: Quoting Jos Backus (2012-03-19 23:40:43) Hi Manfred, On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser manf...@mosabuam.com wrote: Jos, I agree with you in the sense that any open source project that cares about a wide user base should try to provide packages of its software that are useful to as many people as possible. Thanks. Therefore e.g. the Jenkins effort to offer all sorts of installs is laudible imho. Yes. It increases adoption by lowering the threshold to install/manage the software. However for Maven this is clearly not going to happen from the current team. There is just too much bad experience with old Maven packages supplied by various parties. That's too bad, really, as it will cause people like me to reinvent the wheel. But I understand the perspective and it's not my place to tell people how to spend their time. Well let's see if we can change this. I'll try to prepare patch for maven to generate rpms during build that would both work, and not make FHS proponents get angry (too much). If it gets commited: woot. If not at least I can tell my future kids I tried :-) That said I understand what would additional dist target entail for Maven devs. No hard feelings either way At this stage I would suggest to make the package yourself the way you want and host it on your own yum repo. Then you can do what you want and provide it to other people as well. Indeed. If you disregard a bit of common sense of Linux distribution wrt FHS and similar things you could create rpm by using binary maven tarball. It is definitely easier than adding rpm output to Maven and supporting it on different distributions :-) You could try to push it to rpm repositories outside Fedora/Red Hat in case any one is interested but it all depends on the effort you want to spend. Most people want to be sure they have an Apache quality package and that is only availalble in tar gz or zip with the well known disadvantages.. Yes, that's why it's desirable that the software producer produces the packages. In fact imho the slow uptake of new versions e.g. Maven 3 vs Maven 2 is in part due to the fact that no binaries for the various OS are available that would get automatically updates as part of regular updates.. Yes, I think so, too. Not providing packages hampers adoption of newer versions because people will stick with the old versions that tends to ship with their distro if there's no easy way to upgrade. That is why I would think that the Maven folks would be interested in this, but it sounds like it's not a priority. Thanks for your response, Manfred, and for everyone else's input in this thread. I like your approach. Kudos for handling this conversation in a civilized manner even though you were (more-less) turned down. Let's see if we can ease your pain a little bit... -- Stanislav Ochotnicky sochotni...@redhat.com
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-16 19:55:31) Hi Stanislav, On Fri, Mar 16, 2012 at 3:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. Okay, I will try to find the SRPM and rebuild it on my CentOS 6 box. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. Thanks for the pointer and your response. Another thing I should have pointed out right away, but forgot is that alternative way would be to create rpms directly out of upstream maven release with bundled dependencies and all that. I know most people on this list would feel more comfortable with this approach and it is more simple way to achieve your goals right now. It shouldn't take more than a few minutes to create that spec file. Good luck, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RPMs for Maven 3?
Quoting Jos Backus (2012-03-15 21:04:00) Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Depending on your needs for using exact upstream (meaning Apache) version or not you *might* have luck trying to use Fedora binary rpms on your CentOS machine. I haven't tried this, but with a 1 or 2 rebuilds it might work. You'd have to create your own rpm repo for this probably and do a few tweaks here and there. Biggest issue would probably be that some of our current binary rpms in F17 and rawhide are built using OpenJDK 7 with target set to 1.7 so you won't be able to use them with 1.6 VM. We do have 3.0.4 currently and quite a few plugins, but if you go this way I'd suggest to ask questions on java-devel at lists.fedoraproject.org. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Build Requires tag
Quoting enarkri (2012-03-16 09:27:12) Hi, I am creating an RPM package using rpm-maven-plugin. During the generation of the SPEC file, I would want to have the BUILDREQUIRES tag also to be printed in the SPEC file. Is it possible? If so how? From maven-rpm-plugin docs: In particular, source RPMs can not be generated and the spec files which are used do not do any build process (the plugin collects the files and installs them for packaging). This would suggest that resulting spec files are not suitable for rebuilding the package from scratch and therefore BuildRequires tag is pointless in them. I assume you have a specific use-case, but it doesn't seem valid from the information you provided. Why do you want to rebuild the rpm after the maven-rpm-plugin is done with it? -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Using maven as appstore for java app
Excerpts from Jesse Farinacci's message of Thu Dec 22 18:32:01 +0100 2011: Greetings, On Thu, Dec 22, 2011 at 12:20 PM, Deepesh Garg deepes...@gmail.com wrote: I share your pain, but couldn't find anything close when it comes to installing java apps. I don't think there is a standard for that, nor do I think it is required. The shared library mechanism employed by Linux and other high quality operating systems is a dying tradition, I think. It doesn't seem to fit for general applications. The performance gains are minimal, and the chance for having mismatched libraries requires far too much test and support time. It isn't worth the headache when you can get a 1Tb drive in a notebook for 100 USD; or when low end business laptops ship with quad core and hyperthreading. I see this again and again. People seem to forget that number 1 issue with bundling of dependencies is NOT performance/storage requirements. It is security. I'd like to see you fixing a security bug in a low-level java library (something from apache-commons would be a good example here). Let's see case of a multiple-application distribution with synced commons version (the dying tradition). Steps to fix security bug: 1. verify that one version you have shared among your applications is vulnerable 2. fix the vulnerability 3. test, deploy, etc. Whatever your processes require Now let's see the great new upcoming trend of bundled dependencies. Steps to fix security bug: 1. identify packages where you have bundled vulnerable library BEGIN LOOP 2. identify version of the library that is bundled for each application. Do you even have source code for bundled dep to check for vulnerability? You bundled just the binary right? 3. Develop fix for each of identified versions 4. test, deploy, etc END LOOP Good luck to your security response team. Before I forget: Merry Christmas and happy New Year everyone (no sarcasm here :-) ) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature
Re: [VOTE] Apache Maven 3.0.4
Excerpts from Arnaud Héritier's message of Sat Nov 26 00:37:09 +0100 2011: ... it might be really useful to add a link to release notes of components we upgraded like wagon, sisu or aether. I'm not sure that for all issues solved in these projects we have an MNG issue ? And nowadays we could have important maven issues hidden in such sub-components. It is just a proposal to try to give to users a better overview of changes This would be really great not just for users, but also for packagers in Linux distributions (i.e. me). I'll find out about updated deps one way or the other, but it would be nice to have it stated in the release notes if possible. So: pretty please do this :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature
Fix test scope dependency skipping
Hi everyone, Currently Maven includes test dependencies in resolving graph even when -Dmaven.test.skip is used. It's unnecessary and sub-optimal when big test dependencies have to be downloaded to local cache. As far as I know Maven 2.X didn't have this problem, so I'd guess this is a sort of regression (minor one, but still). I've prepared a patch (more like a hack) that solves this problem for me. However the patch uses literal maven.test.skip string, referencing test scope directly and few other ugly things so I know it can't be included as it is. I'd be willing to work on it more, but first I'd like your opinion on the general PoC idea so I don't waste time with something you'd consider pointless in the end :-) Regards, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature
Re: Fix test scope dependency skipping
Excerpts from Stanislav Ochotnicky's message of Mon Sep 05 10:35:17 +0200 2011: Hi everyone, Currently Maven includes test dependencies in resolving graph even when -Dmaven.test.skip is used. It's unnecessary and sub-optimal when big test dependencies have to be downloaded to local cache. As far as I know Maven 2.X didn't have this problem, so I'd guess this is a sort of regression (minor one, but still). I've prepared a patch (more like a hack) that solves this problem for me. However the patch uses literal maven.test.skip string, referencing test scope directly and few other ugly things so I know it can't be included as it is. I'd be willing to work on it more, but first I'd like your opinion on the general PoC idea so I don't waste time with something you'd consider pointless in the end :-) Aaand the patch... -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com 0001-Fix-text-scope-skipping-with-maven.test.skip.patch Description: Binary data signature.asc Description: PGP signature
[PATCH] Use ArtifactUtils when creating keys for ReactorReader
Hi,
ReactorReader used ArtifactUtils in some places, but in others created
keys/versionless keys on its own. This inconsistency could cause
problems in the future. Attached patch fixes this problem.
--
Stanislav Ochotnicky sochotni...@redhat.com
Associate Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
From f82d77ab758e24248a6ddeea2130180a0b3b1fd6 Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky sochotni...@redhat.com
Date: Mon, 17 Jan 2011 18:26:14 +0100
Subject: [PATCH] Use ArtifactUtils when creating keys for ReactorReader
---
.../main/java/org/apache/maven/ReactorReader.java |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/maven-core/src/main/java/org/apache/maven/ReactorReader.java
b/maven-core/src/main/java/org/apache/maven/ReactorReader.java
index 62e181a..3d08c65 100644
--- a/maven-core/src/main/java/org/apache/maven/ReactorReader.java
+++ b/maven-core/src/main/java/org/apache/maven/ReactorReader.java
@@ -216,7 +216,7 @@ class ReactorReader
public File findArtifact( Artifact artifact )
{
-String projectKey = artifact.getGroupId() + ':' +
artifact.getArtifactId() + ':' + artifact.getVersion();
+String projectKey = ArtifactUtils.key( artifact.getGroupId(),
artifact.getArtifactId(), artifact.getVersion() );
MavenProject project = projectsByGAV.get( projectKey );
@@ -230,7 +230,7 @@ class ReactorReader
public ListString findVersions( Artifact artifact )
{
-String key = artifact.getGroupId() + ':' + artifact.getArtifactId();
+String key = ArtifactUtils.versionlessKey( artifact.getGroupId(),
artifact.getArtifactId() );
ListMavenProject projects = projectsByGA.get( key );
if ( projects == null || projects.isEmpty() )
--
1.7.3.4
signature.asc
Description: OpenPGP digital signature
Explanation for bundleshade of org.sonatype.sisu ?
Hi,
I am currently in the process of packaging Maven 3 and all its
dependencies for Fedora. I encountered few things in org.sonatype.sisu
pom.xml that I don't entirely understand.
This is the main directory structure:
.
├── guice-bean
│ ├── guice-bean-binders
│ ├── guice-bean-containers
│ ├── guice-bean-converters
│ ├── guice-bean-inject
│ ├── guice-bean-locators
│ ├── guice-bean-reflect
│ ├── guice-bean-scanners
│ └── sisu-inject-bean
└── guice-plexus
├── guice-plexus-binders
├── guice-plexus-converters
├── guice-plexus-locators
├── guice-plexus-metadata
├── guice-plexus-scanners
├── guice-plexus-shim
└── sisu-inject-plexus
sisu-inject-bean and sisu-inject plexus seem to be bundling and shading
rest of their group respectively (plus few other libraries such as
objectweb-asm, javax.inject and some plexus parts).
What I don't understand is why was this approach used instead of
standard dependency resolution of maven (addding libraries into
dependency section or similar). For the reference I am adding part of
sisu-inject-plexus pom.xml containing settings for bundle and shade
plugin. I am guessing it might have something to do with the way bundle
plugin is used, but I'd rather know for sure.
-
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
excludeDependencies
!-- fragment host and external dependencies --
sisu-inject-bean,*;groupId=org.codehaus.plexus
/excludeDependencies
instructions
Bundle-SymbolicName
org.sonatype.inject.plexus
/Bundle-SymbolicName
Fragment-Host
org.sonatype.inject
/Fragment-Host
Export-Package
org.codehaus.plexus.*;-noimport:=true;-split-package:=merge-first
/Export-Package
Private-Package
META-INF.plexus,org.sonatype.guice.*,org.objectweb.asm
/Private-Package
/instructions
/configuration
/plugin
plugin
artifactIdmaven-shade-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration
artifactSet
includes
include${project.groupId}:${project.artifactId}/include
/includes
/artifactSet
relocations
relocation
patternorg.objectweb/pattern
shadedPatternorg.sonatype.guice/shadedPattern
/relocation
/relocations
filters
filter
artifact*:*/artifact
includes
includeMETA-INF/**/include
includeorg/codehaus/plexus/**/include
includeorg/sonatype/guice/plexus/**/include
includeorg/objectweb/asm/*Writer*/include
/includes
/filter
/filters
/configuration
/execution
/executions
/plugin
/plugins
/build
--
Stanislav Ochotnicky sochotni...@redhat.com
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
Explanation for bundleshade of org.sonatype.sisu ?
Hi,
I am currently in the process of packaging Maven 3 and all its
dependencies for Fedora. I encountered few things in org.sonatype.sisu
pom.xml that I don't entirely understand.
This is the main directory structure:
.
├── guice-bean
│ ├── guice-bean-binders
│ ├── guice-bean-containers
│ ├── guice-bean-converters
│ ├── guice-bean-inject
│ ├── guice-bean-locators
│ ├── guice-bean-reflect
│ ├── guice-bean-scanners
│ └── sisu-inject-bean
└── guice-plexus
├── guice-plexus-binders
├── guice-plexus-converters
├── guice-plexus-locators
├── guice-plexus-metadata
├── guice-plexus-scanners
├── guice-plexus-shim
└── sisu-inject-plexus
sisu-inject-bean and sisu-inject plexus seem to be bundling and shading
rest of their group respectively (plus few other libraries such as
objectweb-asm, javax.inject and some plexus parts).
What I don't understand is why was this approach used instead of
standard dependency resolution of maven (addding libraries into
dependency section or similar). For the reference I am adding part of
sisu-inject-plexus pom.xml containing settings for bundle and shade
plugin. I am guessing it might have something to do with the way bundle
plugin is used, but I'd rather know for sure.
-
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
excludeDependencies
!-- fragment host and external dependencies --
sisu-inject-bean,*;groupId=org.codehaus.plexus
/excludeDependencies
instructions
Bundle-SymbolicName
org.sonatype.inject.plexus
/Bundle-SymbolicName
Fragment-Host
org.sonatype.inject
/Fragment-Host
Export-Package
org.codehaus.plexus.*;-noimport:=true;-split-package:=merge-first
/Export-Package
Private-Package
META-INF.plexus,org.sonatype.guice.*,org.objectweb.asm
/Private-Package
/instructions
/configuration
/plugin
plugin
artifactIdmaven-shade-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration
artifactSet
includes
include${project.groupId}:${project.artifactId}/include
/includes
/artifactSet
relocations
relocation
patternorg.objectweb/pattern
shadedPatternorg.sonatype.guice/shadedPattern
/relocation
/relocations
filters
filter
artifact*:*/artifact
includes
includeMETA-INF/**/include
includeorg/codehaus/plexus/**/include
includeorg/sonatype/guice/plexus/**/include
includeorg/objectweb/asm/*Writer*/include
/includes
/filter
/filters
/configuration
/execution
/executions
/plugin
/plugins
/build
--
Stanislav Ochotnicky sochotni...@redhat.com
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
