JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
Hi Robert,Kristian, JDK 8 Build b124 Early Access Build is now available for download http://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. A fix for JDK-8030781 is included in b124. Please log all show stopper issues as soon as possible. If you are going to FOSDEM next week,please let me know we should meet up. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
Thanks, we saw that already. Preliminary checks seem to indicate things are much better ! I'll be running through our tests on windows, linux and OSX to see if there's anything else interesting to be found, I'll post a summary in couple of days time. Kristian 2014/1/22 Rory O'Donnell Oracle, Dublin Ireland rory.odonn...@oracle.com Hi Robert,Kristian, JDK 8 Build b124 Early Access Build is now available for downloadhttp://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. A fix for JDK-8030781 is included in b124. Please log all show stopper issues as soon as possible. If you are going to FOSDEM next week,please let me know we should meet up. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
On 22/01/2014 12:26, Kristian Rosenvold wrote: Thanks, we saw that already. Preliminary checks seem to indicate things are much better ! Glad to hear that. I'll be running through our tests on windows, linux and OSX to see if there's anything else interesting to be found, I'll post a summary in couple of days time. Excellent, hoping all will be in good shape. Rgds,Rory Kristian 2014/1/22 Rory O'Donnell Oracle, Dublin Ireland rory.odonn...@oracle.com mailto:rory.odonn...@oracle.com Hi Robert,Kristian, JDK 8 Build b124 Early Access Build is now available for download http://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. A fix for JDK-8030781 is included in b124. Please log all show stopper issues as soon as possible. If you are going to FOSDEM next week,please let me know we should meet up. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: JIRA Cleanup
Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing,
Re: JIRA Cleanup
I advise that we add a comment in each closing issue explaining that it was closed specifically because it's more than 2 years old and to re-open it only if it is still valid. Otherwise, it will look very rude to close a ticket without an explanation. BTW, what I just recommended was done by JBoss Hibernate and Spring Framework when they cleared out their old tickets. It was great to know their reasoning. On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote: Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason
Re: JIRA Cleanup
Sure, good idea. I assume there's a relatively straight forward way to do that with a bulk operation. On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote: I advise that we add a comment in each closing issue explaining that it was closed specifically because it's more than 2 years old and to re-open it only if it is still valid. Otherwise, it will look very rude to close a ticket without an explanation. BTW, what I just recommended was done by JBoss Hibernate and Spring Framework when they cleared out their old tickets. It was great to know their reasoning. On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote: Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares
Re: JIRA Cleanup
Yup, it's very straight forward to add a comment to each of the issues that will be closed. When I publish the accompanying documentation I can point the comment at the documentation. Good call. On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote: Sure, good idea. I assume there's a relatively straight forward way to do that with a bulk operation. On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote: I advise that we add a comment in each closing issue explaining that it was closed specifically because it's more than 2 years old and to re-open it only if it is still valid. Otherwise, it will look very rude to close a ticket without an explanation. BTW, what I just recommended was done by JBoss Hibernate and Spring Framework when they cleared out their old tickets. It was great to know their reasoning. On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote: Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we
Re: JIRA Cleanup
I changed the strategy slightly as I thought it might be crappy if the issue was created 5 years ago, but the person updated it 2 months ago. So I took all the issues that have not been updated in the last year and unassigned and closed those out. Got to about the same number and thought this more fair. I referred anyone looking at the comment to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 I'll start sifting through what remains tomorrow. On Jan 22, 2014, at 1:02 PM, Jason van Zyl ja...@takari.io wrote: Yup, it's very straight forward to add a comment to each of the issues that will be closed. When I publish the accompanying documentation I can point the comment at the documentation. Good call. On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote: Sure, good idea. I assume there's a relatively straight forward way to do that with a bulk operation. On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote: I advise that we add a comment in each closing issue explaining that it was closed specifically because it's more than 2 years old and to re-open it only if it is still valid. Otherwise, it will look very rude to close a ticket without an explanation. BTW, what I just recommended was done by JBoss Hibernate and Spring Framework when they cleared out their old tickets. It was great to know their reasoning. On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote: Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look
Maven 4.0.0
I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Adding a classpath element within a Mojo
Igor, I'm having some difficulty getting the LifecycleParticipant to resolve Maven components. In particular, the org.apache.maven.project.ProjectDependenciesResolver. While it gets resolved, none of it's internal attributes get resolved. So calls to projectDependenciesResolver.resolve crash with NPEs because DefaultProjectDependenciesResolver#logger or #repoSystem is not initialised. /** * @component * @readonly * @required */ protected ProjectDependenciesResolver projectDependenciesResolver; Is there some special trick to getting components fully initialised in a LifecycleParticipant? William On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko i...@ifedorenko.comwrote: Here is Tycho lifecycle participant [1] and here is the code that injects new dependencies in MavenProject instances [2]. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ TychoMavenLifecycleParticipant.java?h=tycho-0.19.x [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ MavenDependencyInjector.java?h=tycho-0.19.x -- Regards, Igor On 1/20/2014, 8:21, William Ferguson wrote: Thanks Igor, could you give me a link to an example or some code that - Utilises AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project dependencies from there. I found an example example by Brett Porter, but the doco is pretty thin and I can't see how I would go about inject extra elements into the classpath from there. William On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko i...@ifedorenko.com wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project dependencies. This is what we do in Tycho, where we resolve project OSGi dependencies in AbstractMavenLifecycleParticipant and then inject that into Maven project model as system scoped maven dependencies. I also think your usecase highlights general deficiency with current dependency model. Since you have to add classpath elements dynamically, these elements are not visible to maven-based tools like m2e without additional effort on the tools part. I think it will be useful to extend dependency element syntax to allow references for nested archive entries, i.e. dependency on classes jar nested within this AAR archive. -- Regards, Igor On 1/20/2014, 7:00, William Ferguson wrote: Hi, I realise this question isn't exactly related to dev within the Maven components, but it is about developing a Mojo using components that have to be pretty central and don't appear to be obviously documented anywhere. And I ahve asked on maven-users without much luck. As part of the android-maven-plugin we have a Mojo which needs to add an element to the compile time classpath for future Mojos (specifically the maven-compiler-plugin). Project has dependencies on artifacts of type AAR (Android archive - an archive that contains several sub-artifacts including a classes jar). Our Mojo unpacks the AAR artifacts and makes the sub-artifacts available to other build components. One of those build components is the maven-compiler-plugin. We want to add the classes contained in the AAR dependencies to the compile classpath so that the maven-compiler-plugin can compile our classes against the classes from the AARs. How do we do that? William - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 4.0.0
EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
