Re: [VOTE] Merge Archiva Database Branch to Trunk
+1 option B [ ] Merge the branch into the existing trunk. Nico. 2007/4/26, Joakim Erdfelt [EMAIL PROTECTED]: Lots of work has been done in the archiva database branch in the past 2 months. It has come time to start the merge back into trunk and get the help of others to finish off the work. I wanted to point people to the branch and let them take a look around, and then vote. As I see it we have 3 options. option A [ ] Make the branch the new trunk. option B [ ] Merge the branch into the existing trunk. option C [ ] -1 Do not merge the branch into trunk. I'll wait the usual 72 hours and tabulate the scores. Scores will be tabulated around 1:00am Sunday UTC. I favor option A personally, but I don't know what that will mean to those people that have trunk currently checked out. The Branch: https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor The Good: 1) Completed Integration of JPOX Database into system. 2) Completely overhauled the repository scanning for performance, availability, resilience, and capabilities. 3) Completely overhauled the reporting system for growth and use of the database. The Bad: 1) Admin screens have not yet been converted to the new configuration. (that's a priority for me ATM) 2) Automatic Artifact relocation on proxied requests has not been implemented. 3) Untested. I'm eager to get the other devs involved ASAP. While the vote is going on, I'll be alternating between Redback development and Archiva Admin Screen work. - Joakim Erdfelt
Re: [VOTE] Merge Archiva Database Branch to Trunk
Trygve Laugstøl wrote: Joakim Erdfelt wrote: Lots of work has been done in the archiva database branch in the past 2 months. It has come time to start the merge back into trunk and get the help of others to finish off the work. I wanted to point people to the branch and let them take a look around, and then vote. As I see it we have 3 options. option A [ ] Make the branch the new trunk. option B [ ] Merge the branch into the existing trunk. option C [ ] -1 Do not merge the branch into trunk. I'll wait the usual 72 hours and tabulate the scores. Scores will be tabulated around 1:00am Sunday UTC. I vote for the one that will get an alpha out as soon as possible. Archiva is really missing out on a lot of good customers and thus developers. I am afraid that unless an alpha is kicked out ASAP the development will loose it focus and that it will develop more advanced and/or unnecessary features that needed. My timeline is this ... 1) Get branch merged back into trunk. 2) Allow 1 to 2 weeks to stabilize core functionality. 3) Release 1.0-alpha-1 4) Integrate redback. 5) Work through jira's. 6) Release 1.0-alpha-2 (time since 1.0-alpha-1, about 2 weeks) 7) Work through feature set for 1.0 in http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap 8) Tackle jira's 9) Iterate thru feature set and jiras until we decide it's time for 1.0 (final). - Joakim
Re: [VOTE] Merge Archiva Database Branch to Trunk
I'm testing Nicola's patch on the trunk and I wanted to apply them before the end of the week. I'm not sure that it's a good solution if you merge the branch. Did you have a look if there was a lot of changes in the trunk since you created the branch ? Arnaud On 26/04/07, Maria Odea Ching [EMAIL PROTECTED] wrote: +1 option B [ ] Merge the branch into the existing trunk. Btw, great work on the branch! Count me in for the other issues :) Thanks, Deng Joakim Erdfelt wrote: Lots of work has been done in the archiva database branch in the past 2 months. It has come time to start the merge back into trunk and get the help of others to finish off the work. I wanted to point people to the branch and let them take a look around, and then vote. As I see it we have 3 options. option A [ ] Make the branch the new trunk. option B [ ] Merge the branch into the existing trunk. option C [ ] -1 Do not merge the branch into trunk. I'll wait the usual 72 hours and tabulate the scores. Scores will be tabulated around 1:00am Sunday UTC. I favor option A personally, but I don't know what that will mean to those people that have trunk currently checked out. The Branch: https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor The Good: 1) Completed Integration of JPOX Database into system. 2) Completely overhauled the repository scanning for performance, availability, resilience, and capabilities. 3) Completely overhauled the reporting system for growth and use of the database. The Bad: 1) Admin screens have not yet been converted to the new configuration. (that's a priority for me ATM) 2) Automatic Artifact relocation on proxied requests has not been implemented. 3) Untested. I'm eager to get the other devs involved ASAP. While the vote is going on, I'll be alternating between Redback development and Archiva Admin Screen work. - Joakim Erdfelt !DSPAM:602,462fef3782972047432395!
RE: Dep to same artifact in different versions
Arik Kfir wrote on Wednesday, April 25, 2007 4:15 PM: Doesn't the jmock2 contains the classes of jmock1 as well? No. They should be used side-by-side. And this is a general problem. No project will change their domain/packages and adjust artifact names, simply because Maven cannot handle the situation. The problem has been delayed, since a lot of projects used the transition from M1 to M2 also to adjust their groupId according their domain, but this does obviously not scale. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found: http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 which confirms what I have written above. Greetings Grzegorz Slowikowski Arik Kfir napisał(a): Doesn't the jmock2 contains the classes of jmock1 as well? On 4/25/07, Jörg Schaible [EMAIL PROTECTED] wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 3:26 PM: On 25 Apr 07, at 9:00 AM 25 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? First I'll ask why you are using both versions in one project and then I'll answer your question. Becasue I have 1000 of old unit tests with jMock 1.x, I am switching my project to JDK 5 and write my new unit tests with improved DSL and annotation support of jMock 2.x. No need at all to to convert the 1000 old tests (some might be converted over time). This is exaclty why jMock 1.xand jMock 2.x is designed to be used at the same time. - Jörg BTW: The same problem appears if your deps depend transitively on two development branches of the same artifact, that are classloader compatible (different class names) and might be used at the same time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dep to same artifact in different versions
Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM: Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found: http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 which confirms what I have written above. You simply acknowledge that the problem exists! The fact that jMock will now switch groupId form jmock to org.jmock is exactly driven by this limitation. The first question I received from Nat of jMock was: And what will happoen next time?. And I would rather think about the consequences regarding M2.1 now instead of putting my head into the sand. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
IMO, if the project claims to be backwards-compatible, then it should include the older classes. If they can exist side-by-side, there should be no issue. I see your point, though - I just don't think it is methodology-correct to use different versions of the same project in one place, regardless of the saying that it works, because it just doesn't seem right to me... anyway - just my 2 cents; I have no real objection for Maven to support declaring two dependencies of the same artifact with different version. cheers, Arik. On 4/26/07, Jörg Schaible [EMAIL PROTECTED] wrote: Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM: Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found: http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 which confirms what I have written above. You simply acknowledge that the problem exists! The fact that jMock will now switch groupId form jmock to org.jmock is exactly driven by this limitation. The first question I received from Nat of jMock was: And what will happoen next time?. And I would rather think about the consequences regarding M2.1 now instead of putting my head into the sand. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote: IMO, if the project claims to be backwards-compatible, then it should include the older classes. If they can exist side-by-side, there should be no issue. I don't think you can force every project to do this, and I think that users would intuitively users expect that two versions of, say, junit that are declared should show up. So what Jorg is asking for is not unreasonable and I'm really just trying to think of the repercussions of allowing multiple versions i.e. do we have any plugins keying off special versions of classes: the surefire plugin for example. I think the JMock example is perfectly valid and is something that could be addressed in 2.1 but here is my concern and generally why we took the strategy of not allowing this to begin with: The classpath order is now derived from the order of the listing of the dependencies. So in a particular project what if one case requires class C1 from version 1.0 of JMock, and another case that requires class C1 from version 2.0 of JMock? How are you going to satisfy those two conditions and in general how are you going to protect against classes that have the same name in different versions of the JAR where both are needed?. When this case arises you are going to need a form of paritioning, yes? Because you're going to end up requiring features from the new version which means using the newer classes. If you are going to need some way to say for this group of tests use this version of JMock and for this other set of tests use that version of JMock then you've gotten yourself into a case that cannot be satisfied easy. If projects could guaranteed that version N and the next major upgrade guaranteed compatibility of the intersection of classes in the different versions and additions were a superset of that then adding both versions would be fine. But this is often not the case and you get into real problems because the general rule for major version number changes is that the API can break which means that a class in 2.0 could be significantly different in API and structure then its equivalent in 1.0. In Ant you might create a separate classpath with different JARs and apply that to a different set of classes. We avoid this by simply saying, this is just too complicated and take your tests, create another module that uses the new version of JMock and be done with it. What is easier: creating a separate module which has this simple rule of allowing only one version of a dependency and using all the same patterns of every other type of Maven module. Or allow multiple versions and then start trying to rig up ways to defend against incompatibilities and partitioning sets of classes for use with a particular dependency? I think just making another module is easier. Are you sure you can defend against and cope with the two versions of JMock without any problem? Nat is a bright guy, and is probably very careful about changes between versions but lots of project are not and we decided not to allow multiple versions to protect people from less then stringent practices that generally happen in real life. We tried to make the rules for a single module simple, and make it simple to create new one. It's just so much easier for the rest of the tool chain to understand then trying to deal with the innumerable variations that occurs when multiple anything is allowed: multiple versions, multiple source trees, and multiple artifacts per unit of work which is a POM/module in Maven. That's the not so short answer, but the reason why we do what we do. I know what users expect to happen, but try to think of the counter examples where things might go wrong by using multiple versions in the same module. Jason. I see your point, though - I just don't think it is methodology- correct to use different versions of the same project in one place, regardless of the saying that it works, because it just doesn't seem right to me... anyway - just my 2 cents; I have no real objection for Maven to support declaring two dependencies of the same artifact with different version. cheers, Arik. On 4/26/07, Jörg Schaible [EMAIL PROTECTED] wrote: Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM: Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found: http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 which confirms what I have written above. You simply acknowledge that the problem exists! The fact that jMock will now switch groupId form jmock to org.jmock is exactly driven by this limitation. The first question I received from Nat of jMock was: And what will happoen next time?. And
Re: [VOTE] Merge Archiva Database Branch to Trunk
+1 option B [ ] Merge the branch into the existing trunk. Btw, great work on the branch! Count me in for the other issues :) Thanks, Deng Joakim Erdfelt wrote: Lots of work has been done in the archiva database branch in the past 2 months. It has come time to start the merge back into trunk and get the help of others to finish off the work. I wanted to point people to the branch and let them take a look around, and then vote. As I see it we have 3 options. option A [ ] Make the branch the new trunk. option B [ ] Merge the branch into the existing trunk. option C [ ] -1 Do not merge the branch into trunk. I'll wait the usual 72 hours and tabulate the scores. Scores will be tabulated around 1:00am Sunday UTC. I favor option A personally, but I don't know what that will mean to those people that have trunk currently checked out. The Branch: https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor The Good: 1) Completed Integration of JPOX Database into system. 2) Completely overhauled the repository scanning for performance, availability, resilience, and capabilities. 3) Completely overhauled the reporting system for growth and use of the database. The Bad: 1) Admin screens have not yet been converted to the new configuration. (that's a priority for me ATM) 2) Automatic Artifact relocation on proxied requests has not been implemented. 3) Untested. I'm eager to get the other devs involved ASAP. While the vote is going on, I'll be alternating between Redback development and Archiva Admin Screen work. - Joakim Erdfelt !DSPAM:602,462fef3782972047432395!
RE: Dep to same artifact in different versions
Hi Jason, Jason van Zyl wrote on Thursday, April 26, 2007 1:52 PM: On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote: IMO, if the project claims to be backwards-compatible, then it should include the older classes. If they can exist side-by-side, there should be no issue. I don't think you can force every project to do this, and I think that users would intuitively users expect that two versions of, say, junit that are declared should show up. So what Jorg is asking for is not unreasonable and I'm really just trying to think of the repercussions of allowing multiple versions i.e. do we have any plugins keying off special versions of classes: the surefire plugin for example. I think the JMock example is perfectly valid and is something that could be addressed in 2.1 but here is my concern and generally why we took the strategy of not allowing this to begin with: The classpath order is now derived from the order of the listing of the dependencies. So in a particular project what if one case requires class C1 from version 1.0 of JMock, and another case that requires class C1 from version 2.0 of JMock? How are you going to satisfy those two conditions and in general how are you going to protect against classes that have the same name in different versions of the JAR where both are needed?. When this case arises you are going to need a form of paritioning, yes? Well, Nat *is* a bright guy :) Although both versions share the same root package, they have no overlap in claases itself. It is the perfect case for a slotted artifact - both development branches can be used at same time. And they continue development in both. Because you're going to end up requiring features from the new version which means using the newer classes. If you are going to need some way to say for this group of tests use this version of JMock and for this other set of tests use that version of JMock then you've gotten yourself into a case that cannot be satisfied easy. If projects could guaranteed that version N and the next major upgrade guaranteed compatibility of the intersection of classes in the different versions and additions were a superset of that then adding both versions would be fine. But this is often not the case and you get into real problems because the general rule for major version number changes is that the API can break which means that a class in 2.0 could be significantly different in API and structure then its equivalent in 1.0. If the project does not play nice, Maven cannot help you. Look at the ASM nightmare. Plain CGLIB 2.x depends on ASM 1.x while popular packages like Hibernate-3 or Groovy use ASM 2.x. Unfortunately both ASM versions are not compatible and either you break the artifacts depending on CGLIB or the other ones. CGLIB solved this by the -nodep artifact that contains the necessary ASM 1.x classes with a different package name, but, alas, this is also quite a hack. However, this mess was caused by the ASM project team itself. In Ant you might create a separate classpath with different JARs and apply that to a different set of classes. We avoid this by simply saying, this is just too complicated and take your tests, create another module that uses the new version of JMock and be done with it. What is easier: creating a separate module which has this simple rule of allowing only one version of a dependency and using all the same patterns of every other type of Maven module. Or allow multiple versions and then start trying to rig up ways to defend against incompatibilities and partitioning sets of classes for use with a particular dependency? I think just making another module is easier. Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... Are you sure you can defend against and cope with the two versions of JMock without any problem? Nat is a bright guy, and is probably very careful about changes between versions but lots of project are not and we decided not to allow multiple versions to protect people from less then stringent practices that generally happen in real life. Yep. We tried to make the rules for a single module simple, and make it simple to create new one. It's just so much easier for the rest of the tool chain to understand then trying to deal with the innumerable variations that occurs when multiple anything is allowed: multiple versions, multiple source trees, and multiple artifacts per unit of work which is a POM/module in Maven. That's the not so
RE: Dep to same artifact in different versions
Couldn't you just use shade and/or uber jar to combine into a new one and depend on that? -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 7:52 AM To: Maven Developers List Subject: Re: Dep to same artifact in different versions On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote: IMO, if the project claims to be backwards-compatible, then it should include the older classes. If they can exist side-by-side, there should be no issue. I don't think you can force every project to do this, and I think that users would intuitively users expect that two versions of, say, junit that are declared should show up. So what Jorg is asking for is not unreasonable and I'm really just trying to think of the repercussions of allowing multiple versions i.e. do we have any plugins keying off special versions of classes: the surefire plugin for example. I think the JMock example is perfectly valid and is something that could be addressed in 2.1 but here is my concern and generally why we took the strategy of not allowing this to begin with: The classpath order is now derived from the order of the listing of the dependencies. So in a particular project what if one case requires class C1 from version 1.0 of JMock, and another case that requires class C1 from version 2.0 of JMock? How are you going to satisfy those two conditions and in general how are you going to protect against classes that have the same name in different versions of the JAR where both are needed?. When this case arises you are going to need a form of paritioning, yes? Because you're going to end up requiring features from the new version which means using the newer classes. If you are going to need some way to say for this group of tests use this version of JMock and for this other set of tests use that version of JMock then you've gotten yourself into a case that cannot be satisfied easy. If projects could guaranteed that version N and the next major upgrade guaranteed compatibility of the intersection of classes in the different versions and additions were a superset of that then adding both versions would be fine. But this is often not the case and you get into real problems because the general rule for major version number changes is that the API can break which means that a class in 2.0 could be significantly different in API and structure then its equivalent in 1.0. In Ant you might create a separate classpath with different JARs and apply that to a different set of classes. We avoid this by simply saying, this is just too complicated and take your tests, create another module that uses the new version of JMock and be done with it. What is easier: creating a separate module which has this simple rule of allowing only one version of a dependency and using all the same patterns of every other type of Maven module. Or allow multiple versions and then start trying to rig up ways to defend against incompatibilities and partitioning sets of classes for use with a particular dependency? I think just making another module is easier. Are you sure you can defend against and cope with the two versions of JMock without any problem? Nat is a bright guy, and is probably very careful about changes between versions but lots of project are not and we decided not to allow multiple versions to protect people from less then stringent practices that generally happen in real life. We tried to make the rules for a single module simple, and make it simple to create new one. It's just so much easier for the rest of the tool chain to understand then trying to deal with the innumerable variations that occurs when multiple anything is allowed: multiple versions, multiple source trees, and multiple artifacts per unit of work which is a POM/module in Maven. That's the not so short answer, but the reason why we do what we do. I know what users expect to happen, but try to think of the counter examples where things might go wrong by using multiple versions in the same module. Jason. I see your point, though - I just don't think it is methodology- correct to use different versions of the same project in one place, regardless of the saying that it works, because it just doesn't seem right to me... anyway - just my 2 cents; I have no real objection for Maven to support declaring two dependencies of the same artifact with different version. cheers, Arik. On 4/26/07, Jörg Schaible [EMAIL PROTECTED] wrote: Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM: Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found:
Anyone for MNG-2854?
Hi, may I nag for someone's attention to MNG-2854? This is an issue which could improve Maven's speed for larger projects a real lot. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is the Best practice for generating variations of an artifacts?
Good day, Anybody want to comment on [1]. I think this has already been asked several times, and it would be interesting what the other developers would suggest as the best practice :-) Thanks, Franz [1] http://www.nabble.com/forum/ViewPost.jtp?post=9512947framed=yskin=177 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote: Hi Jason, Jason van Zyl wrote on Thursday, April 26, 2007 1:52 PM: On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote: IMO, if the project claims to be backwards-compatible, then it should include the older classes. If they can exist side-by-side, there should be no issue. I don't think you can force every project to do this, and I think that users would intuitively users expect that two versions of, say, junit that are declared should show up. So what Jorg is asking for is not unreasonable and I'm really just trying to think of the repercussions of allowing multiple versions i.e. do we have any plugins keying off special versions of classes: the surefire plugin for example. I think the JMock example is perfectly valid and is something that could be addressed in 2.1 but here is my concern and generally why we took the strategy of not allowing this to begin with: The classpath order is now derived from the order of the listing of the dependencies. So in a particular project what if one case requires class C1 from version 1.0 of JMock, and another case that requires class C1 from version 2.0 of JMock? How are you going to satisfy those two conditions and in general how are you going to protect against classes that have the same name in different versions of the JAR where both are needed?. When this case arises you are going to need a form of paritioning, yes? Well, Nat *is* a bright guy :) Although both versions share the same root package, they have no overlap in claases itself. It is the perfect case for a slotted artifact - both development branches can be used at same time. And they continue development in both. They don't have to be slotted. Maven does not prevent you from using multiple versions on a system, which is what the slotting approach is for. It's only for a project, and it's technically not hard to admit multiple versions into the processing. This is not a technical problem. Because you're going to end up requiring features from the new version which means using the newer classes. If you are going to need some way to say for this group of tests use this version of JMock and for this other set of tests use that version of JMock then you've gotten yourself into a case that cannot be satisfied easy. If projects could guaranteed that version N and the next major upgrade guaranteed compatibility of the intersection of classes in the different versions and additions were a superset of that then adding both versions would be fine. But this is often not the case and you get into real problems because the general rule for major version number changes is that the API can break which means that a class in 2.0 could be significantly different in API and structure then its equivalent in 1.0. If the project does not play nice, Maven cannot help you. Look at the ASM nightmare. Plain CGLIB 2.x depends on ASM 1.x while popular packages like Hibernate-3 or Groovy use ASM 2.x. Unfortunately both ASM versions are not compatible and either you break the artifacts depending on CGLIB or the other ones. CGLIB solved this by the - nodep artifact that contains the necessary ASM 1.x classes with a different package name, but, alas, this is also quite a hack. However, this mess was caused by the ASM project team itself. I don't think the uber JAR approach works as well as child first loading classloaders so that you can use multiple versions of a library. Much like a webapp where two webapps could easily use different versions of CGLIB. But I think the uber JAR approach where a transitive hull is used to reduce the payload and then mange non- public interfaces is a fine approach. In Ant you might create a separate classpath with different JARs and apply that to a different set of classes. We avoid this by simply saying, this is just too complicated and take your tests, create another module that uses the new version of JMock and be done with it. What is easier: creating a separate module which has this simple rule of allowing only one version of a dependency and using all the same patterns of every other type of Maven module. Or allow multiple versions and then start trying to rig up ways to defend against incompatibilities and partitioning sets of classes for use with a particular dependency? I think just making another module is easier. Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... I don't think we need to introduce the idea of
RE: Dep to same artifact in different versions
Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM: On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote: [snip] Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... I don't think we need to introduce the idea of slots. Allowing multiple versions would suffice. I don't see what the slot concept buys anyone except another term to be familiar with. Well, so how could this work in practice? B-2.2 depends on A-1.0.1 C-1.3 depends on A-2.1 D-1.1 depends on A-1.2 E-1.0 depends on C-2.2 and C-1.3 F-1.0 depends on E-1.0 and A-1.0.1 What do I have to do for E? How does Maven know that A-1.x and A-2.x are both necessary and that it should use A-1.2 and A-2.1? Do I have to add both deps explicitly to E? What does this mean for F? How can I manage in a parent POM the two versions of A in the dependencyManagement? [snip] If your project cannot define the deps directly, the module approach does not work. See the JCL example. Yes, it works if they are separate modules. But as I said above it is not a technical problem to allow multiple versions of JMock for example. At first blush I just see this causing more problems then viable solutions. Well, therefore I refered Gentoo in my first post. They already have been there and found a solution. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the Best practice for generating variations of an artifacts?
Franz Allan Valencia See wrote: Good day, Anybody want to comment on [1]. I think this has already been asked several times, and it would be interesting what the other developers would suggest as the best practice :-) I wrote [1] on the subject a while back. [1] http://blogs.codehaus.org/people/trygvis/archives/001296_building_for_different_environments_with_maven_2.html -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Merge Archiva Database Branch to Trunk
Option C: Tests don't work on windows so I can't test it. When they'll be fixed, I'll be for Option B. Emmanuel Joakim Erdfelt a écrit : Lots of work has been done in the archiva database branch in the past 2 months. It has come time to start the merge back into trunk and get the help of others to finish off the work. I wanted to point people to the branch and let them take a look around, and then vote. As I see it we have 3 options. option A [ ] Make the branch the new trunk. option B [ ] Merge the branch into the existing trunk. option C [ ] -1 Do not merge the branch into trunk. I'll wait the usual 72 hours and tabulate the scores. Scores will be tabulated around 1:00am Sunday UTC. I favor option A personally, but I don't know what that will mean to those people that have trunk currently checked out. The Branch: https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor The Good: 1) Completed Integration of JPOX Database into system. 2) Completely overhauled the repository scanning for performance, availability, resilience, and capabilities. 3) Completely overhauled the reporting system for growth and use of the database. The Bad: 1) Admin screens have not yet been converted to the new configuration. (that's a priority for me ATM) 2) Automatic Artifact relocation on proxied requests has not been implemented. 3) Untested. I'm eager to get the other devs involved ASAP. While the vote is going on, I'll be alternating between Redback development and Archiva Admin Screen work. - Joakim Erdfelt
Re: Dep to same artifact in different versions
On 26 Apr 07, at 10:12 AM 26 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM: On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote: [snip] Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... I don't think we need to introduce the idea of slots. Allowing multiple versions would suffice. I don't see what the slot concept buys anyone except another term to be familiar with. Well, so how could this work in practice? B-2.2 depends on A-1.0.1 C-1.3 depends on A-2.1 D-1.1 depends on A-1.2 E-1.0 depends on C-2.2 and C-1.3 F-1.0 depends on E-1.0 and A-1.0.1 What do I have to do for E? How does Maven know that A-1.x and A-2.x are both necessary and that it should use A-1.2 and A-2.1? Do I have to add both deps explicitly to E? What does this mean for F? How can I manage in a parent POM the two versions of A in the dependencyManagement? The first question to answer is whether we even want to allow this and if the complexity that would arise from situations like this are worth it versus having N modules where each module has a different set of dependencies. What's easier, and what's necessary. Because there exists a solution in Gentoo for doesn't mean it's necessarily the right one for Maven. And because people have these situations in their builds also doesn't necessarily mean it's something ideal. Not saying it's not worth consideration, just playing the devil's advocate. In your case here above then in dependency management we would also support multiple versions where you could specify defaults, and if you needed to override them in the child you would. This translates into multiple version support all the way down in the core. [snip] If your project cannot define the deps directly, the module approach does not work. See the JCL example. Yes, it works if they are separate modules. But as I said above it is not a technical problem to allow multiple versions of JMock for example. At first blush I just see this causing more problems then viable solutions. Well, therefore I refered Gentoo in my first post. They already have been there and found a solution. Yes, as I said this doesn't necessarily translate into an ideal for Maven. My default position now is the distro tools take their notions and wind them all the way down into the core of the distro which doesn't necessarily jive well with Maven. Again I'm not dismissing slots and multiple versions allowable in the POM. Jason. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dep to same artifact in different versions
Jason van Zyl wrote on Thursday, April 26, 2007 4:41 PM: On 26 Apr 07, at 10:12 AM 26 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM: On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote: [snip] Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... I don't think we need to introduce the idea of slots. Allowing multiple versions would suffice. I don't see what the slot concept buys anyone except another term to be familiar with. Well, so how could this work in practice? B-2.2 depends on A-1.0.1 C-1.3 depends on A-2.1 D-1.1 depends on A-1.2 E-1.0 depends on C-2.2 and C-1.3 should have been: E-1.0 depends on B-2.2 and C-1.3 F-1.0 depends on E-1.0 and A-1.0.1 What do I have to do for E? How does Maven know that A-1.x and A-2.x are both necessary and that it should use A-1.2 and A-2.1? Do I have to add both deps explicitly to E? What does this mean for F? How can I manage in a parent POM the two versions of A in the dependencyManagement? The first question to answer is whether we even want to allow this and if the complexity that would arise from situations like this are worth it versus having N modules where each module has a different set of dependencies. What's easier, and what's necessary. Because there exists a solution in Gentoo for doesn't mean it's necessarily the right one for Maven. And because people have these situations in their builds also doesn't necessarily mean it's something ideal. Not saying it's not worth consideration, just playing the devil's advocate. I'm quite sure, nobody sets up something like this at free will. Typically A to at least D are third party artifacts you don't controll, but you have to manage the mess on your end dealing with environments that have themselves no clue about isolated classloaders. At this point your level of tolerance for the build tool tends to zero. ;-) In your case here above then in dependency management we would also support multiple versions where you could specify defaults, and if you needed to override them in the child you would. This translates into multiple version support all the way down in the core. From my naive PoV, it looked easier to introduce a slot that behaves quite like a classifier than implementing support for multiple versions at once. *This* would have scared me much more. However, you're the expert with best knowledge of the internals and you can estimate the impact much better than me. [snip] Yes, as I said this doesn't necessarily translate into an ideal for Maven. My default position now is the distro tools take their notions and wind them all the way down into the core of the distro which doesn't necessarily jive well with Maven. Again I'm not dismissing slots and multiple versions allowable in the POM. I'm quite sure, the topic will rise again. Better to be prepared about the options, especially since M2.1 is not that far away. Anyway, thanks for your time. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
ok, I found why I had Embedded error: duplicate entry:: when I add wagon-ssh as a dependency, I get plexus:plexus-utils as a transitive dependency, which conflicts with org.codehaus.plexus:plexus-utils. Adding excludeplexus:plexus-utils/exclude solved my problem. Then, here are the figures (1.0-beta-2): - wagon-ssh: +169K - wagon-ftp: +255K - wagon-webdav: +593K Including wagon-ssh in Maven Ant Tasks seems to be a good idea. But don't forget the exclude thing... Then it would be nice to: - close MANTTASKS-19: the reporter says it is ok - close MANTTASKS-7: it is fixed in 2.0.6 - close MANTTASKS-43: it is not a Maven bug - commit MANTTASKS-66 patch: not complicated but really usefull - commit MANTTASKS-15 patch? usefull too - look at MANTTASKS-6 patch: this seems a good addition to me I have other patches waiting on other jira issues, but I'm starting with the easiest ones... Hervé Le mardi 24 avril 2007 09:12, Hervé BOUTEMY a écrit : Le lundi 23 avril 2007 22:05, Jason van Zyl a écrit : you mean: artifact:install-provider artifactId=wagon-ssh version=1.0- beta-2/ is not sufficient? and wagon-ftp? and wagon-webdav? Doesn't take much to make it that much easier. ok, why not. I tried to get how many KB each provider would add, to have figures for doesn't take much. But I couldn't: I get an error, either with trunk and 2.0.x branch: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar. Embedded error: duplicate entry: hidden/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.class Do you know what's happening? I would have thought that this was the purpose of the shade version lockdown on 2.0.x branch, but that doesn't seem to work. BTW, the current staged Maven Ant Tasks are a lot better than the actually published 2.0.4 (which are quite buggy): I really think the better is to go with them, and only after that work on enhancements for 2.0.7. Maven 2.0.5 was released on 14/2 and 2.0.6 on 1/4: having a release for Ant Tasks is long awaited. Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
Nice, thanks. I'm doing some Ant (well, a conversion) so I'll take a look as soon as I can. Thanks, Jason. On 26 Apr 07, at 4:45 PM 26 Apr 07, Hervé BOUTEMY wrote: ok, I found why I had Embedded error: duplicate entry:: when I add wagon-ssh as a dependency, I get plexus:plexus-utils as a transitive dependency, which conflicts with org.codehaus.plexus:plexus-utils. Adding excludeplexus:plexus-utils/exclude solved my problem. Then, here are the figures (1.0-beta-2): - wagon-ssh: +169K - wagon-ftp: +255K - wagon-webdav: +593K Including wagon-ssh in Maven Ant Tasks seems to be a good idea. But don't forget the exclude thing... Then it would be nice to: - close MANTTASKS-19: the reporter says it is ok - close MANTTASKS-7: it is fixed in 2.0.6 - close MANTTASKS-43: it is not a Maven bug - commit MANTTASKS-66 patch: not complicated but really usefull - commit MANTTASKS-15 patch? usefull too - look at MANTTASKS-6 patch: this seems a good addition to me I have other patches waiting on other jira issues, but I'm starting with the easiest ones... Hervé Le mardi 24 avril 2007 09:12, Hervé BOUTEMY a écrit : Le lundi 23 avril 2007 22:05, Jason van Zyl a écrit : you mean: artifact:install-provider artifactId=wagon-ssh version=1.0- beta-2/ is not sufficient? and wagon-ftp? and wagon-webdav? Doesn't take much to make it that much easier. ok, why not. I tried to get how many KB each provider would add, to have figures for doesn't take much. But I couldn't: I get an error, either with trunk and 2.0.x branch: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Error creating shaded jar. Embedded error: duplicate entry: hidden/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.class Do you know what's happening? I would have thought that this was the purpose of the shade version lockdown on 2.0.x branch, but that doesn't seem to work. BTW, the current staged Maven Ant Tasks are a lot better than the actually published 2.0.4 (which are quite buggy): I really think the better is to go with them, and only after that work on enhancements for 2.0.7. Maven 2.0.5 was released on 14/2 and 2.0.6 on 1/4: having a release for Ant Tasks is long awaited. Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plexus CommandShell on Windows?
Has anyone had experience with Plexus CommandShell on Windows? I am finding that it is creating a Process like: [cmd, /C, /X, C:\path\to\maven\mvn.bat goal1 goal2] (mvn.bat is quoted because it contains spaces) And that java.lang.Process is throwing an IllegalArgumentException (without any message *grr*) but after stepping through the debugger I see the problem is that Process expects that if an argument is quoted then the whole argument is quoted. So it expects: C:\path\to\maven\mvn.bat goal1 goal2 to be C:\path\to\maven\mvn.bat goal1 goal2 Or alternatively it could be 'C:\path\to\maven\mvn.bat' goal1 goal2 Before I start hacking into code I don't understand, does anyone have experience using this class and is there something that should be done prior to using it in a Windows environment? Shouldn't CommandShell work out how to quote the executable correctly on windows so I don't have to do anything special? Thanks Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plexus CommandShell on Windows?
On 4/27/07, Barrie Treloar [EMAIL PROTECTED] wrote: Has anyone had experience with Plexus CommandShell on Windows? I am finding that it is creating a Process like: [cmd, /C, /X, C:\path\to\maven\mvn.bat goal1 goal2] (mvn.bat is quoted because it contains spaces) And that java.lang.Process is throwing an IllegalArgumentException (without any message *grr*) but after stepping through the debugger I see the problem is that Process expects that if an argument is quoted then the whole argument is quoted. So it expects: C:\path\to\maven\mvn.bat goal1 goal2 to be C:\path\to\maven\mvn.bat goal1 goal2 Or alternatively it could be 'C:\path\to\maven\mvn.bat' goal1 goal2 Before I start hacking into code I don't understand, does anyone have experience using this class and is there something that should be done prior to using it in a Windows environment? Shouldn't CommandShell work out how to quote the executable correctly on windows so I don't have to do anything special? Yes its buggy. See http://jira.codehaus.org/browse/PLXUTILS-31 I want to attach a batch file to the issue to test the problem. Would you mind help out ? I will attach it in a few hours. Then we can fix my proposed patch because it is not complete. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plexus CommandShell on Windows?
On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote: Yes its buggy. See http://jira.codehaus.org/browse/PLXUTILS-31 I want to attach a batch file to the issue to test the problem. Would you mind help out ? I will attach it in a few hours. Then we can fix my proposed patch because it is not complete. Sure. Ping me when you are ready to go. I'll probably have to do it at home over the weekend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Merge Archiva Database Branch to Trunk
On 4/26/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Also, even if we go with option B (which seems to be leading the vote counts so far) the commit messages will not be lost, the svn log should still contain that information (if I'm not mistaken). When I look at 'svn log' for a random part of the nmaven trunk (which Shane has been branching and merging back) I only see: [EMAIL PROTECTED] /cygdrive/c/svn/nmaven/components $ svn log r521824 | sisbell | 2007-03-23 10:37:38 -0700 (Fri, 23 Mar 2007) | 1 line Merge of SI_RUBY branch. r520983 | sisbell | 2007-03-21 12:50:36 -0700 (Wed, 21 Mar 2007) | 1 line Merge of SI_IDE branch to the trunk. I'd have to go over to the branch to look at the individual commits that explain what was changed and why. I'd prefer to have as much of that history as possible available on the Archiva trunk. -- Wendy
