Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas
Baptiste, when you do not control Nexus but have to go through a proxy for http and want to develop Jenkins plugins you need such voodoo :-) . Regards Mirko -- Sent from my mobile On Feb 13, 2014 8:56 AM, Baptiste Mathus m...@batmat.net wrote: Btw (apart from the fact that kind of question should better be asked on users ML), it seems a bit weird to me at first sight you're actually having to configure both a nexus server, and a proxy. For instance, we exclusively use a nexus server to do the actual proxying(+hosting) of anything that maven has to download inside the company. Not sure what's your use case to need to not go through your maven repo manager any time. My 2 cents. 2014-02-13 8:17 GMT+01:00 Anders Hammar and...@hammar.net: It would be great if you could file a JIRA ticket so that the docs can be fixed, see [1]! Use the website JIRA project. /Anders [1] http://maven.apache.org/issue-tracking.html On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian ian.barn...@lmco.com wrote: I develop behind a proxy. Some of our servers sit behind that proxy as well, including our Nexus Repository. I have configured my settings.xml to point to our proxy but to ignore the hosts that are behind that proxy. If I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore that list and apply the proxy to those hosts as well. If I use a pipe-delimited list in my nonProxyHosts, everything works great and Maven does NOT try to apply the proxy to those hosts. According to this document only pipes are acceptable as delimiters, which is what I observed: https://maven.apache.org/guides/mini/guide-proxies.html According to this document either pipes or commas are acceptable as delimiters which is incorrect according to my observation: https://maven.apache.org/settings.html (Proxies header) This is an example of the proxies block in my settings.xml file that does not work. When Maven needs to hit 123.456.789.111 or my.nexus.host, it applies the proxy to it. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost,123.456.789.*,my.nexus.host/nonProxyHosts /proxy /proxies This example WORKS. Proxy is ignored for any requests to 123.456.789.111 or my.nexus.host, etc. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost|123.456.789.*|my.nexus.host/nonProxyHosts /proxy /proxies Environment: Maven 3.1.1 Mac OS-X 10.9 Also reproduced this issue on: Apache Maven 3.0.4 Ubuntu 11.04 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas
;-). We simply added the jenkins repos in our nexus instance, as this is what our/a MRM is designed for, but I see your point when you're inside an rigid organization and you just want to work. My goal is surely not to say proxy is useless, but more something like are you sure you're using it for the right reasons? Anyway, I see your point :-). 2014-02-13 9:47 GMT+01:00 Mirko Friedenhagen mfriedenha...@gmail.com: Baptiste, when you do not control Nexus but have to go through a proxy for http and want to develop Jenkins plugins you need such voodoo :-) . Regards Mirko -- Sent from my mobile On Feb 13, 2014 8:56 AM, Baptiste Mathus m...@batmat.net wrote: Btw (apart from the fact that kind of question should better be asked on users ML), it seems a bit weird to me at first sight you're actually having to configure both a nexus server, and a proxy. For instance, we exclusively use a nexus server to do the actual proxying(+hosting) of anything that maven has to download inside the company. Not sure what's your use case to need to not go through your maven repo manager any time. My 2 cents. 2014-02-13 8:17 GMT+01:00 Anders Hammar and...@hammar.net: It would be great if you could file a JIRA ticket so that the docs can be fixed, see [1]! Use the website JIRA project. /Anders [1] http://maven.apache.org/issue-tracking.html On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian ian.barn...@lmco.com wrote: I develop behind a proxy. Some of our servers sit behind that proxy as well, including our Nexus Repository. I have configured my settings.xml to point to our proxy but to ignore the hosts that are behind that proxy. If I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore that list and apply the proxy to those hosts as well. If I use a pipe-delimited list in my nonProxyHosts, everything works great and Maven does NOT try to apply the proxy to those hosts. According to this document only pipes are acceptable as delimiters, which is what I observed: https://maven.apache.org/guides/mini/guide-proxies.html According to this document either pipes or commas are acceptable as delimiters which is incorrect according to my observation: https://maven.apache.org/settings.html (Proxies header) This is an example of the proxies block in my settings.xml file that does not work. When Maven needs to hit 123.456.789.111 or my.nexus.host, it applies the proxy to it. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost,123.456.789.*,my.nexus.host/nonProxyHosts /proxy /proxies This example WORKS. Proxy is ignored for any requests to 123.456.789.111 or my.nexus.host, etc. proxies proxy idMy Proxy/id activetrue/active protocolhttp/protocol username/username password/password hostmy.proxy.com/host port80/port nonProxyHostslocalhost|123.456.789.*|my.nexus.host/nonProxyHosts /proxy /proxies Environment: Maven 3.1.1 Mac OS-X 10.9 Also reproduced this issue on: Apache Maven 3.0.4 Ubuntu 11.04 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
JDK 8 : Second Release Candidate - Build 129 is available on java.net
Hi Robert,Kristian, JDK 8 Second Release Candidate , Build 129 is now available for download http://jdk8.java.net/download.html test. Please log all show stopper issues as soon as possible. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: Linkage error
Maybe related to https://jira.codehaus.org/browse/MNG-5513 ? As cdi-api is now also in core? Thanks, ~t~ On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? Kristia n
Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Apologies for posting in a too general mailing list but I could not find a better one. I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
You should use the Maven users mailing list. This list is for developing Maven itself. Info here: http://maven.apache.org/mail-lists.html /Anders On Thu, Feb 13, 2014 at 10:30 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote: Hi Apologies for posting in a too general mailing list but I could not find a better one. I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: Linkage error
It still breaks with 3.1.1; bugger :) 2014-02-13 10:23 GMT+01:00 Tamás Cservenák ta...@cservenak.net: Maybe related to https://jira.codehaus.org/browse/MNG-5513 ? As cdi-api is now also in core? Thanks, ~t~ On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? Kristia n
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
I intentionally used this mailing list since I thought it had to do with the implementation. I will repost in user. Med venlig hilsen Henrik Skriver Rasmussen On Thu, Feb 13, 2014 at 1:51 PM, Anders Hammar and...@hammar.net wrote: You should use the Maven users mailing list. This list is for developing Maven itself. Info here: http://maven.apache.org/mail-lists.html /Anders On Thu, Feb 13, 2014 at 10:30 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote: Hi Apologies for posting in a too general mailing list but I could not find a better one. I have a question about the expected behaviour of the deploy:deploy-file goal in the maven deploy plugin 2.8.1 which I am currently using to deploy one file. It surprised me that no matter what I did I kept getting more artifacts deployed that I asked for and the reason is in the org.apache.maven.plugin.deploy.DeployFileMojo.execute line 376 where the attached artifacts are also deployed. Is this intended behaviour and if so how can I avoid this from happening? The goal name deploy-file indicates that one artifact (possible incl. pom/metadata) is to be deployed and not also a throng of other artifacts. I will be happy to provide a patch where this is aspect is removed. Thank you in advance regards Henrik Skriver Rasmussen
Re: Linkage error
On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
Much as I hate leaking stuff like this, it would appear to me that extending the import (alternative 2) is the correct thing to do. Of course, ifimports.put( javax.enterprise.inject.Typed, coreRealm ); doesn't break any tests we could always start with that. I'll give it a shot tonight. Kristian 2014-02-13 11:56 GMT+01:00 Stuart McCulloch mccu...@gmail.com: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation.. .) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we're really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-plugins pull request: Allow help:evaluate output in quiet mo...
GitHub user zigarn opened a pull request: https://github.com/apache/maven-plugins/pull/17 Allow help:evaluate output in quiet mode (MPH-99) http://jira.codehaus.org/browse/MPH-99 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/maven-plugins MPH-99 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/17.patch commit 8ccdb169ff462ba3a1710a72c918acddecdfb7e4 Author: Alexandre Garnier zigarn+git...@gmail.com Date: 2014-02-13T11:23:00Z Allow help:evaluate output in quiet mode (MPH-99) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Once we get 3.2.x started... how about we try and get a speed up?
So I am thinking that we have gotten into this habit of holding onto changes in core far far too long. I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen
Re: Linkage error
On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable). On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable). Why would we need it? You have any use cases at hand? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Once we get 3.2.x started... how about we try and get a speed up?
I've proposed the shorter vote period and criteria for releasing. I think if the ITs pass and it is for fixes to regressions, changes that we are marking as provisional, or functionality that have no API implications (like improvements to the CLI) I think those point releases can go out as soon as possible. For new features or APIs we will have to support indefinitely, no. This is also all predicated on there being things to release and work being done in the core. It would also help to have the release be fully automated as right now if someone who hadn't done a core release casually tried to do a release I don't think they would have much fun. It's quite tedious. It should be push button. On Feb 13, 2014, at 8:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So I am thinking that we have gotten into this habit of holding onto changes in core far far too long. I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Linkage error
On 13 Feb 2014, at 14:43, Jason van Zyl ja...@takari.io wrote: On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? Hiding this package disables the optional runtime support for @Typed, but does not affect other container features - the container will still load without it. I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable). Why would we need it? You have any use cases at hand? I don’t know if anything in Maven uses it at the moment, it’s mainly to aid migration from Plexus (which always restricted a component's type visibility to its specific role class) to the new JSR330 model where a component’s type visibility is open - ie. it’s visible as any type in its hierarchy - unless you use @Typed to limit it to specific roles. I have some examples where it was useful in migrating legacy Plexus applications, but nothing specific to Maven. On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Once we get 3.2.x started... how about we try and get a speed up?
On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote: I've proposed the shorter vote period and criteria for releasing. I think if the ITs pass and it is for fixes to regressions, changes that we are marking as provisional, or functionality that have no API implications (like improvements to the CLI) I think those point releases can go out as soon as possible. For new features or APIs we will have to support indefinitely, no. That is why I am suggesting the 3.2.x branch only Once we get the first 3.2.x release out I envision we will start on 4.0.x So 3.2.x will really be maintenance mode ;-) We should probably declare all of 2.x end of life... I'd be happy to say 3.0.x is end of life too if others agree... but those are for other votes -Stephen This is also all predicated on there being things to release and work being done in the core. It would also help to have the release be fully automated as right now if someone who hadn't done a core release casually tried to do a release I don't think they would have much fun. It's quite tedious. It should be push button. On Feb 13, 2014, at 8:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So I am thinking that we have gotten into this habit of holding onto changes in core far far too long. I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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
[VOTE] Maven 2.x is end of life
We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
Re: [VOTE] Maven 2.x is end of life
+1 On Thu, Feb 13, 2014 at 10:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
+1 /Anders On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
Re: Once we get 3.2.x started... how about we try and get a speed up?
On Feb 13, 2014, at 10:03 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote: I've proposed the shorter vote period and criteria for releasing. I think if the ITs pass and it is for fixes to regressions, changes that we are marking as provisional, or functionality that have no API implications (like improvements to the CLI) I think those point releases can go out as soon as possible. For new features or APIs we will have to support indefinitely, no. That is why I am suggesting the 3.2.x branch only Once we get the first 3.2.x release out I envision we will start on 4.0.x I plan on continuing some refactoring in the core. I also think with some of the added extension points, and a few more that all the features we want in 4.0 can be a clean superset on 3.x. This was part of the thinking in how 3.x was designed. All the new POM format work can be done with what's currently there, almost everything I can think of can be done. Mixins would be nicer with a small change in the model builder but a form can be done with what's there now. So 3.2.x will really be maintenance mode ;-) We should probably declare all of 2.x end of life... I'd be happy to say 3.0.x is end of life too if others agree... but those are for other votes I don't think we need to EOL it, nor should we. I think most users are on 3.x now but just barely the majority. As I said above I don't think there are any features we want in 4.0 that can be done with extensions to the core. The frequency of releases will happen when more people work on the core. I don't think there is any magic that is going to make releases come out faster. -Stephen This is also all predicated on there being things to release and work being done in the core. It would also help to have the release be fully automated as right now if someone who hadn't done a core release casually tried to do a release I don't think they would have much fun. It's quite tedious. It should be push button. On Feb 13, 2014, at 8:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So I am thinking that we have gotten into this habit of holding onto changes in core far far too long. I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: [VOTE] Maven 2.x is end of life
+1 On Thu, Feb 13, 2014 at 4:30 PM, Anders Hammar and...@hammar.net wrote: +1 /Anders On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
[GitHub] maven-scm pull request: SCM-741: check svn info matches what's in ...
GitHub user Batmat opened a pull request: https://github.com/apache/maven-scm/pull/8 SCM-741: check svn info matches what's in the pom Patch proposition for https://jira.codehaus.org/browse/SCM-741 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/maven-scm SCM-741 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-scm/pull/8.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #8 commit 03b1907a631cb31cbd4943fd1c2ceafe3e400dd6 Author: Baptiste Mathus bat...@batmat.net Date: 2014-02-12T11:17:16Z SCM-741: check svn info matches what's in the pom - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Once we get 3.2.x started... how about we try and get a speed up?
On Thu, Feb 13, 2014 at 10:30 AM, Jason van Zyl ja...@takari.io wrote: On Feb 13, 2014, at 10:03 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote: I've proposed the shorter vote period and criteria for releasing. I think if the ITs pass and it is for fixes to regressions, changes that we are marking as provisional, or functionality that have no API implications (like improvements to the CLI) I think those point releases can go out as soon as possible. For new features or APIs we will have to support indefinitely, no. That is why I am suggesting the 3.2.x branch only Once we get the first 3.2.x release out I envision we will start on 4.0.x I plan on continuing some refactoring in the core. I also think with some of the added extension points, and a few more that all the features we want in 4.0 can be a clean superset on 3.x. This was part of the thinking in how 3.x was designed. All the new POM format work can be done with what's currently there, almost everything I can think of can be done. Mixins would be nicer with a small change in the model builder but a form can be done with what's there now. So 3.2.x will really be maintenance mode ;-) We should probably declare all of 2.x end of life... I'd be happy to say 3.0.x is end of life too if others agree... but those are for other votes I don't think we need to EOL it, nor should we. I think most users are on 3.x now but just barely the majority. As I said above I don't think there are any features we want in 4.0 that can be done with extensions to the core. EOL is an Apache Thing. If we're not going to fix it, it's considered polite to EOL it. The frequency of releases will happen when more people work on the core. I don't think there is any magic that is going to make releases come out faster. -Stephen This is also all predicated on there being things to release and work being done in the core. It would also help to have the release be fully automated as right now if someone who hadn't done a core release casually tried to do a release I don't think they would have much fun. It's quite tedious. It should be push button. On Feb 13, 2014, at 8:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So I am thinking that we have gotten into this habit of holding onto changes in core far far too long. I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Once we get 3.2.x started... how about we try and get a speed up?
On Feb 13, 2014, at 10:38 AM, Benson Margulies bimargul...@gmail.com wrote: EOL is an Apache Thing. If we're not going to fix it, it's considered polite to EOL it. Then I don't see EOL'ing 3.x because 3.x is the base 4.0 will sit on. 4.0 will have new features but a large part of it will be culling all the cruft APIs that have built up that we haven't been very diligent about removing. The frequency of releases will happen when more people work on the core. I don't think there is any magic that is going to make releases come out faster. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Be not afraid of growing slowly, be only afraid of standing still. -- Chinese Proverb
Re: [VOTE] Maven 2.x is end of life
+1 On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
Re: Once we get 3.2.x started... how about we try and get a speed up?
On Feb 13, 2014 10:47 AM, Jason van Zyl ja...@takari.io wrote: On Feb 13, 2014, at 10:38 AM, Benson Margulies bimargul...@gmail.com wrote: EOL is an Apache Thing. If we're not going to fix it, it's considered polite to EOL it. Then I don't see EOL'ing 3.x because 3.x is the base 4.0 will sit on. 4.0 will have new features but a large part of it will be culling all the cruft APIs that have built up that we haven't been very diligent about removing. I don't think anyone meant to suggest a 3.x EOL any time soon. The frequency of releases will happen when more people work on the core. I don't think there is any magic that is going to make releases come out faster. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Be not afraid of growing slowly, be only afraid of standing still. -- Chinese Proverb
Re: [VOTE] Maven 2.x is end of life
+1 (forgot my vote) On 13 February 2014 15:14, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen
Re: [VOTE] Maven 2.x is end of life
+1 (non-binding). Glad to see this vote finally take place. On Thu, Feb 13, 2014 at 9:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 (forgot my vote) On 13 February 2014 15:14, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen -- Cheers, Paul
Re: [VOTE] Maven 2.x is end of life
Stephen Connolly wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. -1 This vote is real-life comedy as long as there is no newer version that succeeds with its core competence to build multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs. Embarassed, Jörg This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
non-binding +1 Gary On Thu, Feb 13, 2014 at 10:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Maven 2.x is end of life
I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... but if there are any committers who want to cut 2.x releases, I - as a PMC member - will certainly stand up and do what is required in terms of testing the source bundle and checking the IP etc... I don't see any committers standing up. If the vote is for EOL and after this vote there is a committer who wants to act as release manager for 2.x, we will not stop them from releasing either... we will just stop putting 2.x on the active downloads page On 13 February 2014 15:52, Jörg Schaible joerg.schai...@swisspost.comwrote: Stephen Connolly wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. -1 This vote is real-life comedy as long as there is no newer version that succeeds with its core competence to build multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs. Embarassed, Jörg This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
On Feb 13, 2014, at 11:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. Well, one more thing: if it’s officially EOL, there is a much higher chance that plugins would be marked as using 3.x as a minimum and will no longer work with 2.1.1. API’s and such that the plugins use will likely get updated to 3.x level. Etc…. Anyway, I’m +1 to dropping 2.x support. Dan You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... but if there are any committers who want to cut 2.x releases, I - as a PMC member - will certainly stand up and do what is required in terms of testing the source bundle and checking the IP etc... I don't see any committers standing up. If the vote is for EOL and after this vote there is a committer who wants to act as release manager for 2.x, we will not stop them from releasing either... we will just stop putting 2.x on the active downloads page On 13 February 2014 15:52, Jörg Schaible joerg.schai...@swisspost.comwrote: Stephen Connolly wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. -1 This vote is real-life comedy as long as there is no newer version that succeeds with its core competence to build multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs. Embarassed, Jörg This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- 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
[GitHub] maven-scm pull request: SCM-741: check svn info matches what's in ...
Github user Batmat closed the pull request at: https://github.com/apache/maven-scm/pull/8 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
Please keep @Typed annotation available outside of core. I use @Typed annotation in one of my (private) core extensions where I need a class to implement an interface but not make that interface visible for injection in other components. -- Regards, Igor On 2/13/2014, 9:43, Jason van Zyl wrote: On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn’t be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI’s @Typed part of the component API like JSR330’s @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it’s own ad-hoc annotation which wouldn’t be as portable). Why would we need it? You have any use cases at hand? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we’re really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Simplex sigillum veri. (Simplicity is the seal
Re: [VOTE] Maven 2.x is end of life
Daniel Kulp wrote: On Feb 13, 2014, at 11:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. Well, one more thing: if it’s officially EOL, there is a much higher chance that plugins would be marked as using 3.x as a minimum and will no longer work with 2.1.1. API’s and such that the plugins use will likely get updated to 3.x level. Etc…. Right. The question is already if 2.2.1 runs on Java 8 or if we have a compatible release plugin that allows us to switch from subversion to git. With EOL of M221 those situations will grow rapidly. Anyway, I’m +1 to dropping 2.x support. I'd switch immediately to a working 3.x version. You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. See above. 2.2.1 can become a dead end faster than wanted. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... What else can we do apart from digging into Maven/Aether code ourselves? Providing an example project and an IT did not help to make any progress. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
+1 from me as well. Kind regards Karl-Heinz Marbaise We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
Wouldn't it make more sense to roll our own version of typed then? Leaking ee stuff from core does not seem like nice thing. Kristian (Who will only touch ee stuff with a pitchfork) 2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Please keep @Typed annotation available outside of core. I use @Typed annotation in one of my (private) core extensions where I need a class to implement an interface but not make that interface visible for injection in other components. -- Regards, Igor On 2/13/2014, 9:43, Jason van Zyl wrote: On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/ PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn't be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI's @Typed part of the component API like JSR330's @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it's own ad-hoc annotation which wouldn't be as portable). Why would we need it? You have any use cases at hand? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/ Instance.html#select(javax.enterprise.util.TypeLiteral,% 20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we're really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,
Fwd: maven-scm - Build # 827 - Failure
Ahem, it's embarassing... :-). The IT I added in the patch is failing, but in its very beginning when it's trying to decrypt the dummy password in the src/it/settings.xml [1] I looked into the issue, and I'm not sure how to solve it (just re-checked, the IT works fine on my machine). Any idea of how to solve this? The simplest solution might be to simply get rid of the server block here [2], but as I cannot test it on the target CI system, would prefer not to propose random commits to try and kill the issue :-). Or maybe this is something that's solveable on the Jenkins job configuration side? Thanks Cheers [1] https://builds.apache.org/job/maven-scm/ws/maven-scm-plugin/target/it/scm-741-validate-scm-url-matches-working-copy/build.log [2] https://github.com/apache/maven-scm/pull/8/files#diff-1154d0ea8f6b5143a055345bf1fae166R24 -- Forwarded message -- From: Apache Jenkins Server jenk...@builds.apache.org Date: 2014-02-13 17:31 GMT+01:00 Subject: maven-scm - Build # 827 - Failure To: notificati...@maven.apache.org, bat...@batmat.net The Apache Jenkins build system has built maven-scm (build #827) Status: Failure Check console output at https://builds.apache.org/job/maven-scm/827/ to view the results.
Re: Linkage error
On 13 Feb 2014, at 17:08, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Wouldn't it make more sense to roll our own version of typed then? Why roll our own when there’s a standard annotation available? I can always add our own version of @Typed under a different package, but that doesn’t seem to encourage re-use. Leaking ee stuff from core does not seem like nice thing. Kristian (Who will only touch ee stuff with a pitchfork) 2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Please keep @Typed annotation available outside of core. I use @Typed annotation in one of my (private) core extensions where I need a class to implement an interface but not make that interface visible for injection in other components. -- Regards, Igor On 2/13/2014, 9:43, Jason van Zyl wrote: On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/ PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn't be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI's @Typed part of the component API like JSR330's @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it's own ad-hoc annotation which wouldn't be as portable). Why would we need it? You have any use cases at hand? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/ Instance.html#select(javax.enterprise.util.TypeLiteral,% 20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we're really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io
Re: [VOTE] Maven 2.x is end of life
Hi Jörg, multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs Maybe you could (re)point out the corresponding JIRAs? Because as a maven user, I wonder what triggers these issues for you. We have tens of multi-projects with interdependencies being currently developed, and I'd be interested to hear about the (problematic) use case we don't encounter. 2014-02-13 18:05 GMT+01:00 Jörg Schaible joerg.schai...@gmx.de: Daniel Kulp wrote: On Feb 13, 2014, at 11:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. Well, one more thing: if it’s officially EOL, there is a much higher chance that plugins would be marked as using 3.x as a minimum and will no longer work with 2.1.1. API’s and such that the plugins use will likely get updated to 3.x level. Etc…. Right. The question is already if 2.2.1 runs on Java 8 or if we have a compatible release plugin that allows us to switch from subversion to git. With EOL of M221 those situations will grow rapidly. Anyway, I’m +1 to dropping 2.x support. I'd switch immediately to a working 3.x version. You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. See above. 2.2.1 can become a dead end faster than wanted. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... What else can we do apart from digging into Maven/Aether code ourselves? Providing an example project and an IT did not help to make any progress. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! dev-h...@maven.apache.org
Re: Linkage error
I don't think there is anything 'ee' about @Typed annotation. I would keep it and would make it the only cdi.jar class exported by the core. -- Regards, Igor On 2/13/2014, 12:08, Kristian Rosenvold wrote: Wouldn't it make more sense to roll our own version of typed then? Leaking ee stuff from core does not seem like nice thing. Kristian (Who will only touch ee stuff with a pitchfork) 2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com: Please keep @Typed annotation available outside of core. I use @Typed annotation in one of my (private) core extensions where I need a class to implement an interface but not make that interface visible for injection in other components. -- Regards, Igor On 2/13/2014, 9:43, Jason van Zyl wrote: On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote: I would consider something like SFL4J as something which is now part of our API think it's fine to expose something like that. I'm not sure the same holds true for CDI. Wouldn't it be better just to completely hide it? As mentioned in http://wiki.eclipse.org/Sisu/ PlexusMigration#Type_Override, the @javax.enterprise.inject.Typed annotation can be used to restrict the type visibility of components. Hiding this package means you wouldn't be able to use this feature outside of Maven core - so I guess it depends whether you consider CDI's @Typed part of the component API like JSR330's @Inject. I would say I don't consider it part of our API, so I'd be inclined to hide it and strictly stick to JSR330. Will Sisu not load without it? I think we keep running into these issues with App Servers because people are trying to run their App Server in Maven's runtime environment which doesn't really make sense. For any of these strange conflicts that arise with SLF4J or other APIs I think we should just encourage people to run any sort of test for your App Server with an environment akin to production in that you should fork once with your own classpath and whatever else you need. Maven's APIs and runtime environment are for build related activities. Where we have this cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should just tell people the best thing to do is fork once and do what you like. The CDI API is at least standardised (one of the reasons why the container respects @Typed rather than creating it's own ad-hoc annotation which wouldn't be as portable). Why would we need it? You have any use cases at hand? On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote: On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Stuart, We're seeing java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name javax/enterprise/util/TypeLiteral using the maven-jetty-plugin on 3.1. I can't really see this seeping through in DefaultClassRealmManager, but google shows me https://java.net/jira/browse/GLASSFISH-20802 Is this something you understand ? DefaultClassRealmManager currently exposes the complete javax.enterprise.inject package from CDI-API: imports.put( javax.enterprise.inject.*, coreRealm ); This package contains annotations, exceptions, and one interface - and it looks like the interface pulls in a type from javax.enterprise.util: http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/ Instance.html#select(javax.enterprise.util.TypeLiteral,% 20java.lang.annotation.Annotation...) Which means that while javax.enterprise.inject.Instance is loaded and exposed from the core realm, javax.enterprise.util.TypeLiteral will be loaded from core but not exposed - this is likely the cause of the constraint violation. There are two solutions - first we could narrow the exposure in DefaultClassRealmManager to: imports.put( javax.enterprise.inject.Typed, coreRealm ); since that is the only CDI annotation we're really interested in, and it has no dependencies to other types. Alternatively we could widen the exposure to include the javax.enterprise.util package: imports.put( javax.enterprise.inject.*, coreRealm ); imports.put( javax.enterprise.util.*, coreRealm ); which should also fix the loader constraint while not introducing other issues. WDYT? 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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: [VOTE] Maven 2.x is end of life
http://jira.codehaus.org/browse/MNG-5207 On 13 February 2014 17:15, Baptiste Mathus m...@batmat.net wrote: Hi Jörg, multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs Maybe you could (re)point out the corresponding JIRAs? Because as a maven user, I wonder what triggers these issues for you. We have tens of multi-projects with interdependencies being currently developed, and I'd be interested to hear about the (problematic) use case we don't encounter. 2014-02-13 18:05 GMT+01:00 Jörg Schaible joerg.schai...@gmx.de: Daniel Kulp wrote: On Feb 13, 2014, at 11:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I suggest you convince at least one of these people: https://people.apache.org/committers-by-project.html#maven that they should act as release manager. EOL just means we will not be making new releases, and it will be moved to the archive section of the downloads. Well, one more thing: if it's officially EOL, there is a much higher chance that plugins would be marked as using 3.x as a minimum and will no longer work with 2.1.1. API's and such that the plugins use will likely get updated to 3.x level. Etc Right. The question is already if 2.2.1 runs on Java 8 or if we have a compatible release plugin that allows us to switch from subversion to git. With EOL of M221 those situations will grow rapidly. Anyway, I'm +1 to dropping 2.x support. I'd switch immediately to a working 3.x version. You will still be able to download it. You will still be able to get the source code. We just will be recognising the fact that there is nobody who wants to cut a release from the 2.x codebase. See above. 2.2.1 can become a dead end faster than wanted. Hopefully focusing on the 3.x codebase will allow us to iron out the bugs you feel are present in 3.x and thus preventing you from migrating... What else can we do apart from digging into Maven/Aether code ourselves? Providing an example project and an IT did not help to make any progress. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
Hi, Stephen Connolly wrote: http://jira.codehaus.org/browse/MNG-5207 On 13 February 2014 17:15, Baptiste Mathus m...@batmat.net wrote: Hi Jörg, multi-projects in correct order and therefore will not produce artifacts with bogus SNAPSHOTs Maybe you could (re)point out the corresponding JIRAs? Because as a maven user, I wonder what triggers these issues for you. We have tens of multi-projects with interdependencies being currently developed, and I'd be interested to hear about the (problematic) use case we don't encounter. The easiest way to detect if you're affected is by removing any SNAPSHOT from your repositories and run a build. If the build stops because SNAPSHOTs cannot be found that are part of your build, the problem is obvious. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: the only show stopper I know is for svn trunk which contains a lot of components so -1 for plugins, shared, skins, resources Why wouldn't you put something with its own release cycle in its own repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level but no problem for me for other release roots containing only one component [1] notice I don't see much gain: did we get much patches for components already in git? did nobody send a patch through github for a svn component replicated to github? Is everybody fluent with git (I still ses much merge commits in git) So what's the rationale, really? (apart from bashing one scm over the other, in one or another direction) The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. what is p4? which component from the 75 previous entries have branches? should require branches? The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) do you mean you intend to contribute to other components than core? As far as potential contribution if you look at Apache projects at Github there are varying numbers of forks and pull requests but for some of them it's pretty significant. But for me it's a primarily a personal workflow issue. So I'm -0 on such a change for parts where I feel it would be feasible Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d ist-tool-check-source-release.html Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and then get infra to use what we converted to do the flip. Jason (who would be happy to never execute svn again) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Convert everything to Git
On 13 February 2014 17:28, Hervé BOUTEMY herve.bout...@free.fr wrote: Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: the only show stopper I know is for svn trunk which contains a lot of components so -1 for plugins, shared, skins, resources Why wouldn't you put something with its own release cycle in its own repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level We should look at getting the literate plugin installed on ASF jenkins once I get it finished... would greatly simplify the job requirements but no problem for me for other release roots containing only one component [1] notice I don't see much gain: did we get much patches for components already in git? did nobody send a patch through github for a svn component replicated to github? Is everybody fluent with git (I still ses much merge commits in git) So what's the rationale, really? (apart from bashing one scm over the other, in one or another direction) The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. what is p4? which component from the 75 previous entries have branches? should require branches? The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) do you mean you intend to contribute to other components than core? As far as potential contribution if you look at Apache projects at Github there are varying numbers of forks and pull requests but for some of them it's pretty significant. But for me it's a primarily a personal workflow issue. So I'm -0 on such a change for parts where I feel it would be feasible Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d ist-tool-check-source-release.html Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and then get infra to use what we converted to do the flip. Jason (who would be happy to never execute svn again) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: [VOTE] Maven 2.x is end of life
+1 Regards, Hervé Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit : We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Linkage error
Well we'll always have the cutoff problem once we start leaking classes we don't really have any control over. Given a fairly marginal use case with probably just 1 user, I think my point is valid. These classes are in the javax.enterprise package space. That's ee to me. Even the modern ee stuff is the pinnacle of all that is wrong about java, but my opinion on this subject is really not the point here. Either way they go in or out. Keeping Typed *in* i going to cause grief down the line, but you ee users are used to that anyway. Kristian Kristian
Re: [VOTE] Maven 2.x is end of life
+1 :-) Am Donnerstag, 13. Februar 2014 schrieb Hervé BOUTEMY : +1 Regards, Hervé Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit : We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: [VOTE] Maven 2.x is end of life
+1 LieGrue, strub On Thursday, 13 February 2014, 18:42, Andreas Gudian andreas.gud...@gmail.com wrote: +1 :-) Am Donnerstag, 13. Februar 2014 schrieb Hervé BOUTEMY : +1 Regards, Hervé Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit : We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: Convert everything to Git
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: the only show stopper I know is for svn trunk which contains a lot of components so -1 for plugins, shared, skins, resources Why wouldn't you put something with its own release cycle in its own repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level I'm used to more granularity in Git, if something has a separate lifecycle it doesn't bother me to have a different repo for it. In the case where there are a bunch of things that have different artifactIds but really only get released together then group those together. I can't speak to what Jenkins can handle. but no problem for me for other release roots containing only one component [1] notice I don't see much gain: did we get much patches for components already in git? did nobody send a patch through github for a svn component replicated to github? Is everybody fluent with git (I still ses much merge commits in git) So what's the rationale, really? (apart from bashing one scm over the other, in one or another direction) The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. what is p4? Perforce. which component from the 75 previous entries have branches? should require branches? For Maven core I have 10 branches locally, I share some of them with others and this is very easy with Git. This is the issue with SVN, it's so cumbersome to make branches and use them no one does. The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) do you mean you intend to contribute to other components than core? I think it would make it easier for anyone to contribute if they wanted to. As far as potential contribution if you look at Apache projects at Github there are varying numbers of forks and pull requests but for some of them it's pretty significant. But for me it's a primarily a personal workflow issue. So I'm -0 on such a change for parts where I feel it would be feasible Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d ist-tool-check-source-release.html Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and then get infra to use what we converted to do the flip. Jason (who would be happy to never execute svn again) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Convert everything to Git
Great posts, Jason! There are so many reasons to dump SVN, but controlled branch sharing and personal work flow are big ones for me, too. I have a dozen or more local branches of my project, too, and like you, I rebase against what I publish until they're ready, then publish them, and rebase the others, etc. It gives you immense power to work freely and experiment and ultimately contribute higher quality material once you finally publish. But I'm clearly preaching to the choir ;-) On Fri, Feb 14, 2014 at 8:29 AM, Jason van Zyl ja...@takari.io wrote: On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: the only show stopper I know is for svn trunk which contains a lot of components so -1 for plugins, shared, skins, resources Why wouldn't you put something with its own release cycle in its own repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level I'm used to more granularity in Git, if something has a separate lifecycle it doesn't bother me to have a different repo for it. In the case where there are a bunch of things that have different artifactIds but really only get released together then group those together. I can't speak to what Jenkins can handle. but no problem for me for other release roots containing only one component [1] notice I don't see much gain: did we get much patches for components already in git? did nobody send a patch through github for a svn component replicated to github? Is everybody fluent with git (I still ses much merge commits in git) So what's the rationale, really? (apart from bashing one scm over the other, in one or another direction) The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. what is p4? Perforce. which component from the 75 previous entries have branches? should require branches? For Maven core I have 10 branches locally, I share some of them with others and this is very easy with Git. This is the issue with SVN, it's so cumbersome to make branches and use them no one does. The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) do you mean you intend to contribute to other components than core? I think it would make it easier for anyone to contribute if they wanted to. As far as potential contribution if you look at Apache projects at Github there are varying numbers of forks and pull requests but for some of them it's pretty significant. But for me it's a primarily a personal workflow issue. So I'm -0 on such a change for parts where I feel it would be feasible Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d ist-tool-check-source-release.html Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and then get infra to use what we converted to do the flip. Jason (who would be happy to never execute svn again) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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,
Re: Convert everything to Git
On 13 February 2014 23:57, Jason van Zyl ja...@takari.io wrote: [del] The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) [del] But for me it's a primarily a personal workflow issue. I'd really appreciate a write up on that workflow. I'm still too green using git and I'd rather follow something that others have thought about and blessed than try to develop that on my own. It would also help people wanting to contribute to focus on contribution rather than version control gymnastics. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Injecting a variable into a resource(-ish) file
Hi,
Please correct me if I'm posting this question to the wrong list.
I'm building a .war using Maven 3.04, and my project source contains a file
src/main/webapp/WEB-INF/xyz.properties. I want the build process to inject
the project version into an entry in that properties file (in the built
artifacts, not in the original source file). I've hit a couple of obstacles.
I tried using resource filtering, putting something like
myProp=${project.version} into that properties file and trying to enable
filtering for that directory:
build
resources
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
/resource
...
But, although I can get filtering to work in src/main/resources, I can't
get it to work in this WEB-INF directory.
My other approach was to write a Maven plugin. I wrote a Mojo that I think
does what I want -- it edits the properties file in the target directory
(i.e., target/myProject/WEB-INF/xyz.properties) -- but I can't find the
right phase to attach my goal to. If I apply it to the package phase,
it's too late; the .war file has already been created with the unmodified
properties. If I apply it to the prepare-package phase, the Mojo doesn't
find a target directory yet.
I'm exploring some uglier options, but I'd appreciate any suggestions.
Thanks,
Josh
Re: [VOTE] Maven 2.x is end of life
On Thu, 13 Feb 2014 15:14:03 + Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 tony. We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.x is end of life
+1 On 14 February 2014 02:14, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We have not made a release of Maven 2.x since 2.2.1 which was August 2009. During that period no release manager has stepped up to cut a release. I would argue that we should just therefore just declare Maven 2.x as end of life. This vote is therefore to resolve this issue. The vote will be decided on the basis of committer votes cast. If the majority of votes from committers (which includes PMC members) are in favour then we will declare 2.x end of life. If you are a committer and voting -1, then we will assume that you are willing to step up and act as a release manager to get a 2.2.2 release out (which would hopefully include being able to not barf on maven-metadata.xml that uses the snapshotVersions schema generated by Maven 3.x but the release manager gets to decide what it is they want to release) The decision on this is actually quite simple as if there is nobody committer to act as a release manager for the 2.x line, then it is end of life. +1: Maven 2.x is end of life, I am not willing to act as release manager for this line of releases 0: I have no opinion -1: Maven 2.x is not end of life, I am willing to act as release manager for this line of releases The vote will be open for 72h and may be closed earlier in the unlikely event that all Maven committers have cast a vote before the 72h are up. -Stephen -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
On 14 Feb 2014, at 2:27, Jason van Zyl wrote: Why wouldn't you put something with its own release cycle in its own repository? maven-release-plugin and git's branching/tagging really kinda make that hard to avoid. Unless we move EVERYTHING to generations :) Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
Jenkins could build from a super-repo that uses git submodule. Since a quite a few versions ago, git-submodules can now follow a branch rather than a fixed SHA1. So you could build/test monolithically, branch/commit individually. Compromise maybe? On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote: each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
On 14 Feb 2014, at 2:27, Jason van Zyl wrote: Why wouldn't you put something with its own release cycle in its own repository? Actually, whilst we're on the subject - can we get a maven-release-plugin out which locks in a newer version of the *-scm-* dependencies as currently, m-r-p BREAKS on current git ( due to git finally changing the output format of git-status ). So we need to config with: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version dependencies dependency groupIdorg.apache.maven.scm/groupId artifactIdmaven-scm-provider-gitexe/artifactId version1.9/version /dependency /dependencies . Not sure if I ever raised a bug for this in Jira or not... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
releasing 3.2.1
Ok, everything is in. Just running through my normal set of tests and I'll try to get 3.2.1 staged later tonight or in the morning. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Convert everything to Git
Le jeudi 13 février 2014 14:29:12 Jason van Zyl a écrit : On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: the only show stopper I know is for svn trunk which contains a lot of components so -1 for plugins, shared, skins, resources Why wouldn't you put something with its own release cycle in its own repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level I'm used to more granularity in Git, if something has a separate lifecycle it doesn't bother me to have a different repo for it. In the case where there are a bunch of things that have different artifactIds but really only get released together then group those together. I can't speak to what Jenkins can handle. yes, I know that this is the good solution if we switch to git I'm just anticipating consequences, since we have 100 release roots, and actual svn structure reduce these as much less svn trunks. I know that with git, the right structure is 100 release roots = 100 git repos. If git repos could be organized in directory structures, like dist area for exemple, Ithis would be better, particularly if the 100 Maven repos were in a maven subdirectory, instead of flat inside Apache git root. And such differences go to ASF Jenkins, and to ASF Sonar. I don't know who will take t his charge the lot of work that such a change will require: having done the work (with a few others) for svnpubsub, and anticipating git migration wil require even more work, I just want to be sure that sufficient energy will be given to the effective switch because sufficient people are convinced there is a real win for the Maven comunity (not only technical facts from git zealots, who are probably right on much points, but just ignore consequences on the whole project) but no problem for me for other release roots containing only one component [1] notice I don't see much gain: did we get much patches for components already in git? did nobody send a patch through github for a svn component replicated to github? Is everybody fluent with git (I still ses much merge commits in git) So what's the rationale, really? (apart from bashing one scm over the other, in one or another direction) The biggest win for me is working on branches. Working with branches in SVN is horrible, only worse in p4 which is saying a lot. what is p4? Perforce. which component from the 75 previous entries have branches? should require branches? For Maven core I have 10 branches locally, I share some of them with others and this is very easy with Git. This is the issue with SVN, it's so cumbersome to make branches and use them no one does. The ability to easily create branches, squash commits, incrementally improve them without fear. I constantly rebase against master and it's really easy with all the great tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse support for Git is a million times better, and doing anything Git related with JGit in Java is always a pleasure (because the #2 CGit guy, wrote JGit) do you mean you intend to contribute to other components than core? I think it would make it easier for anyone to contribute if they wanted to. As far as potential contribution if you look at Apache projects at Github there are varying numbers of forks and pull requests but for some of them it's pretty significant. But for me it's a primarily a personal workflow issue. So I'm -0 on such a change for parts where I feel it would be feasible Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ d ist-tool-check-source-release.html Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : Can we start the process of converting everything to Git. I don't really see any benefit in using Subversion any longer. If so then we should just get together for a day and convert them and then get infra to use what we converted to do the flip. Jason (who would be happy to never execute svn again) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason
Re: Convert everything to Git
I'm not a git expert: if there are solutions, yes, they have to be found, explained, tested, before we launch convert everything to git thank you for any good idea and then any tests from people wanting the great migration to happen (without wreaking havoc) Regards, Hervé Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit : Jenkins could build from a super-repo that uses git submodule. Since a quite a few versions ago, git-submodules can now follow a branch rather than a fixed SHA1. So you could build/test monolithically, branch/commit individually. Compromise maybe? On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote: each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
I have my private git repo setup in a nested way. No reason you couldn't do that the same for this. baseurl/org/apache/mvn/core/componentA.git etc. Unsure if this addresses your concerns or not, but it's certainly neat and tidy at the server end, and the user can duplicate the path structure the same at home. Fred. On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I'm not a git expert: if there are solutions, yes, they have to be found, explained, tested, before we launch convert everything to git thank you for any good idea and then any tests from people wanting the great migration to happen (without wreaking havoc) Regards, Hervé Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit : Jenkins could build from a super-repo that uses git submodule. Since a quite a few versions ago, git-submodules can now follow a branch rather than a fixed SHA1. So you could build/test monolithically, branch/commit individually. Compromise maybe? On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote: each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convert everything to Git
+1 on the submodule solution. We started using it some months ago since the branch option came out. As a simplistic analogy, you can see it as svn: externals equivalent. It helps developers (and ci configuration) to retrieve many related projects in only one clone command. My 2 cents Le 14 févr. 2014 05:10, Mark Derricutt m...@talios.com a écrit : Jenkins could build from a super-repo that uses git submodule. Since a quite a few versions ago, git-submodules can now follow a branch rather than a fixed SHA1. So you could build/test monolithically, branch/commit individually. Compromise maybe? On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote: each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
