Problems with old and new group id
Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig
Re: Adapting legacy request parameters into new POJO?
Notwithstanding that I find the previous post confusing on many levels, I would discourage this thread from continuing on the Commons list(s), despite the fact that I am the one who brought it up. Morph is not a Commons project and has its own lists. -Matt On 4/14/10, Martin Gainty mgai...@hotmail.com wrote: Hi Folks took a while but i was able to run the morph testcase %MORPH_HOME%\target\classes java -classpath E:\MORPH\morph-1.1.1\target\ classes;%CLASSPATH% net.sf.morph.MorphCommandlineTest log4j:WARN No appenders could be found for logger (net.sf.morph.transform.conver ters.TextToTimeConverter). log4j:WARN Please initialize the log4j system properly. Sun Jan 30 18:51:02 EET 2005 1107103862000 Sun Jan 30 18:51:02 EET 2005 1107103862000 true true true 0 Hint: morph implements Spring framework with generics to instrument the beans classes.. most of the MORPH code uses the Spring 3.0 framework most notably HashMaps and ArrayLists but without required generic type parameters so with strict on the code wont compile I would post the clean code but i'm hearing that EMC bought spring? ..i'll beg off posting any code until i find an Apache Spring site that supports OSS (OpenSource) thanks, Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: mknut...@baselogic.com Date: Tue, 13 Apr 2010 06:20:50 -0400 Subject: Re: Adapting legacy request parameters into new POJO? To: user@commons.apache.org the compiler plugin is implicit in Maven. You should have access to it automatically. But, if the examples are the same as the PDF document, then it is wrong as there is no DelegatingCopier anywhere and that is a main class that is used in that example. So if it is missing, then the examples will not compile anyways. --- Thank You… Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://www.baselogic.com Blog: http://www.baselogic.com/blog/ Linked IN: http://linkedin.com/in/mickknutson Twitter: http://twitter.com/mickknutson Vacation Rental: http://tahoe.baselogic.com --- On Mon, Apr 12, 2010 at 10:28 PM, Martin Gainty mgai...@hotmail.com wrote: for some reason the pom.xml that came with the morph project forgot the maven-compile plugin ( so you cannot compile the examples) here is my pom.xml for morph project _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Problems with old and new group id
I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Adapting legacy request parameters into new POJO?
I tried to subscribe to the Morph list, and the list does not exist anymore. I got a rejection email back. --- Thank You… Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://www.baselogic.com Blog: http://www.baselogic.com/blog/ Linked IN: http://linkedin.com/in/mickknutson Twitter: http://twitter.com/mickknutson Vacation Rental: http://tahoe.baselogic.com --- On Thu, Apr 15, 2010 at 10:18 AM, Matt Benson gudnabr...@gmail.com wrote: Notwithstanding that I find the previous post confusing on many levels, I would discourage this thread from continuing on the Commons list(s), despite the fact that I am the one who brought it up. Morph is not a Commons project and has its own lists. -Matt On 4/14/10, Martin Gainty mgai...@hotmail.com wrote: Hi Folks took a while but i was able to run the morph testcase %MORPH_HOME%\target\classes java -classpath E:\MORPH\morph-1.1.1\target\ classes;%CLASSPATH% net.sf.morph.MorphCommandlineTest log4j:WARN No appenders could be found for logger (net.sf.morph.transform.conver ters.TextToTimeConverter). log4j:WARN Please initialize the log4j system properly. Sun Jan 30 18:51:02 EET 2005 1107103862000 Sun Jan 30 18:51:02 EET 2005 1107103862000 true true true 0 Hint: morph implements Spring framework with generics to instrument the beans classes.. most of the MORPH code uses the Spring 3.0 framework most notably HashMaps and ArrayLists but without required generic type parameters so with strict on the code wont compile I would post the clean code but i'm hearing that EMC bought spring? ..i'll beg off posting any code until i find an Apache Spring site that supports OSS (OpenSource) thanks, Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: mknut...@baselogic.com Date: Tue, 13 Apr 2010 06:20:50 -0400 Subject: Re: Adapting legacy request parameters into new POJO? To: user@commons.apache.org the compiler plugin is implicit in Maven. You should have access to it automatically. But, if the examples are the same as the PDF document, then it is wrong as there is no DelegatingCopier anywhere and that is a main class that is used in that example. So if it is missing, then the examples will not compile anyways. --- Thank You… Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://www.baselogic.com Blog: http://www.baselogic.com/blog/ Linked IN: http://linkedin.com/in/mickknutson Twitter: http://twitter.com/mickknutson Vacation Rental: http://tahoe.baselogic.com --- On Mon, Apr 12, 2010 at 10:28 PM, Martin Gainty mgai...@hotmail.com wrote: for some reason the pom.xml that came with the morph project forgot the maven-compile plugin ( so you cannot compile the examples) here is my pom.xml for morph project _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
RE: Problems with old and new group id
Well the problem is still that the project I depend on (turbine) will still have its velocity.velocity dependency. It does not matter if there is a correct one available, right? And this was just an example. There are lot of other dependencies that create the same problem. /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:21 To: Commons Users List Subject: Re: Problems with old and new group id I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Problems with old and new group id
Well, I'd play around with doing excludes in your maven setup. On Thu, Apr 15, 2010 at 10:31 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Well the problem is still that the project I depend on (turbine) will still have its velocity.velocity dependency. It does not matter if there is a correct one available, right? And this was just an example. There are lot of other dependencies that create the same problem. /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:21 To: Commons Users List Subject: Re: Problems with old and new group id I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
RE: Problems with old and new group id
Ok, I'll do that and hope it won't be too much to manage =) Thanks /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:34 To: Commons Users List Subject: Re: Problems with old and new group id Well, I'd play around with doing excludes in your maven setup. On Thu, Apr 15, 2010 at 10:31 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Well the problem is still that the project I depend on (turbine) will still have its velocity.velocity dependency. It does not matter if there is a correct one available, right? And this was just an example. There are lot of other dependencies that create the same problem. /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:21 To: Commons Users List Subject: Re: Problems with old and new group id I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Problems with old and new group id
I would still ping the velocity list, too. They might have had someone else encounter this already. On Thu, Apr 15, 2010 at 10:47 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Ok, I'll do that and hope it won't be too much to manage =) Thanks /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:34 To: Commons Users List Subject: Re: Problems with old and new group id Well, I'd play around with doing excludes in your maven setup. On Thu, Apr 15, 2010 at 10:31 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Well the problem is still that the project I depend on (turbine) will still have its velocity.velocity dependency. It does not matter if there is a correct one available, right? And this was just an example. There are lot of other dependencies that create the same problem. /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:21 To: Commons Users List Subject: Re: Problems with old and new group id I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[LANG] incompatibility of jar with svn
Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho
Mailing lists page
Why do the Mailin Lists Page have a Post button link if I can't post while not subscribed? -- Wellington B. de Carvalho
RE: Problems with old and new group id
Well, their new releases are according to maven2 standards -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:53 To: Commons Users List Subject: Re: Problems with old and new group id I would still ping the velocity list, too. They might have had someone else encounter this already. On Thu, Apr 15, 2010 at 10:47 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Ok, I'll do that and hope it won't be too much to manage =) Thanks /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:34 To: Commons Users List Subject: Re: Problems with old and new group id Well, I'd play around with doing excludes in your maven setup. On Thu, Apr 15, 2010 at 10:31 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Well the problem is still that the project I depend on (turbine) will still have its velocity.velocity dependency. It does not matter if there is a correct one available, right? And this was just an example. There are lot of other dependencies that create the same problem. /Ludwig -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: den 15 april 2010 16:21 To: Commons Users List Subject: Re: Problems with old and new group id I would suggest you bring this up to the Velocity community: http://velocity.apache.org/contact.html What we would hopefully do here in Apache Commons is that we would change the package name so that there are no naming collisions even if both jars are on the classpath. On Thu, Apr 15, 2010 at 10:14 AM, Ludwig Magnusson lud...@itcatapult.com wrote: Hi! I have a dependency in my project that in turn depends on velocity 1.5. More precisely velocity.velocity (maven 1 layout). However, my project also _directly_ depends on velocity 1.6.3 or, org.apache.velocity.velocity (maven 2 laoyt). Maven doesn't understand that these are different versions of the same artifact. Is there a way to solve this, because now two velocity packages are added to my classpath. It seems like this would be a very common problem with some kind of solution but I can't find information about it. /Ludwig - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
James, Actually, I believe Lang 3 is supposed to be mixed and matched. That is why the package was renamed. What I think we have here are symptoms of an incomplete transition. If we really want mixing/matching, the groupId should be renamed too; otherwise, we should revert the package name. Paul On Thu, Apr 15, 2010 at 11:16 AM, Tom Brito brito@gmail.com wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
The previous version of LANG is still in SVN: http://svn.apache.org/repos/asf/commons/proper/lang/branches/LANG_2_X SVN trunk contains the lang3 code. On 15/04/2010, Tom Brito brito@gmail.com wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
Yes, you can have code that uses both versions in your code. What I meant was that we support the codebase as a whole, publishable unit. We don't expect folks to pick pieces out of different releases and try to combine them. The group id has been renamed to org.apache.commons already (http://svn.apache.org/repos/asf/commons/proper/lang/trunk/pom.xml), so you really can have two different versions in your maven project. One might argue that the artifactId should be commons-lang3 for consistency with later releases, but since we don't have any lang releases in the org.apache.commons group yet, it's not that big of a deal I guess (I'd prefer lang3 in the artifactId too). On Thu, Apr 15, 2010 at 12:20 PM, Paul Benedict pbened...@apache.org wrote: James, Actually, I believe Lang 3 is supposed to be mixed and matched. That is why the package was renamed. What I think we have here are symptoms of an incomplete transition. If we really want mixing/matching, the groupId should be renamed too; otherwise, we should revert the package name. Paul On Thu, Apr 15, 2010 at 11:16 AM, Tom Brito brito@gmail.com wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
Great, Thanks James and sebb. Then all a user needs to do is declare both jars in a POM and things should be fine. Paul On Thu, Apr 15, 2010 at 11:29 AM, James Carman ja...@carmanconsulting.com wrote: Yes, you can have code that uses both versions in your code. What I meant was that we support the codebase as a whole, publishable unit. We don't expect folks to pick pieces out of different releases and try to combine them. The group id has been renamed to org.apache.commons already (http://svn.apache.org/repos/asf/commons/proper/lang/trunk/pom.xml), so you really can have two different versions in your maven project. One might argue that the artifactId should be commons-lang3 for consistency with later releases, but since we don't have any lang releases in the org.apache.commons group yet, it's not that big of a deal I guess (I'd prefer lang3 in the artifactId too). On Thu, Apr 15, 2010 at 12:20 PM, Paul Benedict pbened...@apache.org wrote: James, Actually, I believe Lang 3 is supposed to be mixed and matched. That is why the package was renamed. What I think we have here are symptoms of an incomplete transition. If we really want mixing/matching, the groupId should be renamed too; otherwise, we should revert the package name. Paul On Thu, Apr 15, 2010 at 11:16 AM, Tom Brito brito@gmail.com wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
Hi Tom, Tom Brito wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. The new stuff in 3.x is not binary compatible either. You have to adjust your code in any case, if you want to use it. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
No, they're not supposed to be the same. That's why we changed the package name so that we have more leeway to change things. We don't guarantee backward (or binary) compatibility between major revisions. On Thu, Apr 15, 2010 at 12:44 PM, Tom Brito brito@gmail.com wrote: The trunk and the jar have are different from each other. They aren't suppose to be the same code? And the Branches be the variants (not the Trunk)? -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 1:42 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi Tom, Tom Brito wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. The new stuff in 3.x is not binary compatible either. You have to adjust your code in any case, if you want to use it. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
On Thu, Apr 15, 2010 at 12:37 PM, Paul Benedict pbened...@apache.org wrote: Great, Thanks James and sebb. Then all a user needs to do is declare both jars in a POM and things should be fine. Well, yes, once there's a lang3 release in maven (or you build it on your own into your local repo). - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
Tom Brito wrote: The trunk and the jar have are different from each other. They aren't suppose to be the same code? No. A released jar refers always a special tag in Subversion. And the Branches be the variants (not the Trunk)? Branches are different code lines. There is currently a branch for possible 2.x releases, but it's not for certain that another 2.x release happens. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
RE: [LANG] Having problems with trunk
You need to give your JVM more memory. The settings for each JVM vendor is different. For example, for Sun's JVM on Windows I use: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=128M Check your JVM documentation and experiment with different settings to get your specific set up to work. Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com -Original Message- From: Adrian Crum [mailto:adrian.c...@yahoo.com] Sent: Thursday, April 15, 2010 10:17 To: user@commons.apache.org Subject: [LANG] Having problems with trunk I'm having problems working with the lang trunk. I use mvn package to create the package, and I use mvn site to generate the cobertura reports - which is what I'm focusing on right now. When I tried to run mvn site, the process aborted with a Java out of memory error (heap space). I commented out all but the cobertura reports in the reporting section of the pom.xml file and that got it to work. The cobertura report task keeps aborting with parse errors. It appears that it is choking on certain annotations. Then I noticed the cobertura report was cumulative - each test run would add to the coverage. So, I tried to run mvn clean to clear the report between each test run. That didn't work - the coverage still included test runs before clean. I tried to delete the contents of the target folder manually, but I got an error message saying that the cobertura folder was being used by another user or process. I'm the only user and I couldn't find any processes that were using the folder. After restarting my computer I was able to delete the folder. I don't know what I'm doing wrong. I seem to be having more problems than one would expect. Any help would be greatly appreciated! -Adrian - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
RE: [LANG] Having problems with trunk
Thanks Gary! That solved the out of memory error while running mvn site. The rest of the problems are still there. :-( -Adrian --- On Thu, 4/15/10, Gary Gregory ggreg...@seagullsoftware.com wrote: From: Gary Gregory ggreg...@seagullsoftware.com Subject: RE: [LANG] Having problems with trunk To: Commons Users List user@commons.apache.org Date: Thursday, April 15, 2010, 10:55 AM You need to give your JVM more memory. The settings for each JVM vendor is different. For example, for Sun's JVM on Windows I use: MAVEN_OPTS=-Xmx512M -XX:MaxPermSize=128M Check your JVM documentation and experiment with different settings to get your specific set up to work. Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com -Original Message- From: Adrian Crum [mailto:adrian.c...@yahoo.com] Sent: Thursday, April 15, 2010 10:17 To: user@commons.apache.org Subject: [LANG] Having problems with trunk I'm having problems working with the lang trunk. I use mvn package to create the package, and I use mvn site to generate the cobertura reports - which is what I'm focusing on right now. When I tried to run mvn site, the process aborted with a Java out of memory error (heap space). I commented out all but the cobertura reports in the reporting section of the pom.xml file and that got it to work. The cobertura report task keeps aborting with parse errors. It appears that it is choking on certain annotations. Then I noticed the cobertura report was cumulative - each test run would add to the coverage. So, I tried to run mvn clean to clear the report between each test run. That didn't work - the coverage still included test runs before clean. I tried to delete the contents of the target folder manually, but I got an error message saying that the cobertura folder was being used by another user or process. I'm the only user and I couldn't find any processes that were using the folder. After restarting my computer I was able to delete the folder. I don't know what I'm doing wrong. I seem to be having more problems than one would expect. Any help would be greatly appreciated! -Adrian - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [LANG] incompatibility of jar with svn
You would have the old stuff and the new stuff on the classpath at the same time. On Thu, Apr 15, 2010 at 12:16 PM, Tom Brito brito@gmail.com wrote: But the new svn trunk don't have the lang package, just the lang3. So the code that depends on the old stuff don't work. -- Wellington B. de Carvalho On Thu, Apr 15, 2010 at 12:27 PM, James Carman ja...@carmanconsulting.comwrote: The Commons Lang library isn't intended to be mixed and matched between releases like that. The package is released as a whole. You can't expect to pick stuff out of different releases and then just combine them and somehow expect them to work. The reason the package name is changing is so that the next-generation work on Commons Lang can move forward. This way, even if you still have an old version of Commons Lang in your classpath (because of a third-party dependency) and you want to use Lang3, you can still do it. The code that depends on the old stuff will work just fine and the code that depends on the new stuff will work just fine. On Thu, Apr 15, 2010 at 11:04 AM, Tom Brito brito@gmail.com wrote: Hi all! I would like to know why this incompatibility between the jar file and the svn repository: In the jar file there is the package org.apache.commons.lang; This same package in svn is called org.apache.commons.lang3 As consequence, I can't use code directly from svn, becouse it will not run with the jar. Anyone know why this incompatibility? Thanks! -- Wellington B. de Carvalho - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
