Re: [configuration] Roadmap
I agrea with Jörg : having some classes depend on java 1.4 should not make all the lib depend on java 1.4 when possible. This can be handled in maven2 with some compiler configuration (two executions with includes/excludes), just by having some naming convention (or deticated package) for java 1.4classes. 2007/4/19, Jörg Schaible [EMAIL PROTECTED]: Hi Emmanuel, do you think 2.x is worth it simply because of dropping JDK 1.3? You might still introduce Preferences in JCC 1.x - it is simply not usable in JDK 1.3. However, the plan looks good for the addressed topics. - Jörg Emmanuel Bourg wrote on Thursday, April 19, 2007 10:46 AM: Hi, I was thinking lately about the orientation for the next releases. I focused on the design choices, some features like new configurations could be added at any moment. Here is what we could do, feel free to add your points to the list. Commons Configuration 1.5.x Java 1.3 compatible Deprecate everything to be removed in 2.x Backport of bug fixes until Configuration 3 is out Commons Configuration 2.x Java 1.4 compatible API cleanup, but no major refactoring Remove the deprecated methods and classes (HierarchicalXMLConfiguration, ConfigurationFactory ?) Remove the dependency on Commons Logging PreferencesConfiguration, ConfigurationPreferences Implement the Locators ? Add the generic get methods to the Configuration interface Backport of bug fixes after the release of Configuration 3 Commons Configuration 3.x Java 5 compatible New package : org.apache.commons.config Remove the dependency on Commons Collections In deepth refactoring of the API Make all configurations hierarchical by default Nodes are Configurations, like java.util.Preferences Generification of the API Pluggable converters (Morph, Beanutils ?) Emmanuel Bourg - 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: [configuration] Roadmap
I'm using JDK 1.3 with M2 with no issue. To be clear, I'm TARGETING java 1.3 runtime, but my M2 runs over jrockit5. I'm using the compiler bootclasspath to point to SUN java 1.3 rt.jar to ensure compatibility. 2007/4/19, Jörg Schaible [EMAIL PROTECTED]: nicolas de loof wrote on Thursday, April 19, 2007 11:44 AM: I agrea with Jörg : having some classes depend on java 1.4 should not make all the lib depend on java 1.4 when possible. This can be handled in maven2 with some compiler configuration (two executions with includes/excludes), just by having some naming convention (or deticated package) for java 1.4classes. Apart from the fact that using JDK 1.3 with M2 is really a pain ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Roadmap
You're right about beeing easier to have multiple branches for various JRE, but from a user point of view, having the same jar working on java1.3 as minimal but having support for java 1.4 classes and maybe tiger is great. I have the same use case for some common-code in my corporate work. I had to setup such a multi-compiler conf for maven2, but using some simple convention made it work fine (example : java1.4 classes have java14 or jdbc3 prefix.). I'm not sure if testing under multiple JRE with various includes/excludes is possible/simple with maven. This would require not only the rt.jar but a fully installed JRE. If you're interested in such a build process I can give help. 2007/4/19, Emmanuel Bourg [EMAIL PROTECTED]: nicolas de loof a écrit : I agrea with Jörg : having some classes depend on java 1.4 should not make all the lib depend on java 1.4 when possible. This can be handled in maven2 with some compiler configuration (two executions with includes/excludes), just by having some naming convention (or deticated package) for java 1.4classes. I'm a bit reluctant to rely on Maven to manage a mixed build correctly. We have test cases that don't run on Java 1.3 for classes that do work on Java 1.3, it's getting weird. I feel it'll be easier to manage 2 branches than fine tuning Maven to build both Java 1.3 and Java 1.4 versions. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Roadmap
This is not only a pain for OSS. Having to download all Java apis jars from Sun is painfull for any developper. They're not redistributable, and we have to live with this restriction. AFAIK maven doesn't come with an integrated JDK and you had to download and install it yourself, didn't you ? 2007/4/19, Jörg Schaible [EMAIL PROTECTED]: Hi Niclas, nicolas de loof wrote on Thursday, April 19, 2007 11:58 AM: I'm using JDK 1.3 with M2 with no issue. To be clear, I'm TARGETING java 1.3 runtime, but my M2 runs over jrockit5. I'm using the compiler bootclasspath to point to SUN java 1.3 rt.jar to ensure compatibility. Yeah. And where does the JDK 1.3.1_xx RT came from? Everybody will have to put it into his own local repo (or use a provate remote one). For OSS this is a pain. Even more if you actually try to run the tests with a 1.3 JRE. Different story though ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REPOST [attributes 2.2] Missing optional package Extension
Any chance to see a vote for 2.2.1 release to solve this ? Nico. 2007/1/16, Henri Yandell [EMAIL PROTECTED]: If no one else is able to, I'll be looking at this next week along with the IO and Lang releases (if no one moves them on). This week is too busy/lacking my personal laptop/too snowy (hurts cable for some reason). Hen On 1/16/07, nicolas de loof [EMAIL PROTECTED] wrote: Can anyone make a release to solve this ? 2007/1/5, nicolas de loof [EMAIL PROTECTED]: The manifest.mf in SVN contain a Created-By: Apache Maven but I never got maven include such Extension-List in my manifest. The one generated by the maven build don't include them. It seems the maven.jar.manifest.extensions.add option creates those entries in manifest. Maybe this property was set on the debian box used to build attributes 2.2 ? From maven jar plugin doc : maven.jar.manifest.extensions.add : Tells Maven to add extension information to the jar manifest. This can cause some applications to break, so it has been disabled by default. An Implementation-Vendor-Id attribute will be added for each dependency that has a vendorId element set in its properties section. Set to true to enable extension information. Seems using such extension is not recommended... I've used maven (not ant) to build on Windows. I can't test on a Mac. I've checked for 1.4 methods by importing api/compiler/unittest into eclipse and setting JRE to 1.3 : There is no compile requirement for Java 1.4 Maybe those compiler options have been set to allow compilation under Java5 JDK. The ant build.xml contains source=1.4 target=1.4 for the Javac task. I've trie building with source=1.3 target=1.3 and it passed Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED] : On 1/4/07, nicolas de loof [EMAIL PROTECTED] wrote: According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) These are for the Ant build - they're the ones that Maven generated for me. Seem to recall that attributes didn't like building on the Mac, so this was done on a Debian Linux box with Sun 1.4.2 and Maven 1.0.2. Unless manifest.mf is a name convention; they're not used for the Maven build. I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3 . I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties Does it compile under 1.3 for you (using Ant I presume)? I'm wondering why the move to 1.4 was done, maybe there's a call to a 1.4 only method in there somewhere. remove manifest.mf from api sub-project Should be unnecessary. remove dependencies in api/project.xml (as they are only required by compiler) +1. With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Sounds good - once we grok why it was moved to 1.4. Hen - 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: budget
Sorry, wrong recipient ... :'-( Nico. Le 03/04/07, Antonio Petrelli [EMAIL PROTECTED] a écrit : 2007/4/3, nicolas de loof [EMAIL PROTECTED]: Peux tu compter ça dans ton budget : http://www.camif.fr/wwwSurf/pages/multimedia/OffreDuJour.asp?REFERENCE=883272 Ca serait pas mal au fond du placard de l'entrée ? Yeah whatever you say :-P - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
budget
Peux tu compter ça dans ton budget : http://www.camif.fr/wwwSurf/pages/multimedia/OffreDuJour.asp?REFERENCE=883272 Ca serait pas mal au fond du placard de l'entrée ?
Re: Commons-Attributes 2.2 Corrupted Manifest
I already asked for a 2.2.1 release to remove those -Extension in manifest, as they break running my app under tomcat 4. Those libs are only required by the compiler jar, not the api (runtime) jar, tho they can be removed from the manifest. This manifest is hand-writen and is included during the ant build. Building with maven doesn't include it. @see http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg88665.html Nico. 2007/3/6, Jörg Schaible [EMAIL PROTECTED]: Henri Yandell wrote on Monday, March 05, 2007 9:45 PM: On 3/5/07, Leo Sutic [EMAIL PROTECTED] wrote: On 3/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: Leo Sutic wrote: Hi all, the Commons-Attributes 2.2 jars have corrupted manifest.mf files. This is apparently causing a bit of problems for users. The issue is in the extension properties: ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5. jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1 .5.jar As you can see, there are spaces and cr/lfs in the URLs. This causes maven 2 etc. to fail. AFAICS the manifest is OK according the spec (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Name-V alue%20pairs%20and%20Sections) by respecting the line length of 72 bytes. Longer lines violate the manifest ... Heh. Thanks - I had no idea. Well, that explains where those line breaks came from. I guess the ball is in the other court then. I'm aiming to make a 2.2.1 release at some point for this - but low energy towards it currently. The above is good to know, said manifest was generated by a Sun JDK (1.4 I presume) on a Linux box, so nothing out of the ordinary. Is there an issue raised with Maven for this? Don't think so. What exactly is the reported problem? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-Attributes 2.2 Corrupted Manifest
You're right, sorry for this mistake. The maven generated manifest was using a maven option to declare dependencies as extensions-list. this option is not set in the project properties, so it may has been set on the computer used to generate the manifest. According to maven doc This can cause some applications to break, so it has been disabled by default. The project also is configured to use target=1.4. I'm using commons-attributes on java 1.3 and have compiled the 2.2 version on java 1.3without any issue. I did not searched the cvs log to know why it has been set. 2007/3/6, Henri Yandell [EMAIL PROTECTED]: On 3/6/07, nicolas de loof [EMAIL PROTECTED] wrote: I already asked for a 2.2.1 release to remove those -Extension in manifest, as they break running my app under tomcat 4. Those libs are only required by the compiler jar, not the api (runtime) jar, tho they can be removed from the manifest. This manifest is hand-written and is included during the ant build. Building with maven doesn't include it. It isn't hand-written btw. It came from the Maven build and was put in SVN for the Ant build to use. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
That would'nt work anyway If you allready downloaded commons-cc:1.1 and get (maybe transitiviely) a dependency on org.apache.commons:cc:1.2, you will get both in your classpath as maven will not kwon those tow groupIds are for the same artifact. We can't expect maven to reload the 1.1 POM that is allready present in local repository (an other cache/mirror/proxy) We could only expect maven to know from the 1.2 POM that what the old groupId was to establish the two artifacts are same. This requires some changes in the POM format to include a section about artifact history in maven repo. Nico. 2007/2/14, Jörg Schaible [EMAIL PROTECTED]: Hi Carlos, Carlos Sanchez wrote on Wednesday, February 14, 2007 8:25 AM: right a relocate pom for ALL versions is required to avoid duplication on classpath BUT as I said almost everybody will have cached previous versions of commons so they won't see the relocation until they delete local repo and the poms with relocation info get downloaded. Maven should give here better support. If it ever downloads a relocation POM it should keep the relocation information in a separate DB/storage and take it always into account when resolving aritfacts no matter which version. Scenario 1 would be completely the the enough then. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
You need to create a relocation POM for the release that does relocation to avoid hundred users to ask for upload on ibilio. The relocation POM will produce a warning on console for maven users. You can expect users to consider warnings and update groupId. The relocation POM will not be required for N+1 releases. You MAY publish one if you consider not all users had time to update. This is similar to @deprecation warning in code : you can keep old code for some time but users are warned that it will be removed. 2007/2/13, Henri Yandell [EMAIL PROTECTED]: On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Hen, Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM: Second try - having had it explained to me on #maven why relocating is important [so commons-lang:commons-lang 2.1 and org.apache.commons:commons-lang 3.0 are considered the same and a transitive clash can be recognized]. So, second suggestion: We declare a point after which we won't do any more m1 releases. We'll move wholesale over to m2. On that day (or as near as we can), we run a script on all commons-*/ to do the relocation for all of them ( http://maven.apache.org/guides/mini/guide-relocation.html ). I know I'm clueless - so please change this to whatever the clueful one is. I think it's time for us to drop m1 and move to m2. you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. So we're cursed with having to do relocation poms every time we do a release? Is that something we can put in the parent pom? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
I don't understand the distinction you make between scenario 1 and 3 : if new release use a relocation pom under commons-xxx and DOESN'T deploy a jar under this group - maven2 users will get relocated artifact + a warning to update dependencies - maven1 users will not get the new version, may ask for it or only found the POM and will update dependencies am I wrong ? Nico. 2007/2/13, Carlos Sanchez [EMAIL PROTECTED]: oh there's a 3rd option that I even like more 3) make new releases in new groupid, no relocations at all + easiest ;) + users trying to upgrade will need to know that the groupId has changed and act by themselves, so they will be involved, and in case of classpath problems they will know what has changed - it'd be better to wait until a major/minor release so users can get bugfixes easily On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote: you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I'd stick with 1) changing old releases scares me ;) and still doesn't guarantee trouble free upgrades On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote: you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
What in such a scenario : My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2 My pom get transitive commons-xxx-1.1 If I DON't update my POM maven2 will find the relocated artifact and exclude 1.1 - that's fine If 1.1 has no relocated POM, and if I update my POM, maven2 will get both 1.1 and 1.2 as they will not be detected as same artifact This mean a relocated POM for all oldest release is required to avoid duplicated jars in classpath. (am I wrong ?) 2007/2/13, Carlos Sanchez [EMAIL PROTECTED]: scenario 3 is with no relocation pom at all, so users get involved by having to explicitly change the groupId On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote: I don't understand the distinction you make between scenario 1 and 3 : if new release use a relocation pom under commons-xxx and DOESN'T deploy a jar under this group - maven2 users will get relocated artifact + a warning to update dependencies - maven1 users will not get the new version, may ask for it or only found the POM and will update dependencies am I wrong ? Nico. 2007/2/13, Carlos Sanchez [EMAIL PROTECTED]: oh there's a 3rd option that I even like more 3) make new releases in new groupid, no relocations at all + easiest ;) + users trying to upgrade will need to know that the groupId has changed and act by themselves, so they will be involved, and in case of classpath problems they will know what has changed - it'd be better to wait until a major/minor release so users can get bugfixes easily On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote: you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I'd stick with 1) changing old releases scares me ;) and still doesn't guarantee trouble free upgrades On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote: you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
According to this, when relocation projectX for new release N+1 option 1 : making dependency to oldGroupId:N+1 will work, but making dependency to newGroupId:N+1 will introduce duplicate jars issues if other dependencies introduce transitive-dependency to oldGroupId:N option 2 : relocating all POM will fail du to proxies caching / mirror / sync issues and others, so will get duplicate jars issues option 3 : same as 1 All options introduce duplicate jars issues. The only solution I can find should be to have some meta-data in the POM to refer the old groupId, so that maven nows that newGroupId:x is the same artifact as oldGroupId:x 2007/2/14, Jörg Schaible [EMAIL PROTECTED]: Hi Carlos, Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM: you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I don't know whether I should laugh or cry because you offered option 2 at all. I took option 2 and adjusted all the old releases of XStream on the Codehaus repo, but they do not get synced to the public repo, since the space for the relocation POMs is already occupied by the old files. It was you who said, nothing can be done about this. Why should the synchronization of the Apache repo be different to the one of Codehaus? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-237) Contrib : managed reloading strategy
[ https://issues.apache.org/jira/browse/CONFIGURATION-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated CONFIGURATION-237: -- Attachment: howto-filebased.patch documentation patch Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: https://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Fix For: 1.5 Attachments: CONFIGURATION-237.patch, howto-filebased.patch, ManagedReloadingStrategyTest.java This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
I've attached a doc path for howto-filbased.xml that describes ManagedReloadingStrategy and give a spring-JMX sample. 2007/2/11, nicolas de loof [EMAIL PROTECTED]: OK, I'll look at user guide to add some doc and attach it to Jira. 2007/2/10, Oliver Heger [EMAIL PROTECTED]: nicolas de loof wrote: could CONFIGURATION-237 be considered for this release ? Well, we can add these classes to the release, but I would prefer to have some more documentation for it. Would it be possible for you to provide a usage example, either in the header comment of the classes or in a new section of the user guide? OTOH reloading will probably be one of the main focuses of the next release. Oliver 2007/2/9, Henri Yandell [EMAIL PROTECTED]: 1.4 is missing from the downloads page. Couple of checkstyle errors (no idea if they matter). Minor nitpick on the Runtime Dependencies page - 'couple' means 2, not 7 :) Clirr in the xml format is even less readable than the txt format - -s text RELEASE_NOTES.txt has an odd character between 'first' and 'whether' Unpacking the source, the ant and m1 builds work fine, but the m2 build fails because it can't find: javax.sql:jdbc-stdext:jar:2.0 Hen On 2/7/07, Oliver Heger [EMAIL PROTECTED] wrote: The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/http://people.apache.org/%7Eoheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver - 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]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
OK, I'll look at user guide to add some doc and attach it to Jira. 2007/2/10, Oliver Heger [EMAIL PROTECTED]: nicolas de loof wrote: could CONFIGURATION-237 be considered for this release ? Well, we can add these classes to the release, but I would prefer to have some more documentation for it. Would it be possible for you to provide a usage example, either in the header comment of the classes or in a new section of the user guide? OTOH reloading will probably be one of the main focuses of the next release. Oliver 2007/2/9, Henri Yandell [EMAIL PROTECTED]: 1.4 is missing from the downloads page. Couple of checkstyle errors (no idea if they matter). Minor nitpick on the Runtime Dependencies page - 'couple' means 2, not 7 :) Clirr in the xml format is even less readable than the txt format - -s text RELEASE_NOTES.txt has an odd character between 'first' and 'whether' Unpacking the source, the ant and m1 builds work fine, but the m2 build fails because it can't find: javax.sql:jdbc-stdext:jar:2.0 Hen On 2/7/07, Oliver Heger [EMAIL PROTECTED] wrote: The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver - 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]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
could CONFIGURATION-237 be considered for this release ? 2007/2/9, Henri Yandell [EMAIL PROTECTED]: 1.4 is missing from the downloads page. Couple of checkstyle errors (no idea if they matter). Minor nitpick on the Runtime Dependencies page - 'couple' means 2, not 7 :) Clirr in the xml format is even less readable than the txt format - -s text RELEASE_NOTES.txt has an odd character between 'first' and 'whether' Unpacking the source, the ant and m1 builds work fine, but the m2 build fails because it can't find: javax.sql:jdbc-stdext:jar:2.0 Hen On 2/7/07, Oliver Heger [EMAIL PROTECTED] wrote: The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver - 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: REPOST [attributes 2.2] Missing optional package Extension
Can anyone make a release to solve this ? 2007/1/5, nicolas de loof [EMAIL PROTECTED]: The manifest.mf in SVN contain a Created-By: Apache Maven but I never got maven include such Extension-List in my manifest. The one generated by the maven build don't include them. It seems the maven.jar.manifest.extensions.add option creates those entries in manifest. Maybe this property was set on the debian box used to build attributes 2.2 ? From maven jar plugin doc : maven.jar.manifest.extensions.add : Tells Maven to add extension information to the jar manifest. This can cause some applications to break, so it has been disabled by default. An Implementation-Vendor-Id attribute will be added for each dependency that has a vendorId element set in its properties section. Set to true to enable extension information. Seems using such extension is not recommended... I've used maven (not ant) to build on Windows. I can't test on a Mac. I've checked for 1.4 methods by importing api/compiler/unittest into eclipse and setting JRE to 1.3 : There is no compile requirement for Java 1.4 Maybe those compiler options have been set to allow compilation under Java5 JDK. The ant build.xml contains source=1.4 target=1.4 for the Javac task. I've trie building with source=1.3 target=1.3 and it passed Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED] : On 1/4/07, nicolas de loof [EMAIL PROTECTED] wrote: According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) These are for the Ant build - they're the ones that Maven generated for me. Seem to recall that attributes didn't like building on the Mac, so this was done on a Debian Linux box with Sun 1.4.2 and Maven 1.0.2. Unless manifest.mf is a name convention; they're not used for the Maven build. I also notice maven.compiler.target has been set to 1.4 during 2.2(rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3 . I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties Does it compile under 1.3 for you (using Ant I presume)? I'm wondering why the move to 1.4 was done, maybe there's a call to a 1.4 only method in there somewhere. remove manifest.mf from api sub-project Should be unnecessary. remove dependencies in api/project.xml (as they are only required by compiler) +1. With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Sounds good - once we grok why it was moved to 1.4. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REPOST [attributes 2.2] Missing optional package Extension
The manifest.mf in SVN contain a Created-By: Apache Maven but I never got maven include such Extension-List in my manifest. The one generated by the maven build don't include them. It seems the maven.jar.manifest.extensions.add option creates those entries in manifest. Maybe this property was set on the debian box used to build attributes 2.2 ? From maven jar plugin doc : maven.jar.manifest.extensions.add : Tells Maven to add extension information to the jar manifest. This can cause some applications to break, so it has been disabled by default. An Implementation-Vendor-Id attribute will be added for each dependency that has a vendorId element set in its properties section. Set to true to enable extension information. Seems using such extension is not recommended... I've used maven (not ant) to build on Windows. I can't test on a Mac. I've checked for 1.4 methods by importing api/compiler/unittest into eclipse and setting JRE to 1.3 : There is no compile requirement for Java 1.4 Maybe those compiler options have been set to allow compilation under Java5 JDK. The ant build.xml contains source=1.4 target=1.4 for the Javac task. I've trie building with source=1.3 target=1.3 and it passed Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED]: On 1/4/07, nicolas de loof [EMAIL PROTECTED] wrote: According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) These are for the Ant build - they're the ones that Maven generated for me. Seem to recall that attributes didn't like building on the Mac, so this was done on a Debian Linux box with Sun 1.4.2 and Maven 1.0.2. Unless manifest.mf is a name convention; they're not used for the Maven build. I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3. I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties Does it compile under 1.3 for you (using Ant I presume)? I'm wondering why the move to 1.4 was done, maybe there's a call to a 1.4 only method in there somewhere. remove manifest.mf from api sub-project Should be unnecessary. remove dependencies in api/project.xml (as they are only required by compiler) +1. With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Sounds good - once we grok why it was moved to 1.4. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REPOST [attributes 2.2] Missing optional package Extension
According to SVN log, the manifest has been added by bayard. The maven generated manifest is not used (why ?) I also notice maven.compiler.target has been set to 1.4 during 2.2 (rev 410143 by leosutic) that will break backward compatibility : I'm using commons-attributes on other projects on JRE 1.3. I've tested some changes from commons-attributes trunk : change maven.compiler.source and maven.compiler.target to 1.3 in project.properties remove manifest.mf from api sub-project remove dependencies in api/project.xml (as they are only required by compiler) With those changes, my webapp launch fine and run as expected. From what I've read, Extension-List is used to allow downloading of libs at runtime when not available in classpath. As ant and qdox manifest don't declare themself as extensions, the extension resolution fails. I'd suggest a new release as compatibility with 1.3 is blocking for me to upgrade. Nico. 2007/1/4, Henri Yandell [EMAIL PROTECTED]: On 1/3/07, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'm using commons-attributes with Spring on a Java 1.4 application. I've included commons-attributes-api 2.2 (from maven repo) I get this Tomcat exception on startup : LifecycleException: Missing optional package Extension[ant, implementationURL= http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar, implementationVersion=1.5] The commons-attributes MANIFEST contains those lines : Extension-List: ant qdox ant-Extension-Name: ant ant-Implementation-Version: 1.5 ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1.5.jar I don't know what this Extension-List is and why is it required by commons-attributes. AFAIK, the API doesn't require those libs anyway (only the compiler do). Is this a bug, and what would be a workaround ? AFAIK there is no development anymore on commons-attributes, so I can't ask for a 2.2.1 to correct this. How to handle this Extension-List ? I've added ant and qodx in my WEB-INF/lib with no result. I've no idea on the specific problem you're facing, but if a solution turns up I could try to push out a 2.2.1 release to correct it. I imagine removing the bits from the manifest would solve things - have you tried deleting them to see if things work? That'd be my first step. Then I'd google around to see if I can figure out what they're for. Then either suggest a new release or a workaround. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
REPOST [attributes 2.2] Missing optional package Extension
Hello, I'm using commons-attributes with Spring on a Java 1.4 application. I've included commons-attributes-api 2.2 (from maven repo) I get this Tomcat exception on startup : LifecycleException: Missing optional package Extension[ant, implementationURL= http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar, implementationVersion=1.5] The commons-attributes MANIFEST contains those lines : Extension-List: ant qdox ant-Extension-Name: ant ant-Implementation-Version: 1.5 ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1.5.jar I don't know what this Extension-List is and why is it required by commons-attributes. AFAIK, the API doesn't require those libs anyway (only the compiler do). Is this a bug, and what would be a workaround ? AFAIK there is no development anymore on commons-attributes, so I can't ask for a 2.2.1 to correct this. How to handle this Extension-List ? I've added ant and qodx in my WEB-INF/lib with no result. Nico.
[jira] Commented: (CONFIGURATION-237) Contrib : managed reloading strategy
[
http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12456318
]
nicolas de loof commented on CONFIGURATION-237:
---
My commons-configuration is build inside Spring context :
bean id=configuration class=PropertiesConfiguration
constructor-arg type=java.net.URL
value=file:${user.home}/custom.properties/
property name=reloadingStrategy ref=reloadingStrategy/
/bean
bean id=reloadingStrategy class=...ManagedReloadingStrategy/
The ManagedReloadingStrategy is itself a spring bean taht is set to the
configuration bean. As a spring bean, I can make a ref to if from the
MBeanExporter :
bean id=mbeanMetadataExporter
class=org.springframework.jmx.export.MBeanExporter
property name=server ref=mbeanServer/
property name=beans
map
entry key=myApp:bean=configuration
value-ref=reloadingStrategy/
/map
/property
/bean
I also made a contrib to spring-modules for building commons-configuration
CompositeConfiguration inside Sprign context based on multiple Configuration
beans. I'm using it to build a configuration from a classpath resource and a
user-space properties file with managedReloadingStrategy for hot reloading
properties.
Contrib : managed reloading strategy
Key: CONFIGURATION-237
URL: http://issues.apache.org/jira/browse/CONFIGURATION-237
Project: Commons Configuration
Issue Type: New Feature
Affects Versions: Nightly Builds
Reporter: nicolas de loof
Priority: Minor
Attachments: CONFIGURATION-237.patch,
ManagedReloadingStrategyTest.java
This patch adds a reloading strategy based on management request, typically
from a JMX console. The Strategy implements a MBean interface so can be
exported as a JMX Managed bean with no code change.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Preparing the 1.1 release
For compiling targeting java 1.3 runtime
- with maven1 :
[project.properties]
maven.compile.compilerargs = -bootclasspath ${java13.home}/lib/rt.jar
maven.compile.source = 1.3
maven.compile.target = 1.3
= You have to set java13.home in your build.properties to your JRE 1.3
: java13.home = C:/Program Files/Java/jre...
- with maven2 :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.3/source
target1.3/target
compilerArguments
bootclasspath
${settings.localRepository}/com/sun/rt/1.3.1_08/rt-1.3.1_08.jar
/bootclasspath
/compilerArguments
/configuration
dependencies
dependency
groupIdcom.sun/groupId
artifactIdrt/artifactId
version1.3.1_08/version
/dependency
/dependencies
/plugin
= You have to install the rt.jar of Java 1.3 JRE in your local repo
under com.sun:rt:1.3.1_08
Maven2 will give you the command to execute if artifact is not found.
Hope this will help !
Nico.
Henri Yandell a écrit :
Sorry for not reading this before the other reply Nico.
I'd definitely be interested in how that works, though would be good
to allow the 1.3 certify bit so I can get these releases out :)
Hen
On 11/14/06, Nicolas DE LOOF [EMAIL PROTECTED] wrote:
Sorry, I didn't read the beginning of this thread.
Do you want to create an Ant build only to ensure compilation for Java
1.3 runtime ?
I'm doing the same with maven by setting the compiler plugin to use JRE
1.3 rt.jar as bootclasspath. I've made some tests to ensure this
produces java 1.3 compliant code and doesn't link classes to methods
introduced in Java 1.4/Java5.
Nico.
Dennis Lundberg a écrit :
Henri Yandell wrote:
Ideally I'd want to use Ant to build the dist under 1.3 and then use
Maven to generate the site under 1.5. I'd use 1.2, but I'm not setup
for that at the moment.
In this case, I want to use Maven to do everything under 1.4 and
point
to the fact that Ant works under 1.3 to build a jar/test as
justification that it's okay to do it under 1.4. My personal
justifcation for the Ant files is that Maven-1 doesn't work under
1.2/1.3, so I'm a bit low personal itch-wise for implementing lots of
stuff in the Ant files.
+1
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
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]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=comments#action_12449598 ] nicolas de loof commented on CONFIGURATION-237: --- JMX has multiple way to expose application datas/features. This pacth only includes a static MBean, this means the Class implements an interface with the same name + MBean. Exported into a JMX Server, such a class will automagically expose to JMX management methods (and/or javabean properties) defines by the MBean interface. I myself use Spring MBeanExporter to do the work : bean id=mbeanExporter class=org.springframework.jmx.export.MBeanExporter property name=beans map entry key=myApp:name=configuration bean class=org.apache.commons.configuration.reloading.ManagedReloadingStrategy/ /entry /map /property property name=server ref=mbeanServer/ /bean In fact, I don't know another way to expose a bean to a JMX MBeanServer, as I did never had to do it programmaticaly... Hope it make this more comprehensible. Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ] nicolas de loof updated CONFIGURATION-237: -- Attachment: ManagedReloadingStrategyTest.java A simple testcase. Some code may be shared with TestFileChangedReloadingStrategy... Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch, ManagedReloadingStrategyTest.java This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Preparing the 1.1 release
Sorry, I didn't read the beginning of this thread. Do you want to create an Ant build only to ensure compilation for Java 1.3 runtime ? I'm doing the same with maven by setting the compiler plugin to use JRE 1.3 rt.jar as bootclasspath. I've made some tests to ensure this produces java 1.3 compliant code and doesn't link classes to methods introduced in Java 1.4/Java5. Nico. Dennis Lundberg a écrit : Henri Yandell wrote: Ideally I'd want to use Ant to build the dist under 1.3 and then use Maven to generate the site under 1.5. I'd use 1.2, but I'm not setup for that at the moment. In this case, I want to use Maven to do everything under 1.4 and point to the fact that Ant works under 1.3 to build a jar/test as justification that it's okay to do it under 1.4. My personal justifcation for the Ant files is that Maven-1 doesn't work under 1.2/1.3, so I'm a bit low personal itch-wise for implementing lots of stuff in the Ant files. +1 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-237) Contrib : managed reloading strategy
Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-237) Contrib : managed reloading strategy
[ http://issues.apache.org/jira/browse/CONFIGURATION-237?page=all ] nicolas de loof updated CONFIGURATION-237: -- Attachment: CONFIGURATION-237.patch Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: http://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Attachments: CONFIGURATION-237.patch This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Contrib : CONFIGURATION-237
I've created CONFIGURATION-237 for contributing. The patch adds a ManagedRealoadingStrategy taht is designed to be exposed as JMX bean to reload configuration from a JMX console. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbpc] SQLNestedException cause exception not logged
Hello, I got an issue using Commons-dbcp due to misconfiguration. The stacktrace doesn't contain the cause exception. As I'm running under Java5, the THROWABLE_CAUSE_METHOD evaluates to true, so the printStackTrace is not completed by SQLNestedException. But as no one called the setCause method, the cause exception is never logged. The cause is written to DriverManager.getLogWriter but I don't know where it logs in my app... Maybe the SQLNestedException constructor could call (using reflexion) the setCause method ? Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] pom for commons-logging-api and building/testing JCLwith Maven 1
I didn't read the start of this topic, but just my 2 cents about creating more sub-projects for implementation specifics : You're suggesting to split the project into modules for log4j, avalon and so on. Using maven2 you can create those artifacts as POM (not jars) and keep commons-logging as a main jar with optional dependencies. The specific poms only declare commons-logging and required dependencies for a particular use-case. You can consider such poms as profiles for some typical use of the lib (but profile has other meaning in maven2). I myself use this for my corporate projects : only declare a dependency to mycompany:webapp and you get all required libs for a typical webapp (typical = the way we used to build webapps, other people may consider some of those dependencies useless) I think it is a good idea to keep the tiny commons-logging-api as separate artifact and allow people to only depend on that. For the review of the pom.xml some comments from me: - -consider about spitting off commons-logging-api as a separate project with its own pom.xml. The build logic could be so much simpler. - -what do you think about a common pom.xml for all commons? - -whenever you swith to maven2 then you should switch to the default directory layout - -the profile based dependency stuff is also very complicated magic. Following the maven2 conventions could make it a lot easier. But this might require that you split of the implementation (commons-logging-logj4, commons-logging-avalon, etc.) then you even do not need to declare the dependencies optional - I gues you are not looking foreward to do this (e.g. from the maintaince point of view)... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5OG2mPuec2Dcv/8RAow/AJ9mIdj40xd7kXwq0FSSVQ0oTnOTyQCfdmdn UBpuYgDNsa82Z+V3DcRnH9U= =V5TA -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Release Attributes 2.2
Just as a (late) suggestion : would you consider migration to org.apache.commons groupId ? (http://maven.apache.org/guides/mini/guide-relocation.html) Nico. Henri Yandell a écrit : 4 +1s (including my own...quick +1 for the record). Leo Sutic Dennis Lundberg Stephen Colebourne Henri Yandell 1 +0 Rahul Akolkar I'll go ahead and work on the release tomorrow night. Hen On 7/23/06, Henri Yandell [EMAIL PROTECTED] wrote: This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Attributes 2.2
+1 from a nightly build user. Henri Yandell a écrit : This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven2 pom.xml files of commons
Commons does not have pom.xml for its components. Them pom files you find at the repositories (i.e. ibiblio) are converted by a piece of software from our (Maven 1) project.xml files. This conversion is made automatically. We are able to add some comments in our project.xml files to fix some of the conversion problems. So a couple of examples would be nice. Then I can check to see what the problems might be and if/how we can solve them. Maybe the maven project.xml 2 pom.xml converter may consider maven1 properties that have a direct equivalent in maven2 ? For example, if junit is refered as : dependency idjunit/id version3.8.1/version propertiesscopetest/scope/properties /dependency this scope property has no effect on maven1 but is valid and adds documentation to dependency use. It can be converted to the scope element in a maven2 pom. This can be a way to help the converter when a project is aware of beeing used by maven2 users but doesn't use it itself. Just my 2 cents... Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] nojdbc3 build not available using maven build
Hello, I'm using commons-dbcp on a Java1.3 environment and so I'm required to recompile it with source modification to comment JDBC3 code. ant build has a jdbc3 detection task, but maven build has no equivalent. Maybe a sourceModification element can be used to add this, but AKAIF it uses the presence of a class in classpath to apply modification, so this will not work on maven1.1 (that requires JDK1.4). Does anyone made experiments about this ? Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
AFAIK maven1 repo is simply a rewriteRule on maven2 repo, so that new
artifacts under org.apache.commons groupId in maven2 repo will be
available in maven1 repo under org.apache.commons/jars/artifact.jar
This may suggest to use a more specific groupId for commons, like
org.apache.commons.*lang*
to keep commons separation in maven1 repo.
Dennis Lundberg a écrit :
Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?
I really don't have a clue. Since I have not acted as release manager
for any component, I haven't really done my homework on what the
difference between the two is. I know about the M1 an M2 repos at
ibiblio, and that there is some sort of conversion between them, but
don't know what it looks like at the Apache end.
Do you have any suggestions on which is better?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
OK
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
OK
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
Cool, I'll have a go at it, to see it I can get it right. It'll have
to wait until this weekend though.
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so
that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any
commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies
mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They
must
keep
the same groupId for all commons-lang dependencies, as an
example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can
be a
PITA
since some of the dependencies are most likely out of the
projects own
control.
What do you suggest we do? Should we wait with this relocation
until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something
completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the
testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on
what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
AFAIK there is a way in maven repo to relocate dependencies, so that a POM for any commons can be published at commons-xxx groupId, that relocates to org.apache.commons groupId. Servletapi for example is now under javax.servlet http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the latest release of any commons it will look at the relocated one. Torsten Curdt a écrit : Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][Release][Attributes] Release Commons-Attributes 2.2
+1 from a 2.2-nightly-build user. Leo Sutic a écrit : Hi all, well, as usual I'm about one year late getting a release out, but I'd like to release Commons Attributes 2.2. The big changes are: 1. Some bugfixes 2. Support for attribute packages when using maven. +1 from me. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Surely a StringBuffer is already an Object? Or am I missing something here? StringBuffer has a new method in Java 1.4 to append another Stringbuffer without invoking it's toSring() method. Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will not work on Java 1.3. I miself recommand Using StringBuffer.append(stb.toString()) that looks better than an apparently useless (Object) cast : checkstyle or IDE may warn for unecessary cast. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
compiled on a JDK 1.4, sb1.append(sb2) will not work on java 1.3 JRE :
it requires append(StringBuffer).
compiled on a JDK 1.3, it is equivalent to a toString() call as
append(Object) method is used by compiler. It will work on all JRE but
will be non-optimal on JDK 1.4
Only two versions of the jar may solve this issue, or some JDK
compatibility test :
pseudo-code
final static boolean jdk13 =
System.getProperty(|java.vm.version|).startWith(1.3);
if (jdk13) {
stb1.append(stb2.toString());
} else {
stb1.append(stb2);
}
/pseudo-code
AFAIK, this code, compiled using JDK 1.4 will run under Java 1.3 without
noSuchMethodException AND uses Java1.4 Stringbuffer optimizations
sebb a écrit :
On 22/05/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
It is supported in jdk1.3.. Just cast the stringbuffer passed in to
an object, so like
StringBuffer.append((Object) StringBuffer)). Much more efficient than
an if...
Surely a StringBuffer is already an Object?
Or am I missing something here?
StringBuffer has a new method in Java 1.4 to append another Stringbuffer
without invoking it's toSring() method.
Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will
not work on Java 1.3.
I miself recommand Using StringBuffer.append(stb.toString()) that
looks better than an apparently useless (Object) cast : checkstyle or
IDE may warn for unecessary cast.
But that won't work so well on Java 1.4+.
Can't one just use:
sb1.append(sb2);
for both 1.3 and 1.4, and let the method do the work as needed?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[attributes] please add support for attributepackages in maven plugin
attributepackages property is used on ant task to allow short attributes in code. There is no support for it in the maven plugin. A simple property may do the job. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] please add support for attributepackages in maven plugin
Sorry, I've just discovered this feature is in CVS... http://jakarta.apache.org/commons/attributes/changelog.html Nicolas De Loof a écrit : attributepackages property is used on ant task to allow short attributes in code. There is no support for it in the maven plugin. A simple property may do the job. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] please add support for attributepackages in maven plugin
Where can I find a nightly build of the maven commons-attribute plugin ? The commons-attributes nightly-build only contains compiler + api Nicolas De Loof a écrit : Sorry, I've just discovered this feature is in CVS... http://jakarta.apache.org/commons/attributes/changelog.html Nicolas De Loof a écrit : attributepackages property is used on ant task to allow short attributes in code. There is no support for it in the maven plugin. A simple property may do the job. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X Martin Cooper a écrit : On 4/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/5/06, Martin Cooper [EMAIL PROTECTED] wrote: Right. But is there any reason we couldn't create a Maven 2 parallel to the Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy RCs there. It's already there: http://cvs.apache.org/maven-snapshot-repository Oh, that's what that is. ;-) The name threw me. -- Martin Cooper You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will generate a pom for it. That should be fine since Logging has no required dependencies. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] RC on ibiblio ?
Hello, Can someone upload commons-logging RC on Maven2 ibiblio repository ? It would be very cool to also upload a POM and the sources jar... Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] Announcing Release Candidate 2 for Pool 1.3
Just a cosmetic bug : AFAIK maven groupId for new version of jakarta commons should be org.apache.commons : http://maven.apache.org/guides/mini/guide-naming-conventions.html Nico. Oliver Heger a écrit : I tested RC2 with Commons Configuration and did not find any problems (but this is not too meaningful because the dependency to Commons Pool is only used by a test case for the database configuration class). Some notes: - There is no release notes file in neither the source nor the binary distro. - LICENSE.txt and NOTICE.txt have unix style line endings in the zips. (This is not a problem for me, but was cause for some discussions in the past.) - I had a problem building with ant (ClassNotFoundError for junit/textui/TestRunner), but this can be a problem with my setup (did not do much with ant recently). Oliver Sandy McArthur wrote: I've prepared Pool 1.3-rc2 at http://people.apache.org/~sandymac/pool/1.3-rc2/ I'd appreciate it if interested parties reviewed it and tested it with their setup. Changes since 1.3-rc1 are limited to documentation updates and maven build clean ups. The previous 1.3-rc1 announcement can be found at: http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200603.mbox/[EMAIL PROTECTED] If no issues are raised, on Saturday the 25th I'll start a vote to make this an official release. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] please use optional in POM
I agree with this : only required for any use case dependencies have to be made non-optional. Without this, transitive dependencies is not a cool feature anymore and becomes a exclusion-hell. Well, anything but core dependencies are IMHO optional. If you decide to make usage of functionality, that requires additional dependencies, you must add them in your project, that makes usage of them. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] please use optional in POM
Hello, I'm using maven2 and commons-configuration, and I need to configure lot's of exclusion as commons-configuration POM declares lot's of dependencies that are only required for some specialized use-cases. Those dependencies may be declared as optional (dom4j, servletapi, comons-codec...) Could someone update the POM ? This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven2/RMIC?
I think you have to declare mojo snapshot repository in your pom.xml : http://mojo.codehaus.org/using-sandbox-plugins.html I myself don't yet use maven2 (just looking at it), so I can't help you. James Carman a écrit : Thanks, Jörg. I tried using it, but my M2 installation couldn't download the plugin automagically. I think I'm going to have to download the source from SVN and build them into my local repository. But, if I want automated builds (like one that Mr. McClanahan could run overnight), this will not do. I can't believe this isn't something that's supported in M2. -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 8:32 AM To: Jakarta Commons Developers List Subject: RE: [all] Maven2/RMIC? Hi James, James Carman wrote on Monday, March 13, 2006 1:11 PM: All, Has anyone got RMIC to work using Maven2? Jakarta Commons Proxy's test cases need to generate RMIC stubs, but I can't get it working. It keeps complaining about either JAVA_HOME or CLASSPATH issues. There are complaints out there on the forums about it, but I didn't really see a good work-around. There is a rmic plugin at the in the mojo sandbox http://mojo.codehaus.org/, but I never used it nor do I know, what's the current state of it. [snip] - 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] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] bug in EmailValidator ?
EmailValidator.getInstance().isValid(test@ + '\t' + foo.com) returns true. I don't think use of blanks between @ and domain is valid for eMails. Perhaps SPECIAL_CHARS needs to include blanks ? Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Mario Ivankovits a écrit : robert burrell donkin wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( 3 the release has been compiled using 1.4.2: if commons-configuration is supposed to support 1.3 jdks then this could be a problem unless you've taken very careful steps. I've seen this too. I checked the build and tests and found te build fails with jdk.1.3 as there are references to javax.sql.DataSource and so I thought this is a jdk1.4 project. Unhappily a wrong decision by me. But this might explain why a jdk1.4 were used. --- Mario Can't this dependency be solved using jdbc2.0-stdext.jar ? I'm using Jdk 1.3 and cannot upgrade. Not supporting 1.3 anymore will stop my migration to commons-configuration. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Can't this dependency be solved using jdbc2.0-stdext.jar ? I'm using Jdk 1.3 and cannot upgrade. Not supporting 1.3 anymore will stop my migration to commons-configuration. Nico. Yes, with jdbc2.0-stdext.jar commons-configuration can be compiled and run under a JDK 1.3. Unfortunately this jar cannot be distributed via ibiblio because of licence issues, which makes the build a bit unconvenient. But I guess I will have to update the pom to declare this dependency because DatabaseConfiguration needs the DataSource interface. Would be a good idea to update documentation in this respect, too. Oliver AFAIK, other apache projects require sun jars to compile. You may ask commons-dbcp commiters that seem to have the same requirement : !-- Note JDBC 2.0 is a pain, because it must be manually downloaded to your Maven repository, and it's not even required on JDK 1.4. Maybe we should remove it from this dependency list so Maven doesn't choke? -- dependency idjdbc/id version2.0/version /dependency This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Can the project.xml be customized using jelly ?
something like this :
j:if test=${java.version == '1.3'}
dependency
idjdbc/id
/dependency
/j:if
It would be neater if something could be done in the maven.xml to
detect JDK 1.3 and add it into the class path from a property
specified in the build.properties. I'm going to face the same issue in
Commons Resources - we have 1 class that relies on JDBC 2.
Niall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] please upload a non JDBC3 (JDK 1.2/1.3) jar to apache repository
Hello, I'm using commons-dbcp in my project running on a JDK 1.3. It requires me to use the commons-dbcp library compiled with 'nojdbc3' option. I'm also using maven to resolve dependencies. Commons-dbcp jar is available from apache repository (sync with ibiblio), but this is the JDK1.4/jdbc3 version. Could any dbcp developers upload a commons-dbcp-nojdbc3-1.2.1.jar to apache repository ? It may be greate to include this in dbcp release process. Thanks. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] please upload a non JDBC3 (JDK 1.2/1.3) jar to apache repository
Hello, I'm using commons-dbcp in my project running on a JDK 1.3. It requires me to use the commons-dbcp library compiled with 'nojdbc3' option. I'm also using maven to resolve dependencies. Commons-dbcp jar is available from apache repository (sync with ibiblio), but this is the JDK1.4/jdbc3 version. Could any dbcp developers upload a commons-dbcp-nojdbc3-1.2.1.jar to apache repository ? It may be greate to include this in dbcp release process. Thanks. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
