Re: The next major release of Maven: 4.0.0
I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl ja...@tesla.io wrote: I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only
Re : The next major release of Maven: 4.0.0
I'm on vacation, with weak mobile connexion... I'll try m-dependency-tree when back home Id You updates m-dependency-p to latest -tree, the hope was it would work without more efforts Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mer., mars 13, 2013 08:00 I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl ja...@tesla.io wrote: I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter
Re : The next major release of Maven: 4.0.0
If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 3:30 AM, herve.bout...@free.fr wrote: I'm on vacation, with weak mobile connexion... I'll try m-dependency-tree when back home Id You updates m-dependency-p to latest -tree, the hope was it would work without more efforts It may be something small, but it appears to be an issue at the moment. Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mer., mars 13, 2013 08:00 I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl ja...@tesla.io wrote: I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since
Re: Re : The next major release of Maven: 4.0.0
Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr: If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus
Re: Re : The next major release of Maven: 4.0.0
On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr : If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit
Re: The next major release of Maven: 4.0.0
Ansgar, Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. It would be like me forcing everyone at Apache to build with Maven because that's what I understand. Isn't building your software just as, or more, important than publishing your website? Yet we don't force everyone to build with Maven, we let each project decide based on their preferences and needs. It should be the same for any tool a project decides to use. On Mar 13, 2013, at 8:50 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr : If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote
Re: The next major release of Maven: 4.0.0
As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
So what do you normally use for documentation? Or what would you prefer? Of anything I've seen here the Confluence -- static website looked the most promising. As soon as you saved a page it attempted to make the update to the static website. I don't know if that's still in use but was being used by some projects at some point. On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 9:40 AM, Jason van Zyl ja...@tesla.io wrote: So what do you normally use for documentation? Or what would you prefer? Of anything I've seen here the Confluence -- static website looked the most promising. As soon as you saved a page it attempted to make the update to the static website. I don't know if that's still in use but was being used by some projects at some point. Several projects still use Confluence - static website, but it's a bit more complicated now with svnpubsub in there. We have buildbot builds that run once an hour to export the confluence space to static HTML and check it into SVN where svnpubsub then takes over. CXF, Camel, ActiveMQ, Geronimo, etc… are using it. See: http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ Dan On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 9:18 AM, Jason van Zyl ja...@tesla.io wrote: Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. Umm…. No one in Apache is forcing the CMS on anyone. The only requirement is that your website must be stored in subversion someplace. It can be in your projects main svn tree someplace or infra has setup a separate repo that can be used. This really is no different than a directory someplace other than it's backed by an SCM.How the project populates that SVN space is completely up to the project.The CMS is just one way of accomplishing that.Confluence + the exporter tool + buildbot is one.Directly editing .html files with emacs is another. A maven build from buildbot is another.That's completely up to the project to decide. Dan It would be like me forcing everyone at Apache to build with Maven because that's what I understand. Isn't building your software just as, or more, important than publishing your website? Yet we don't force everyone to build with Maven, we let each project decide based on their preferences and needs. It should be the same for any tool a project decides to use. On Mar 13, 2013, at 8:50 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr : If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 12:09 PM, Daniel Kulp dk...@apache.org wrote: On Mar 13, 2013, at 9:18 AM, Jason van Zyl ja...@tesla.io wrote: Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. Umm…. No one in Apache is forcing the CMS on anyone. Just quoting Benson about the choice issue. I don't ever remember any discussion it just seemed to start happening and I remember mention of a CMS. The only requirement is that your website must be stored in subversion someplace. It can be in your projects main svn tree someplace or infra has setup a separate repo that can be used. This really is no different than a directory someplace other than it's backed by an SCM.How the project populates that SVN space is completely up to the project.The CMS is just one way of accomplishing that.Confluence + the exporter tool + buildbot is one.Directly editing .html files with emacs is another. A maven build from buildbot is another.That's completely up to the project to decide. Do you like the Confluence setup? That seems the easiest of solutions where you edit a page and the site is updated eventually. Dan Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: The next major release of Maven: 4.0.0
I apologize for muddling svnpubsub and the cmd On Mar 13, 2013, at 12:19 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 13, 2013, at 12:09 PM, Daniel Kulp dk...@apache.org wrote: On Mar 13, 2013, at 9:18 AM, Jason van Zyl ja...@tesla.io wrote: Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. Umm…. No one in Apache is forcing the CMS on anyone. Just quoting Benson about the choice issue. I don't ever remember any discussion it just seemed to start happening and I remember mention of a CMS. The only requirement is that your website must be stored in subversion someplace. It can be in your projects main svn tree someplace or infra has setup a separate repo that can be used. This really is no different than a directory someplace other than it's backed by an SCM.How the project populates that SVN space is completely up to the project.The CMS is just one way of accomplishing that.Confluence + the exporter tool + buildbot is one.Directly editing .html files with emacs is another. A maven build from buildbot is another.That's completely up to the project to decide. Do you like the Confluence setup? That seems the easiest of solutions where you edit a page and the site is updated eventually. Dan Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right
Re: The next major release of Maven: 4.0.0
Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would
Re: The next major release of Maven: 4.0.0
My one comment would be to please just get this out and available to everyone soon so we can move on. manfred Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to
Re: The next major release of Maven: 4.0.0
Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal
Re: The next major release of Maven: 4.0.0
Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x
Re: The next major release of Maven: 4.0.0
I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the
Re: The next major release of Maven: 4.0.0
2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for
Re: The next major release of Maven: 4.0.0
On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:43 PM, Stuart McCulloch mccu...@gmail.com wrote: On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. Here you go: http://wiki.eclipse.org/Aether/New_and_Noteworthy Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
The next major release of Maven: 4.0.0
Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. I would just like to move on and start developing some features. Trying to create adapter layers and shims is just going to kill us. I think we should just cut bait because there is no desire amongst the people who can make a shim that have time (myself, Benjamin, Igor) and I doubt Hervé or Kristian really have the time to make a complete shim between the versions of Aether. The few points that people are calling into Aether essentially expose the whole API so the shim needed will be enormous given the package name changes and the API changes in Aether. It will be very much like bridge Aether and Maven Artifact APIs and that simply isn't something that would ever have been done without full-time work and I just don't deem that a worthy investment this time. So I propose rolling in the Eclipse Aether changes along with the JSR330 and SLF4J changes and call it 4.0.0. Also I feel that any hiding of the Aether at this point has been a failure. Everyone is jumping around the Maven Artifact APIs because they need to get at more powerful constructs. This hiding of Aether in practice has been futile and no one is every going to make another artifact API in Maven, it's just not going to happen let's face it. Once Eclipse Aether 1.0.0 is released given the Eclipse standards the API will have to remain compatible. I believe all the changes in Aether made in the last 18 months have been worthwhile and there's no point to unwind anything to try and make it work with Sonatype Aether. If we agree on this then I will roll in all the changes, figure out what's wrong with JDK8 and then we release it. The ITs pass and we'll just have to help people adapt their plugins. I talked to Manfred Moser who works on the Android Maven plugin and he doesn't see an issue with updating. We'll just have to update the rest of the plugins or we'll be spending months trying to make a shim or a magic classloader and I'm not sure it's really worth it. I think it's time to move on with our better core and just move on in general. I think people need to digest this and think about it, but I do believe it is the most practical way forward. SLF4J I consider standard, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it. Thanks, Jason [1]: http://ci.tesla.io:8080/job/tesla-its/ws/ -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl
Re: The next major release of Maven: 4.0.0
A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path.
Re: The next major release of Maven: 4.0.0
On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release. PS. I see that Maven trunk currently exports org.sonatype.inject from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they will also be supported in Eclipse/Sisu. It only contains a small handful of interfaces and annotations so this really isn't much work. Otherwise if you don't use anything from org.sonatype.inject then I suggest this package is removed from the export list for the moment. -- Cheers, Stuart I would just like to move on and start developing some features. Trying to create adapter layers and shims is just going to kill us. I think we should just cut bait because there is no desire amongst the people who can make a shim that have time (myself, Benjamin, Igor) and I doubt Hervé or Kristian really have the time to make a complete shim between the versions of Aether. The few points that people are calling into Aether essentially expose the whole API so the shim needed will be enormous given the package name changes and the API changes in Aether. It will be very much like bridge Aether and Maven Artifact APIs and that simply isn't something that would ever have been done without full-time work and I just don't deem that a worthy investment this time. So I propose rolling in the Eclipse Aether changes along with the JSR330 and SLF4J changes and call it 4.0.0. Also I feel that any hiding of the Aether at this point
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:43 PM, Stuart McCulloch mccu...@gmail.com wrote: On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. I'll collect them with Benjamin, as I'm not sure how good any standard API diffing tool is going to work with all the package changes. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - I don't really want to add anything beyond JSR330, SLF4J and Eclipse Aether. The frequency of change in the core for new features basically ground to a halt. I really don't think this behaviour is going to change radically so I don't see much point in waiting for anything beyond agreement to get a 4.0.0 out the door. meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release. If someone wants to do a 3.1.x that's fine with me but I think having two major branches will just get out of sync. I'm personally in favour of getting a 4.0.0 as fast as possible because the ITs still pass and the few plugins that seem to have issue can be fixed pretty quickly. I just don't think the bandwidth exists to maintain two major branches. Sonatype Aether isn't going to get any love and syncing the branches across package changes probably won't be much fun. We would probably also have to deal with multiple branches across the plugins that will be affected. I proposed what I'm willing to maintain and I think that's ultimately going to be the easiest for us to maintain. PS. I see that Maven trunk currently exports org.sonatype.inject from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: The next major release of Maven: 4.0.0
As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. I have not formed an opinion yet, but here are some things that are filtering around in my head w.r.t. this proposal. * When the switch to Aether was originally put forward, the promise was that with Aether at Eclipse there would be a community of people to work on the directed dependency graph problem set... http://lh5.ggpht.com/-MY5CB_MVKCo/UQErH7pws-I/AK8/WT_zSXWy2eQ/graph.png?imgmax=800 I am seriously worried when I see that *I* am the #3 most active committer to Aether at Eclipse, not that I don't believe I could be a contributor to Aether, more that I have on two occasions said OK, Stephen, time to try and get involved with Aether, started trying to get my feet wet with some small tweaks, and then had my spare time stolen again. I.O.W. I have not engaged with Aether to the level I feel comfortable with saying *I* am a significant contributor...and I (as of 3rd Feb 2012) am the #3 committer! * OK, so logback has effectively 1 active committer... but a very long history, and an API that other implementations are available for, and it's the defacto standard. Aether has really only got users because of Maven from what I can see, and it's got Benjamin as its developer and driver. Now Benjamin knows this space backwards and is great at writing good code... if this is the proposal to resolve the issue of keeping Benjamin's skills available for Maven, while Benjamin (for perfectly legitimate, if outside of the control of the PMC, reasons) does not want to develop code at ASF (based on the evidence of not seeing any engagement from Benjamin since the Board reared its heavy hand), then lets state it as such. But I see that the community of logback developers vs the community of aether developers are a different kettle of fish. If we tie ourselves now to the Aether API, we make it hard to move to an alternative implementation. If there were two competing implementations of the Aether API I would be happy to say that the API is robust and there has been true separation of API from Implementation. In this case we have and API with one and only one implementation, it may or may not have true separation of API from Implementation, but without having been hardened by having a second implementation, it is hard to know for sure. There may be design biases based on the views of the implementers. I guess my point is that I would need to be convinced some more that we would not be baking an API with biases into the core of Maven. Right now we have the case where a few plugins have leaked dependencies to Sonatype Aether, the Maven developer view has been that plugin authors should not do that, but obviously some have, in so doing they should have been aware of the risk they take in using APIs that Maven is not saying are part of the exported hull. Having said that, nobody else has stood up to say oh I have an alternative for Aether
Re: The next major release of Maven: 4.0.0
On 3 March 2013 22:41, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. Well I agree with Semantic Versioning, so the question here that dictates 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed supported API of Maven. IIRC the stated position is that plugin authors are not supposed to rely on the Sonatype Aether API. If plugin authors have relied on it then they are responsible for ensuring that the plugin works in its absence... that would strongly indicate that 3.2 (or 3.1 if at the same time as SLF4J) is the correct SemVer version... but if you view the Sonatype Aether API as being part of the exposed supported API of Maven (as opposed to leaked unsupported API) then 4.0 would be the correct SemVer -Stepjen If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
Well I agree with Semantic Versioning, so the question here that dictates 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed supported API of Maven. IIRC the stated position is that plugin authors are not supposed to rely on the Sonatype Aether API. If plugin authors have relied on it then they are responsible for ensuring that the plugin works in its absence... that would strongly indicate that 3.2 (or 3.1 if at the same time as SLF4J) is the correct SemVer version... but if you view the Sonatype Aether API as being part of the exposed supported API of Maven (as opposed to leaked unsupported API) then 4.0 would be the correct SemVer What if we published a specific policy that covered this case: something like: The Maven project is in transition in the area of dependency resolution. The existing official API is good enough for many problems, but does not expose enough operations to allow the correct implementation of a few, important plugins. Therefore, these plugins are coded directly to 'Sonatype Aether.' The Maven community plans to make changes to these APIs over the next few releases as we work to refine an appropriate public API in this area. Since these changes won't have much user-visible impact, they won't be major versions, even though they will change this API, and require the few plugins which touch it to change to track it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. I have not formed an opinion yet, but here are some things that are filtering around in my head w.r.t. this proposal. * When the switch to Aether was originally put forward, the promise was that with Aether at Eclipse there would be a community of people to work on the directed dependency graph problem set... http://lh5.ggpht.com/-MY5CB_MVKCo/UQErH7pws-I/AK8/WT_zSXWy2eQ/graph.png?imgmax=800 I am seriously worried when I see that *I* am the #3 most active committer to Aether at Eclipse, not that I don't believe I could be a contributor to Aether, more that I have on two occasions said OK, Stephen, time to try and get involved with Aether, started trying to get my feet wet with some small tweaks, and then had my spare time stolen again. I.O.W. I have not engaged with Aether to the level I feel
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. I see JSR330, SLF4J and Eclipse Aether as valuable. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. I have no long use of user-visible improvements because I'm the only one working on the core. There's only so much I'm willing to do and I won't develop any features until I know they will be used. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: The next major release of Maven: 4.0.0
On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. Let's consider three audiences: 1. end users 2. most plugin developers 3. core devs and the devs of the small inventory of very dependency-sensitve plugins I think that all of these things you are citing are good things. But I think that they are mostly in categories 2 and 3, and in the case of Aether, entirely in 3. Thus my view about version numbers. if I'm missing something and picking up a new Aether has benefits for category 1, great. I also want to write now that I'm not on a campaign here. I'd rather see all this happen as '4.0.0' than not happen at all, even if my preference is as expressed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
To me I would like to roll in all of it, I think the bump in major version is appropriate but if we call that 3.1.0 that's fine. It really does work almost the same, there are some plugins that will get need some rework but that's not the end of the world. To me a plugin that works in 3.0.x but not in another later versions is a major breakage. We can define it however we like and call the version whatever we like. I think the major rub is adopting Aether as the Artifact API we're going to expose. My opinion is that it already is. It's out there because people ducked around to get at Aether but we also allowed the RepositorySystem and RepositorySystemSession to be pushed into plugins. Some people moaned but no one stopped it and that is public plugin API as far as I'm concerned. With those two classes exposed you have access to all of Aether and that's been sitting there for 2 years. So the cat is out of the bag and another Artifact API is such a futile value-less effort given Aether's existence. If someone had jumped up and made the bridge a year ago and kept in sync with Eclipse Aether that would be different. But as I noted it's hard, time consuming work. Unless someone commits to do full-time work on this I don't see a bridge, or shim, or new API being made before I'm elderly. If we roll the combo of JSR330, SLF4J and Eclipse Aether things will work for most and we can probably update the rest of the plugins before anyone switches. The code will also be smaller, the dependency plugins using Aether, for example, would probably shed 2/3 of the code. On Mar 3, 2013, at 7:58 PM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. Let's consider three audiences: 1. end users 2. most plugin developers 3. core devs and the devs of the small inventory of very dependency-sensitve plugins I think that all of these things you are citing are good things. But I think that they are mostly in categories 2 and 3, and in the case of Aether, entirely in 3. Thus my view about version numbers. if I'm missing something and picking up a new Aether has benefits for category 1, great. I also want to write now that I'm not on a campaign here. I'd rather see all this happen as '4.0.0' than not happen at all, even if my preference is as expressed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: The next major release of Maven: 4.0.0
Same here. On Sunday, March 3, 2013, Benson Margulies wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.iojavascript:; wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.comjavascript:; wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.iojavascript:; wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.comjavascript:; wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
