Re: Pluggable Dependency Resolution
Jason, behaviour != implementation ! If someone likes to store his artifacts in a database or taking it from a p4, why not? And actually having a much cleaner interface on our side would be highly welcome! LieGrue, strub --- On Sat, 7/30/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Pluggable Dependency Resolution To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 11:58 PM On Jul 30, 2011, at 7:14 PM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. I think the potential for wreaking havoc would be too high. If it's something that is thought to be generally beneficial we should add it. But how would you stop everyone and their brother from thinking they had a better scheme? They all deploys those schemes and then Maven has to deal with potentially incompatible schemes and the default behaviour becoming meaningless. This is why OSGi has a specification on the scheme and the interpretation and you live with the one way for the sake of it working consistently for everyone. The idea seems appealing but I believe it would make the system too fragile. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. Sure, it's possible. Maven's behavior is setup in the Maven specific RepositorySystemSession: http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemSession.java This describes what the various bits do: http://aether.sonatype.org/introduction.html Right now nothing changes in the session once it starts up, and there are no extension points in our particular session. All I see is problems really. If this were project specific we would have to be able to load the scheme from wherever it came from and then determining whether the scheme or interpretations were the same would be problematic. In your particular case where you want to change something like the behaviour of a bound ... maybe that's less problematic but I think everyone living with one defined behavior and it being augmented as a community would be wiser. In OSGi this doesn't really change now because so many people depend on a very specific behaviour. I don't think this would be a great idea, and I'm not convinced it could even work. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - 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 - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way to separate the current project build infrastructure from the fixed information inherent in tagging the codebase for a release. the projects repositories and issue tracker, are things which can evolve over time, and having them fixed in an immutable pom is bad for users. if we can find some way of fixing that concern then that would be a good thing. #2 is a different beast. i think forcing the osgi scheme on users is bad for users. i could be selfish and say that i no longer work for a telecom company that insists on 5-6 segment version numbers (depends on how you choose to release as to whether one of those segments applies) but forcing 4 segments on those users is wrong. i don't mind making life a little harder for people venturing away from maven's opinionated view, but forcing people to conform to get full functionality is bad for users. where this all fits in is defining which versions fall within a defined range, and how to choose a version from within that range. iirc osgi does allow hinting in regard for which end of the range to favour, but because of its classloading isolation, there is less of a problem for osgi. osgi being designed to solve the 2 dependencies needing conflicting versions of the same dependency problem. i am more willing to view #2 as being something that we should be looking into not being plugable, but instead allow hints to the impl to say which end of the range to favour... closest hint wins (sort of) however we do need a clear separation between exposing that as a maven api and whatever code we have solving that graph for us. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 07:41, Mark Struberg strub...@yahoo.de wrote:
Re: Pluggable Dependency Resolution
oh i forgot to mention. i also think that version comparison rules should be plugable. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 08:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way to separate the current project build infrastructure from the fixed information inherent in tagging the codebase for a release. the projects repositories and issue tracker, are things which can evolve over time, and having them fixed in an immutable pom is bad for users. if we can find some way of fixing that concern then that would be a good thing. #2 is a different beast. i think forcing the osgi scheme on users is bad for users. i could be selfish and say that i no longer work for a telecom company that insists on 5-6 segment version numbers (depends on how you choose to release as to whether one of those segments applies) but forcing 4 segments on those users is wrong. i don't mind making life a little harder for people venturing away from maven's opinionated view, but forcing people to conform to get full functionality is bad for users. where this all fits in is defining which versions fall within a defined range, and how to choose a version from within that range. iirc osgi does allow hinting in regard for which end of the range to favour, but because of its classloading isolation, there is less of a problem for osgi. osgi being designed to solve the 2 dependencies needing conflicting versions of the same dependency problem. i am more willing to view #2 as being something that we should be looking into not being plugable, but instead allow hints to the impl to say which end of the range to favour... closest hint wins (sort of) however we do need a clear separation between exposing that as a maven api and whatever code we have solving that graph for us. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 07:41, Mark Struberg strub...@yahoo.de wrote:
Re: Pluggable Dependency Resolution
It is sort-of possible to plug per-project dependency resolver and this is more or less how Tycho works already (I can provide more details about implementation, if you are interested). The problem is on the consumer end. What dependency resolution logic you expect to apply if standard maven project depends on an artifact built using custom resolver? What if both projects use custom resolvers? So far, we did not find an answer for just two resolution strategies (i.e. maven and tycho/p2/osgi) and I am afraid a general solution for N resolvers simply does not exist. -- Regards, Igor On 11-07-31 3:14 AM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
agree. The OSGi naming schema makes it easier to detect if a version is higher or lower than another. But the trade off is numerous, let alone compatibility with the versions of already existing maven artifacts. LieGrue, strub Just as a side note: The handling of multiple jars in different versions in OSGi sounds cool in theory, but in practice it tends to make your system unstable. This really only works if the dependencies form an unidirectional directed graph and you need to recompile all dependencies downwards or you don't change any public APIs. Just upgrade Eclipse a few times and you see what I mean. After max 10 upgrades, your Eclipse installation is completely messed up as you _will_ get conflicting dependencies which don't work together nicely. --- On Sun, 7/31/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: Pluggable Dependency Resolution To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 7:27 AM i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way to separate the current project build infrastructure from the fixed information inherent in tagging the codebase for a release. the projects repositories and issue tracker, are things which can evolve over time, and having them fixed in an immutable pom is bad for users. if we can find some way of fixing that concern then that would be a good thing. #2 is a different beast. i think forcing the osgi scheme on users is bad for users. i could be selfish and say that i no longer work for a telecom company that insists on 5-6 segment version numbers (depends on how you choose to release as to whether one of those segments applies) but forcing 4 segments on those users is wrong. i don't mind making life a little harder for people venturing away from maven's opinionated view, but forcing people to conform to get full functionality is bad for users. where this all fits in is defining which versions fall within a defined range, and how to choose a version from within that range. iirc osgi does allow hinting in regard for which end of the range to favour, but because of its classloading isolation, there is less of a problem for osgi. osgi being designed to solve the 2 dependencies needing conflicting versions of the same dependency problem. i am more willing to view #2 as being something that we should be looking into not being plugable, but instead allow hints to the impl to say which end of the range to favour... closest hint wins (sort of) however we do need a clear separation between exposing that as a maven api and whatever code we have solving that graph for us. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 07:41, Mark Struberg strub...@yahoo.de wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
Hi Igor! I'm also not sure if it makes sense/works out to apply a different DependencyResolver on per project base. This is also kind of a chicken-egg problem. But I could imaging that this could be done in settings.xml! LieGrue, strub --- On Sun, 7/31/11, Igor Fedorenko i...@ifedorenko.com wrote: From: Igor Fedorenko i...@ifedorenko.com Subject: Re: Pluggable Dependency Resolution To: dev@maven.apache.org Date: Sunday, July 31, 2011, 7:51 AM It is sort-of possible to plug per-project dependency resolver and this is more or less how Tycho works already (I can provide more details about implementation, if you are interested). The problem is on the consumer end. What dependency resolution logic you expect to apply if standard maven project depends on an artifact built using custom resolver? What if both projects use custom resolvers? So far, we did not find an answer for just two resolution strategies (i.e. maven and tycho/p2/osgi) and I am afraid a general solution for N resolvers simply does not exist. -- Regards, Igor On 11-07-31 3:14 AM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - 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: Pluggable Dependency Resolution
Fundamental issue here is having multiple ways to construct dependency dirty DAG and prune the DAG to eliminate conflicts. Resolution starts with artifact A using one strategy and then hits dependency artifact B that uses another strategy. Forcing the same strategy on A and B will almost certainly produce unexpected/undesired results. -- Regards, Igor On 11-07-31 12:11 PM, Mark Struberg wrote: Hi Igor! I'm also not sure if it makes sense/works out to apply a different DependencyResolver on per project base. This is also kind of a chicken-egg problem. But I could imaging that this could be done in settings.xml! LieGrue, strub --- On Sun, 7/31/11, Igor Fedorenkoi...@ifedorenko.com wrote: From: Igor Fedorenkoi...@ifedorenko.com Subject: Re: Pluggable Dependency Resolution To: dev@maven.apache.org Date: Sunday, July 31, 2011, 7:51 AM It is sort-of possible to plug per-project dependency resolver and this is more or less how Tycho works already (I can provide more details about implementation, if you are interested). The problem is on the consumer end. What dependency resolution logic you expect to apply if standard maven project depends on an artifact built using custom resolver? What if both projects use custom resolvers? So far, we did not find an answer for just two resolution strategies (i.e. maven and tycho/p2/osgi) and I am afraid a general solution for N resolvers simply does not exist. -- Regards, Igor On 11-07-31 3:14 AM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
IMHO, it can make sense as a CLI option, to let you try multiple strategies (normal, GUMP-like ie. LATEST, compatibility ie. OLDEST) But I doubt it has a meaning neither at project level nor user level, nor install level. Project level is IMHO impossible, like Igor seems to have tried :) User level or install level is feasible, but I don't find any useful use case, or giving headaches since we must check the strategy installed before trying to analyze anything Regards, Hervé Le dimanche 31 juillet 2011, Mark Struberg a écrit : Hi Igor! I'm also not sure if it makes sense/works out to apply a different DependencyResolver on per project base. This is also kind of a chicken-egg problem. But I could imaging that this could be done in settings.xml! LieGrue, strub --- On Sun, 7/31/11, Igor Fedorenko i...@ifedorenko.com wrote: From: Igor Fedorenko i...@ifedorenko.com Subject: Re: Pluggable Dependency Resolution To: dev@maven.apache.org Date: Sunday, July 31, 2011, 7:51 AM It is sort-of possible to plug per-project dependency resolver and this is more or less how Tycho works already (I can provide more details about implementation, if you are interested). The problem is on the consumer end. What dependency resolution logic you expect to apply if standard maven project depends on an artifact built using custom resolver? What if both projects use custom resolvers? So far, we did not find an answer for just two resolution strategies (i.e. maven and tycho/p2/osgi) and I am afraid a general solution for N resolvers simply does not exist. -- Regards, Igor On 11-07-31 3:14 AM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
I see this one regularly and don't frankly understand the need other than pure theory. Actual version comparison supports every numbering scheme I ever saw in reality. The only choice that has been made that is a pure choice (neither good nor bad, just a choice had to be made) is that unknown qualifiers are considered after known ones [1]. Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? I'm really interested, because in the first case, I need to add support for something new, but only the second needs a pluggable version comparison algorithm Then if we really need this one, we'll have the problem of *where* we should configure the value: project-level is a nightmare if ever really possible, CLI doesn't make sense IMHO, then we have user-level or install level But even at user or install level, I doubt this will be usable Regards, Hervé [1] http://maven.apache.org/ref/3.0.4- SNAPSHOT/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html Le dimanche 31 juillet 2011, Stephen Connolly a écrit : oh i forgot to mention. i also think that version comparison rules should be plugable. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 08:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. 2. the code that computed the dependencies graph. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way to separate the current project build infrastructure from the fixed information inherent in tagging the codebase for a release. the projects repositories and issue tracker, are things which can evolve over time, and having them fixed in an immutable pom is bad for users. if we can find some way of fixing that concern then that would be a good thing. #2 is a different beast. i think forcing the osgi scheme on users is bad for users. i could be selfish and say that i no longer work for a telecom company that insists on 5-6 segment version numbers (depends on how you choose to release as to whether one of those segments applies) but forcing 4 segments on those users is wrong. i don't mind making life a little harder for people venturing away from maven's opinionated view, but forcing people to conform to get full functionality is bad for users. where this all fits in is defining which versions fall within a defined range, and how to choose a version from within that range. iirc osgi does allow hinting in regard for which end of the range to favour, but because of its classloading isolation, there is less of a problem for osgi. osgi being designed to solve the 2 dependencies needing conflicting versions of the same dependency problem. i am more willing to view #2 as being something that we should be looking into not being plugable, but instead allow hints to the impl to say which end of the range to favour... closest hint wins (sort of) however we do need a clear separation between exposing that as a maven api and whatever code we have solving that graph for us. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 07:41, Mark Struberg strub...@yahoo.de wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of 2.5.4 doesn't actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use something higher if you need to. In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected?
Re: Pluggable Dependency Resolution
Le dimanche 31 juillet 2011, Mark Derricutt a écrit : The use case that we originally came with in our discussions revolved around version ranges, ok, that's not a version comparison but version (range) resolution question: version ordering is here to define how artifacts are ordered, then the range has to choose which one is to be used effectively Multiple strategies can make sens here, but we should be careful on how to provide them. This lets the question of pluggable version comparison need: is there a real world example of unwanted version order? Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
Not from any of my use cases no. Mark On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote: This lets the question of pluggable version comparison need: is there a real world example of unwanted version order?
Re: non-reproducible issues on CI
Hi Mark and I spent yesterday trying to figure out what is going on with this failing build. Here are our finding this far for maven-repository-plugin. 1. maven-invoker-plugin is used to install the current artifact (maven-repository-plugin) into a special repository used by the ITs, namely target/it-repo. The ITs are set up with their own repo so that the users local repository is not messed with. 2. maven-repository-collector-plugin is used to resolve the current artifact's (maven-repository-plugin) dependencies from the local repository to target/it-repo. 3. maven-surefire-plugin is used to run the ITs. When doing this it sets a system property maven.repo.local and points that to target/it-repo. When this is run with Maven 3.0.3 on the command line like this: mvn clean verify -Prun-its all is well and the ITs pass. When this is run with Maven 3.0.3 on the command line like this: mvn clean verify -Prun-its -Dmaven.repo.local=/local/repository the build fails because it cannot find maven-repository-plugin in the local repository. This is the way the CI builds are run, but it can be reproduced locally by adding the extra command line parameter. What seems to happening in that the -Dmaven.local.repository command line parameter overrides the system property set for the Surefire Plugin. Thus making maven-surefire-plugin look for maven-repository-plugin in the wrong repository (/local/repository). Does anyone have ideas how we can solve this? On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at
Re: Pluggable Dependency Resolution
ok, in the past i have had discussions with Jason over version range syntax. Jason previously expoused the view that osgi format version numbers is the -only- way to have version numbers, and anything else he would not support. at the time i was working for a company where we had 5 segment version numbers. major.minor.servicepack.patch.build and the reality is that we needed all 5. if version ranges can work with any number of segments, that solves my itch (besides working for a new company without such issues) qualifier sorting is something where i see being opinionated as a value, but number of segments is not. the other case is where you need to change the scheme. rpm has a second field called, iirc epoch. it is integer and increments when you change the version number scheme... if we had provides scope then we just say change G or A coordinates... otherwise we need some epoch like support to version numbering. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 11:19, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 31 juillet 2011, Mark Derricutt a écrit : The use case that we originally came with in our discussions revolved around version ranges, ok, that's not a version comparison but version (range) resolution question: version ordering is here to define how artifacts are ordered, then the range has to choose which one is to be used effectively Multiple strategies can make sens here, but we should be careful on how to provide them. This lets the question of pluggable version comparison need: is there a real world example of unwanted version order? Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote: i see two concerns that need separation. 1. the code that fetches dependencies from wherever they live. Sure, I've known people to change this in many ways. Integration of legacy artifact stores, migration strategies which involve pulling things from SCMs or what have you. Lots of people have modified this that I know of. This can happen in many ways and hasn't done anything too terrible in the places I've seen it implemented. 2. the code that computed the dependencies graph. Right, the specification and interpretation of a version scheme happening in multiple ways I think would be highly problematic. I don't really see much upside to making this pluggable. #1 should be something that is plugable, and in essence could be part of the repositories definitions... in saying that, i think we need a way to separate the current project build infrastructure from the fixed information inherent in tagging the codebase for a release. the projects repositories and issue tracker, are things which can evolve over time, and having them fixed in an immutable pom is bad for users. if we can find some way of fixing that concern then that would be a good thing. #2 is a different beast. i think forcing the osgi scheme on users is bad for users. i could be selfish and say that i no longer work for a telecom company that insists on 5-6 segment version numbers (depends on how you choose to release as to whether one of those segments applies) but forcing 4 segments on those users is wrong. i don't mind making life a little harder for people venturing away from maven's opinionated view, but forcing people to conform to get full functionality is bad for users. where this all fits in is defining which versions fall within a defined range, and how to choose a version from within that range. iirc osgi does allow hinting in regard for which end of the range to favour, but because of its classloading isolation, there is less of a problem for osgi. osgi being designed to solve the 2 dependencies needing conflicting versions of the same dependency problem. i am more willing to view #2 as being something that we should be looking into not being plugable, but instead allow hints to the impl to say which end of the range to favour... closest hint wins (sort of) however we do need a clear separation between exposing that as a maven api and whatever code we have solving that graph for us. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 07:41, Mark Struberg strub...@yahoo.de wrote: Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: Pluggable Dependency Resolution
What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of 2.5.4 doesn't actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use something higher if you need to. In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Pluggable Dependency Resolution
I thought about that too, and actually don't think that there is a general solution. Two examples: * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range. * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib. Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability... LieGrue, strub PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin. --- On Sun, 7/31/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Pluggable Dependency Resolution To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 11:58 AM What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of 2.5.4 doesn't actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use something higher if you need to. In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding SNAPSHOTS* then that would certainly be in my favor. From memory there was a discussion some time ago regarding range resolution excluding -SNAPSHOTs unless the artifacts were also in the current reactor build, from memory the discussion was last stalled around whether to have a command line arg for this, or to introduce something like buildallowExternalSnapshots//build. On 31/07/2011, at 11:58 PM, Jason van Zyl wrote: What if you could find another way to check API compatibility, would you need this at all?
Re: Pluggable Dependency Resolution
On 31 Jul 2011, at 13:15, Mark Struberg wrote: I thought about that too, and actually don't think that there is a general solution. Two examples: * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range. * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib. FYI, those are the two classic provider vs consumer scenarios: http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability... LieGrue, strub PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin. --- On Sun, 7/31/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Pluggable Dependency Resolution To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 11:58 AM What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of 2.5.4 doesn't actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use something higher if you need to. In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? - 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: Pluggable Dependency Resolution
I've been meaning to check out the clirr-plugin - I'll add that to my TODO reading list for the morning. On 1/08/2011, at 12:15 AM, Mark Struberg wrote: PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin.
Re: non-reproducible issues on CI
Had a similar if not same issue while developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg denn...@apache.org:
Re: non-reproducible issues on CI
On 2011-07-31 14:42, Ansgar Konermann wrote:
Had a similar if not same issue while developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg denn...@apache.org:
Thanks for the hint. I have already tried this, but unfortunately it
doesn't work for this use case.
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
That's fine, but I fear only as long as you don't use -Dmaven.repo.local on
your commandline. And exactly that's how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg denn...@apache.org:
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
Mark,
THe problem is this: jenkins gets going using information from the
global settings.xml before any command-line args are processed. So
you've created a monster, as it were. Luckily, there's a job option to
use an alternative settings so long as it's in the svn real estate
that the job knows about. So while you can have infra deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg strub...@yahoo.de wrote:
That's fine, but I fear only as long as you don't use -Dmaven.repo.local on
your commandline. And exactly that's how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg denn...@apache.org:
-
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: non-reproducible issues on CI
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build messages),
nor any detailed info about the setup at the ASF.
Did you understand Dennis' problem description and do have mojo + knowledge how
to fix this on our CI? Our problem is most probably that the current build uses
the -Dmaven.repo.local property to separate local repos for different builds.
I proposed to use a different maven installation just for being able to set the
localRepository. The settings option might as well do, at least worth a try.
Would be really appreciated and a big help if you could take the time and help
us fixing our CI build!
txs and LieGrue,
strub
--- On Sun, 7/31/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 2:49 PM
Mark,
THe problem is this: jenkins gets going using information
from the
global settings.xml before any command-line args are
processed. So
you've created a monster, as it were. Luckily, there's a
job option to
use an alternative settings so long as it's in the svn real
estate
that the job knows about. So while you can have infra
deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg strub...@yahoo.de
wrote:
That's fine, but I fear only as long as you don't use
-Dmaven.repo.local on your commandline. And exactly that's
how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com
wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and
invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg
denn...@apache.org:
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
+1 tested on Maven Core with success Regards, Hervé Le samedi 30 juillet 2011, Dennis Lundberg a écrit : Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName= Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName =Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146st atus=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
not yet perfect, but much better than the previous version ;) +1 LieGrue, strub --- On Sun, 7/31/11, Hervé BOUTEMY herve.bout...@free.fr wrote: From: Hervé BOUTEMY herve.bout...@free.fr Subject: Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1 To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 3:01 PM +1 tested on Maven Core with success Regards, Hervé Le samedi 30 juillet 2011, Dennis Lundberg a écrit : Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName= Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName =Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146st atus=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: non-reproducible issues on CI
If you check a settings.xml into the tree where this job can fetch it,
I will try to go from there.
On Sun, Jul 31, 2011 at 10:58 AM, Mark Struberg strub...@yahoo.de wrote:
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build messages),
nor any detailed info about the setup at the ASF.
Did you understand Dennis' problem description and do have mojo + knowledge
how to fix this on our CI? Our problem is most probably that the current
build uses the -Dmaven.repo.local property to separate local repos for
different builds.
I proposed to use a different maven installation just for being able to set
the localRepository. The settings option might as well do, at least worth a
try.
Would be really appreciated and a big help if you could take the time and
help us fixing our CI build!
txs and LieGrue,
strub
--- On Sun, 7/31/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 2:49 PM
Mark,
THe problem is this: jenkins gets going using information
from the
global settings.xml before any command-line args are
processed. So
you've created a monster, as it were. Luckily, there's a
job option to
use an alternative settings so long as it's in the svn real
estate
that the job knows about. So while you can have infra
deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg strub...@yahoo.de
wrote:
That's fine, but I fear only as long as you don't use
-Dmaven.repo.local on your commandline. And exactly that's
how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com
wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and
invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg
denn...@apache.org:
-
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
-
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
Random errors in parallely executed tests
Hi! While browsing our CI results I saw randomly failing tests. Most of them are caused by starting jetty on a specific port which already is in use by another test. java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) Clearly if 2 unit tests fire up a jetty instance on the same port, then this cannot run in parallel Proposal: What if we add a property in the maven-surefire-plugin to name a semaphore resource? resourceport1080/resource This could be a comma separated list. Surefire will then check if any resource is blocked before scheduling the next test. The problematic part of course is that surefire must communicate this over multiple parallel builds. WDYT? LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Random errors in parallely executed tests
Hello Jetty is normally able to start on a random port. I have fixed that recently in archetype. Imho better solution. Which tests fail for this reason ? -- Olivier send from a mobile Le 31 juil. 2011 17:43, Mark Struberg strub...@yahoo.de a écrit : Hi! While browsing our CI results I saw randomly failing tests. Most of them are caused by starting jetty on a specific port which already is in use by another test. java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) Clearly if 2 unit tests fire up a jetty instance on the same port, then this cannot run in parallel Proposal: What if we add a property in the maven-surefire-plugin to name a semaphore resource? resourceport1080/resource This could be a comma separated list. Surefire will then check if any resource is blocked before scheduling the next test. The problematic part of course is that surefire must communicate this over multiple parallel builds. WDYT? LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Random errors in parallely executed tests
Hi Olivier! Do you have a sample how to incorporate this into our unit tests? I only knew that jetty is able to assign a random port for the stop port, but didn't know that the same exists for the serving port. LieGrue, strub --- On Sun, 7/31/11, Olivier Lamy ol...@apache.org wrote: From: Olivier Lamy ol...@apache.org Subject: Re: Random errors in parallely executed tests To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 3:55 PM Hello Jetty is normally able to start on a random port. I have fixed that recently in archetype. Imho better solution. Which tests fail for this reason ? -- Olivier send from a mobile Le 31 juil. 2011 17:43, Mark Struberg strub...@yahoo.de a écrit : Hi! While browsing our CI results I saw randomly failing tests. Most of them are caused by starting jetty on a specific port which already is in use by another test. java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) Clearly if 2 unit tests fire up a jetty instance on the same port, then this cannot run in parallel Proposal: What if we add a property in the maven-surefire-plugin to name a semaphore resource? resourceport1080/resource This could be a comma separated list. Surefire will then check if any resource is blocked before scheduling the next test. The problematic part of course is that surefire must communicate this over multiple parallel builds. WDYT? LieGrue, strub - 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: Random errors in parallely executed tests
ah, I knew you did something like this but could not find it :) question: ok, random port, but random and guaranteed to success? ie it makes the effort to find an unused port? see r1152587: I chose an arbitrary port we should add this to a FAQ, since this is a common use case Regards, Hervé Le dimanche 31 juillet 2011, Olivier Lamy a écrit : Hello Jetty is normally able to start on a random port. I have fixed that recently in archetype. Imho better solution. Which tests fail for this reason ? -- Olivier send from a mobile Le 31 juil. 2011 17:43, Mark Struberg strub...@yahoo.de a écrit : Hi! While browsing our CI results I saw randomly failing tests. Most of them are caused by starting jetty on a specific port which already is in use by another test. java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) Clearly if 2 unit tests fire up a jetty instance on the same port, then this cannot run in parallel Proposal: What if we add a property in the maven-surefire-plugin to name a semaphore resource? resourceport1080/resource This could be a comma separated list. Surefire will then check if any resource is blocked before scheduling the next test. The problematic part of course is that surefire must communicate this over multiple parallel builds. WDYT? LieGrue, strub - 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: Random errors in parallely executed tests
the build helper has a goal for this. On Jul 31, 2011, at 12:09 PM, Mark Struberg strub...@yahoo.de wrote: Hi Olivier! Do you have a sample how to incorporate this into our unit tests? I only knew that jetty is able to assign a random port for the stop port, but didn't know that the same exists for the serving port. LieGrue, strub --- On Sun, 7/31/11, Olivier Lamy ol...@apache.org wrote: From: Olivier Lamy ol...@apache.org Subject: Re: Random errors in parallely executed tests To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 3:55 PM Hello Jetty is normally able to start on a random port. I have fixed that recently in archetype. Imho better solution. Which tests fail for this reason ? -- Olivier send from a mobile Le 31 juil. 2011 17:43, Mark Struberg strub...@yahoo.de a écrit : Hi! While browsing our CI results I saw randomly failing tests. Most of them are caused by starting jetty on a specific port which already is in use by another test. java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) Clearly if 2 unit tests fire up a jetty instance on the same port, then this cannot run in parallel Proposal: What if we add a property in the maven-surefire-plugin to name a semaphore resource? resourceport1080/resource This could be a comma separated list. Surefire will then check if any resource is blocked before scheduling the next test. The problematic part of course is that surefire must communicate this over multiple parallel builds. WDYT? LieGrue, strub - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Random errors in parallely executed tests
the buildhelper goal is for when you are launching jetty/etc from the pom. or when you need to filter the port into on disk resources. if launching within the test case, just assign it to port 0. a request for port 0 is a request for an unused port in the top 16k (or depending on the os, anywhere above 1024). then you ask the connector what port it bound to. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 18:40, Benson Margulies bimargul...@gmail.com wrote:
Re: Random errors in parallely executed tests
yea, that is good news. Will try to tweak this for all wagon tests too. Do you know since when this works? Is this available in jetty-6.1.26? Btw, when going through our Tests I found lots of tests which do not cleanup the target/local-repo (or similar) before they run. Some of them only work because they work on left-overs from previous tests. This is pretty dangerous and should get fixed asap. I didn't touch them yet because I first like to get the IT on our CI box working again. LieGrue, strub --- On Sun, 7/31/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: Random errors in parallely executed tests To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 6:28 PM the buildhelper goal is for when you are launching jetty/etc from the pom. or when you need to filter the port into on disk resources. if launching within the test case, just assign it to port 0. a request for port 0 is a request for an unused port in the top 16k (or depending on the os, anywhere above 1024). then you ask the connector what port it bound to. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 18:40, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Random errors in parallely executed tests
afaik since always. standard socket.open(port) behaviour when port is 0. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 20:00, Mark Struberg strub...@yahoo.de wrote: yea, that is good news. Will try to tweak this for all wagon tests too. Do you know since when this works? Is this available in jetty-6.1.26? Btw, when going through our Tests I found lots of tests which do not cleanup the target/local-repo (or similar) before they run. Some of them only work because they work on left-overs from previous tests. This is pretty dangerous and should get fixed asap. I didn't touch them yet because I first like to get the IT on our CI box working again. LieGrue, strub --- On Sun, 7/31/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: Random errors in parallely executed tests To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 6:28 PM the buildhelper goal is for when you are launching jetty/etc from the pom. or when you need to filter the port into on disk resources. if launching within the test case, just assign it to port 0. a request for port 0 is a request for an unused port in the top 16k (or depending on the os, anywhere above 1024). then you ask the connector what port it bound to. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 18:40, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
I will re-expose the Sonatype Hudson instances as a point of reference. They
have been running successfully since you guys flipped over to Jenkins. Our
setup can at least serve as some guidance as to what might be wrong with your
setup.
On Jul 31, 2011, at 10:58 AM, Mark Struberg wrote:
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build messages),
nor any detailed info about the setup at the ASF.
Did you understand Dennis' problem description and do have mojo + knowledge
how to fix this on our CI? Our problem is most probably that the current
build uses the -Dmaven.repo.local property to separate local repos for
different builds.
I proposed to use a different maven installation just for being able to set
the localRepository. The settings option might as well do, at least worth a
try.
Would be really appreciated and a big help if you could take the time and
help us fixing our CI build!
txs and LieGrue,
strub
--- On Sun, 7/31/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 2:49 PM
Mark,
THe problem is this: jenkins gets going using information
from the
global settings.xml before any command-line args are
processed. So
you've created a monster, as it were. Luckily, there's a
job option to
use an alternative settings so long as it's in the svn real
estate
that the job knows about. So while you can have infra
deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg strub...@yahoo.de
wrote:
That's fine, but I fear only as long as you don't use
-Dmaven.repo.local on your commandline. And exactly that's
how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com
wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and
invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg
denn...@apache.org:
-
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
-
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
-
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: non-reproducible issues on CI
Hi Jason!
The bugs are fixed already. What we now see are _real_ bugs and they should
fail in your CI system too (can also be reproduced locally).
LieGrue,
strub
--- On Sun, 7/31/11, Jason van Zyl ja...@sonatype.com wrote:
From: Jason van Zyl ja...@sonatype.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 8:41 PM
I will re-expose the Sonatype Hudson
instances as a point of reference. They have been running
successfully since you guys flipped over to Jenkins. Our
setup can at least serve as some guidance as to what might
be wrong with your setup.
On Jul 31, 2011, at 10:58 AM, Mark Struberg wrote:
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from
reading the build messages), nor any detailed info about the
setup at the ASF.
Did you understand Dennis' problem description and do
have mojo + knowledge how to fix this on our CI? Our problem
is most probably that the current build uses the
-Dmaven.repo.local property to separate local repos for
different builds.
I proposed to use a different maven installation just
for being able to set the localRepository. The settings
option might as well do, at least worth a try.
Would be really appreciated and a big help if you
could take the time and help us fixing our CI build!
txs and LieGrue,
strub
--- On Sun, 7/31/11, Benson Margulies bimargul...@gmail.com
wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 2:49 PM
Mark,
THe problem is this: jenkins gets going using
information
from the
global settings.xml before any command-line args
are
processed. So
you've created a monster, as it were. Luckily,
there's a
job option to
use an alternative settings so long as it's in the
svn real
estate
that the job knows about. So while you can have
infra
deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg
strub...@yahoo.de
wrote:
That's fine, but I fear only as long as you
don't use
-Dmaven.repo.local on your commandline. And
exactly that's
how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com
wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on
CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT
phase.
Works for me with surefire-plugin 2.9 and
invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis
Lundberg
denn...@apache.org:
-
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
-
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
-
First, the taking in of scattered particulars under one
Idea,
so that everyone understands what is being talked about ...
Second,
the separation of the Idea into parts, by dividing it at
the joints,
as nature directs, not breaking any limb in half as a bad
carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form
by C. Alexander)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Jenkins is sending more e-mails now
Hi Just a heads up that those of you that are subscribed to notificati...@maven.apache.org will be seeing a lot more e-mails coming your way from Jenkins. I'm going over the configurations for our projects in Jenkins, one parameter at a time. This time I've enabled e-mail notifications for pretty much all of our builds. They are all configured to be sent to notificati...@maven.apache.org, so those of you that are interested in getting direct feedback on how healthy our builds are, now is the time to subscribe. I've also added a JDK 1.7 build of core-integration-testing+maven-3, which passes :-) -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
It turns out that someone had accidently arranged for several projects
to share a workspace, and then to use a private maven repo inside that
workspace, with the predicable disasterous consequences.
However, I'm sure the Sonatype config will be helpful.
On Sun, Jul 31, 2011 at 4:41 PM, Jason van Zyl ja...@sonatype.com wrote:
I will re-expose the Sonatype Hudson instances as a point of reference. They
have been running successfully since you guys flipped over to Jenkins. Our
setup can at least serve as some guidance as to what might be wrong with your
setup.
On Jul 31, 2011, at 10:58 AM, Mark Struberg wrote:
Hi Benson!
Thanks for this information!
I don't have much clue about jenkins (apart from reading the build
messages), nor any detailed info about the setup at the ASF.
Did you understand Dennis' problem description and do have mojo + knowledge
how to fix this on our CI? Our problem is most probably that the current
build uses the -Dmaven.repo.local property to separate local repos for
different builds.
I proposed to use a different maven installation just for being able to set
the localRepository. The settings option might as well do, at least worth a
try.
Would be really appreciated and a big help if you could take the time and
help us fixing our CI build!
txs and LieGrue,
strub
--- On Sun, 7/31/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 2:49 PM
Mark,
THe problem is this: jenkins gets going using information
from the
global settings.xml before any command-line args are
processed. So
you've created a monster, as it were. Luckily, there's a
job option to
use an alternative settings so long as it's in the svn real
estate
that the job knows about. So while you can have infra
deploy a
'special' maven, you don't have to.
--benson
On Sun, Jul 31, 2011 at 10:40 AM, Mark Struberg strub...@yahoo.de
wrote:
That's fine, but I fear only as long as you don't use
-Dmaven.repo.local on your commandline. And exactly that's
how our jenkins was configured.
LieGrue,
strub
--- On Sun, 7/31/11, Ansgar Konermann ansgar.konerm...@googlemail.com
wrote:
From: Ansgar Konermann ansgar.konerm...@googlemail.com
Subject: Re: non-reproducible issues on CI
To: Maven Developers List dev@maven.apache.org
Date: Sunday, July 31, 2011, 12:42 PM
Had a similar if not same issue while
developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and
invoker-plugin
1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg
denn...@apache.org:
-
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
-
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
-
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[notice] Cleaning out a few Jenkins jobs
Hi While going through our jobs in Jenkins [1] I found a couple of jobs that I see no point in having there anymore. These are: 1 core-integration-testing We have other builds for this, and this one has no SCM configured 2 doxia-trunks We have separate build for doxia, doxia-sitetools and doxia-tools 3 maven-plugins-ITs-m2-with-maven-plugin 4 maven-plugins-ITs-m3-with-maven-plugin These two were some kind of experiment by Olivier Lamy 5 mavenVersion Don't know what this does If I don't hear anyone complaining, I'll delete these jobs after one week. [1] https://builds.apache.org/view/M-R/view/Maven/ -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
More POM5 writing
By popular request, I've expanded https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model (and changed its name). It now reflects our recent reflections on attributes, plus some thoughts on namespaces. Please break out your darts and start throwing. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [notice] Cleaning out a few Jenkins jobs
2011/7/31 Dennis Lundberg denn...@apache.org: Hi While going through our jobs in Jenkins [1] I found a couple of jobs that I see no point in having there anymore. These are: 1 core-integration-testing We have other builds for this, and this one has no SCM configured 2 doxia-trunks We have separate build for doxia, doxia-sitetools and doxia-tools 3 maven-plugins-ITs-m2-with-maven-plugin 4 maven-plugins-ITs-m3-with-maven-plugin These two were some kind of experiment by Olivier Lamy Please don't delete those one. This can detect some snapshots dependencies with other jobs (shared scm etc) to automatically schedule a build in case a dependency has been build (and without extra configuration). 5 mavenVersion Don't know what this does If I don't hear anyone complaining, I'll delete these jobs after one week. [1] https://builds.apache.org/view/M-R/view/Maven/ -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy 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: Pluggable Dependency Resolution
What you are suggesting here is something I've been advocating for the last several years - adding provides and requires to poms to indicate versions of things they require that are more granular than the jar. In the example below the driver might support several JDBC versions. Specifying just the groupId, artifactId and the subcomponent version(s) ought to allow Maven to choose the latest (or earliest if desired) version that fulfills those requirements. Likewise, if a managed dependency specifies the version of the artifact and error could be thrown if that artifact doesn't meet the requirements. Ralph On Jul 31, 2011, at 5:15 AM, Mark Struberg wrote: I thought about that too, and actually don't think that there is a general solution. Two examples: * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range. * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib. Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability... LieGrue, strub PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin. --- On Sun, 7/31/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: Pluggable Dependency Resolution To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 11:58 AM What if you could find another way to check API compatibility, would you need this at all? On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of 2.5.4 doesn't actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use something higher if you need to. In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: Do you have practical examples that either are not supported, or the actual ordering is the contrary than you expected? - 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: [DISCUSS] incorporate EPL Aether
On 31/07/2011, at 6:04 AM, Benson Margulies wrote: Kristian, legal-discuss is a public list, with public archives. You can go read these remarks for yourself in the archive. I apologize for assuming that you or anyone else didn't know that. Yes I am a member, but Ralph and I are not quoting any private crap. Note that some Ralph posed a relatively specific legal question to start with, and then it grew and grew into a more complex policy discussion that board members happened to participate in. If you want a clear statement of the board's view, you can ask the board. The board in general would, I bet, rather get a coherent question from the PMC chair in the monthly report, and deal with that, but nothing stops you from sending email to board@ stating your view of the question at hand and asking for clarification. That's all true. I noticed a few people talk about board policy in this thread, and I think it's important to be clear on a couple of things. Board policy is nowhere near as heavy handed as some here may think - in particular, the board does not dictate any technical direction for a project. In the interest of protecting the Foundation, they will however ensure that all legal obligations are being met, that a project has a healthy development community, and that it is aligned with the principles of the ASF. As far as I can tell, these are all the policies relevant to this discussion: http://www.apache.org/legal/src-headers.html#3party http://www.apache.org/legal/resolved.html#category-a http://www.apache.org/legal/resolved.html#category-b http://maven.apache.org/developers/dependency-policies.html The statements made on legal-discuss have some significant weight given who made them, though I don't think they intended them to be ad-hoc policy making on behalf of the board. The comments were not so much policy setting as they are just common sense. Don't risk the project by bringing in a codebase that the main copyright holder doesn't want you to. Don't let a major piece of functionality be developed outside of the project in the first place. I will specifically mention that as a board member myself, my comments on this list should not be treated as a statement from the board unless I've said otherwise :) Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On 31/07/2011, at 4:51 AM, Benson Margulies wrote: Trading more or less insulting public emails with Jason does not qualify under that rubric, in my opinion. Yes, personal attacks have no place here. Coming back after the weekend, I was disappointed with the tone of the thread. Everyone needs to chill out. There is a problem here, but I hope everyone involved is looking for a solution, not a victory. Thanks to those that have made constructive suggestions! Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
On 31/07/2011, at 8:57 AM, Jason van Zyl wrote: Ok, I'll pick up from Ralph's discussion. On Jul 29, 2011, at 1:16 PM, Brett Porter wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time If you can't fork any version of Aether per ASF board guidelines/mandate (I'm only repeating what Ralph said) then what does it matter? And let's say this is not the case, worst case you fork it at Github, make your changes and create a binary. This doesn't hinder you from doing anything if the board changed it's mind on this policy. My preference would certainly be not to fork it but the license affords you that right. I think what has been said is the same in this regard. We can certainly legally fork it, but it's not a great idea. What I'm saying is that, as Maven is a project under the Apache License, it would give us more options if Aether was too. Just one example is If there is an insufficient abstraction and we need to make a customisation, we can pull a class or two in to Maven (even temporarily). That's preferable for everyone than having an unofficial fork at github, or having to replace the whole thing, or having to straddle two projects. I don't want us to be in a situation where we need to exercise the additional rights provided by the license, but that doesn't mean they're not a good thing to have. - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. There's precedent for redistributing EPL at the ASF, and the EPL is commercially friendly. Millions of people use Eclipse, extend Eclipse so I really don't think users have a problem with the EPL. Yes, that's true. I'm not saying we can't accept it at all. It does however impose more conditions than any previous release of Maven, so given the history and current state of things I feel like it would be better to be able to continue to use it under the Apache License. There's also plenty of precedent for dual-licensing at Eclipse - JGit and Jetty come to mind. I don't see what problem has been solved for either project by removing it. If changing it back cools this down and saves us all some time writing mail about hypotheticals, surely that's worth it alone :) - it had the terms of the AL 2.0 when we agreed to incorporate it As I said to Mark things here have changed I prefer in the EPL and what it affords. If I have a choice of organization it's the Eclipse Foundation and the preference is not to dual license. We may not agree about foundations or licenses but our commonality is Maven users. If you believe you can serve them better by forking the code and not joining the Aether project then that's your prerogative. I can't honestly see how that would be, but you're free to do what you like. I can't see what danger Maven would ever be in with Aether being at Eclipse and EPL. Even less if people here chose to be committers on the project. The current count is 6 people here being committers on Aether. The more people from here over there the more likely your requests for change will be incorporated. ... The chances that upstream requests for change are not accepted are close to zero, especially with a bunch of committers here on Aether. This is virtually no different than Plexus and Modello. Kristian made the last set of changes on a Plexus project and released them. I don't know when the last release of Modello happened but I think that was Hervé. I believe that to be true, and to remain the case, but what I believe doesn't matter. I think you should also be listening to the fact that both of those people you mentioned voted -1 until the code was released at Eclipse. I don't want to put words in their mouth (so correct me if I'm wrong), but I interpret that as a sign that even with a low barrier, the current process is not optimal. Going back to your first paragraph above again, I don't want the only options to be join Aether or fork the code. I'd like to fix any Maven bug without having to do those things 99% of the time. It is time to break the cycle of having to straddle projects. If some folks want to participate in Aether because they find that something fun to work on, that's great. I'm glad there's a low barrier. But nobody should be forced to join just because they want to serve Maven users. If that's the case, it's broken and we need to fix it. You've claimed that is possible - others here are saying its not. We should deal with more concrete
Re: Random errors in parallely executed tests
That's correct, but you'll then have to query the content handler object for it's currently running port. I'm going to keep pimping out this solution I built for some clients and open sourced a while back. In one project I have an api for starting up a jetty application server either off of the eclipse compiled classpath or based on a war file found in your target directory (you can implement an interface to construct new methods of application look up). I have some fluent API code I will be pushing in to this soon. Personally I don't believe we should ever be starting jetty from maven pom files, rather that task should be done as part of test start-up, and preferable reused across all tests hitting that app. Which would allow tests to be easily run from with in eclipse (starting the webapp when needed, and allowing hot code replacement when debugging). This just ends up making devs more productive. I've got that capability, as well as retaining complex, reusable testing components through the full test execution here: https://github.com/rexhoffman/test-extensions For the eclipse based mechanism to work, simply add a webapps.properties file to your src/main/resource dir, and the util will pull web-content from src/main/webapp/ or WebContent/ I'll be adding more doc to these in the next couple weeks, but the tests should be good enough examples to get this going if anyone is interested. I will also answer questions. I really, really want to see maven plugins like jetty/tomcat/cassandra/etc die off. A good util package added in to tests to start applications locally prior to testing is more usable, more easily debuggable, and just plain cleaner. A good api on them wouldn't let the developer set a port, but instead only query the randomly selected port. Preventing threading issues like this. File system access should also be carefully managed by a java api used by developers, that prevents garbage being left in target dir or some other resource path that might interfere with other tests. My long winded 2 cents. Oh and I do have a ticket open to push this to central, and these are apache licensed. Feel free to copy. Rex On Sun, Jul 31, 2011 at 1:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: afaik since always. standard socket.open(port) behaviour when port is 0. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 20:00, Mark Struberg strub...@yahoo.de wrote: yea, that is good news. Will try to tweak this for all wagon tests too. Do you know since when this works? Is this available in jetty-6.1.26? Btw, when going through our Tests I found lots of tests which do not cleanup the target/local-repo (or similar) before they run. Some of them only work because they work on left-overs from previous tests. This is pretty dangerous and should get fixed asap. I didn't touch them yet because I first like to get the IT on our CI box working again. LieGrue, strub --- On Sun, 7/31/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: Random errors in parallely executed tests To: Maven Developers List dev@maven.apache.org Date: Sunday, July 31, 2011, 6:28 PM the buildhelper goal is for when you are launching jetty/etc from the pom. or when you need to filter the port into on disk resources. if launching within the test case, just assign it to port 0. a request for port 0 is a request for an unused port in the top 16k (or depending on the os, anywhere above 1024). then you ask the connector what port it bound to. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 31 Jul 2011 18:40, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
+1 -Lukas Dennis Lundberg wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
