Re: [VOTE] Release Configuration 1.2
Yeah, I should have said the real issues :-) Phil On 12/5/05, Emmanuel Bourg [EMAIL PROTECTED] wrote: Phil Steitz wrote: Sorry to be so late checking / trying to help. I am +1 for the release assuming Stephen's points (other than the ones listed as optional) and the following issues are addressed: - You should either modify configs, fix issues or eliminate PMD and checkstyle reports I fixed the remaining issues with PMD and Checkstyle. There are just some false positives left (an unused variable for PMD that is actually used, and missing method comments for Checkstyle that actually exist in a super class). I could disable line by line the checkstyle warnings left, but this would be a pain to maintain. I'd rather bet on a fix of Checkstyle in a future release. 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: [VOTE] Release Configuration 1.2
Phil Steitz wrote: Sorry to be so late checking / trying to help. I am +1 for the release assuming Stephen's points (other than the ones listed as optional) and the following issues are addressed: - You should either modify configs, fix issues or eliminate PMD and checkstyle reports I fixed the remaining issues with PMD and Checkstyle. There are just some false positives left (an unused variable for PMD that is actually used, and missing method comments for Checkstyle that actually exist in a super class). I could disable line by line the checkstyle warnings left, but this would be a pain to maintain. I'd rather bet on a fix of Checkstyle in a future release. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
snip/ Hi Phil, I think I am now at a point where I have a maven build, which should satisfy almost all points noticed by you and other reviewers - except for the line ending issue. After some documentation improvements I hope I can publish the (hopefully final) RC3 in some days. I had a clirr report in the first release candidate. It can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC1-docs/clirr.xml This report contains two error messages, which are a bit strange. It claims that a method was dropped from XMLConfiguration, but this method was simply moved into a super class. Maybe a clirr expert can chime in? Thanks Oliver Sorry to be so late checking / trying to help. I am +1 for the release assuming Stephen's points (other than the ones listed as optional) and the following issues are addressed: - You should either modify configs, fix issues or eliminate PMD and checkstyle reports - Javadoc errors should be fixed so javadoc report is clean - Package javadoc is missing from three of the packages - Apologies if I missed this posted somewhere, but have you done a clirr or jdiff report against 1.0? If there have been incompatible changes since 1.1, these should be called out to users. Its hard to tell from the changes report. Here are some additional comments that you are free to ignore, but which may be useful. 1) The username in the jar manifest is a PITA, since the maven dist plugin does not seem to pay attention to the user.name property that it is supposed to control this (yes, I know, need to open ticket). To work around this, I provide this on the command line: maven -Duser.name=psteitz dist. That works4me. 2) I think the workaround mentioned above for the sun jar is OK, though I don't think its that bad to force the local repo surgery, with a doco note somewhere. 3) You can use maven.compile.executable as described above to force compilation on jdk 1.3 (I personally do not view this as necessary, as long as you test the build on 1.3) and then use the maven.jar.manifest property (http://maven.apache.org/maven-1.x/reference/plugins/jar/properties.html) to specify a text file with lines to be merged in to the manifest to fix the version spec. If you go this route, you should probably check that file into svn so the build is repeatable. Note this can also be used to solve 1). Also, in order for maven.compile.executable to work, you need to have maven.compile.fork=true. Start with a bogus path in the first property to make sure it is being used. 4) At this point, we have no consensus on line endings standards, so I would not worry about the CRLF issue. See other thread. To me the bigger problem here is actually when releases are cut on Windows we are shipping CRLF on all files with svn eol=native props. Looks to me like the RC was build on unix, so there is no problem there. 5) If you configure project.properties and local build.properties as described here: http://jakarta.apache.org/commons/building.html and you have an apache ssh key set up, you can deploy the distribution jar to the distribution repo using maven -Dmaven.repo.list=apache.releases jar:deploy You should sign the jar as well and manually upload the sig to the repo. Signing is not yet supported by the jar (or dist) plugin, and most of the jars in java-repository are not signed, but we should be (manually) signing them. 6) You can use the maven announcement plugin with customized jsl (see [math]) to create full release notes like the maven changes report. I have no problem with not doing that, but if you don't, you need to remember to put a version element in the POM post release, so that the link to http://jakarta.apache.org/commons/configuration/changes-report.html remains valid (i.e. contents don't change to include changes after the release within scope of release). You might also consider including the current version of the html file in both src and binary distros. Phil - 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 Configuration 1.2
Oliver Heger wrote: snip/ Hi Phil, I think I am now at a point where I have a maven build, which should satisfy almost all points noticed by you and other reviewers - except for the line ending issue. After some documentation improvements I hope I can publish the (hopefully final) RC3 in some days. I had a clirr report in the first release candidate. It can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC1-docs/clirr.xml This report contains two error messages, which are a bit strange. It claims that a method was dropped from XMLConfiguration, but this method was simply moved into a super class. Maybe a clirr expert can chime in? clirr is still a 0.6, so not everything is right yet. I would check for/raise a ticket for it on sourceforge, as having reproducable bugs is obviously key for developing this tool. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Stephen, thanks for your feedback. I will address your points. Some questions follow: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? - Line endings: You mean files like project.xml or project.properties should also be converted? I think many things can be done with maven by tweaking the maven.xml, but the complex line ending stuff probably not. AFAIK a comming up version of the dist plugin should support this. Oliver Stephen Colebourne wrote: Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - 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 Configuration 1.2
Oliver Heger wrote: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? The purpose is so users can attach the source of the component to the binary jar file in an IDE such as Eclipse. It just contains the java LICENSE and NOTICE files. - Line endings: You mean files like project.xml or project.properties should also be converted? IMHO yes, but this has been an open debate for a while. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
On 12/3/05, Oliver Heger [EMAIL PROTECTED] wrote: Stephen, thanks for your feedback. I will address your points. Some questions follow: - What is the purpose of the -src-ide.zip file? I didn't find anything about that in the releasing components instructions. It contains the *.java files and the LICENSE and NOTICE files, right? - Line endings: You mean files like project.xml or project.properties should also be converted? I think many things can be done with maven by tweaking the maven.xml, but the complex line ending stuff probably not. AFAIK a comming up version of the dist plugin should support this. Oliver Stephen Colebourne wrote: Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [X] -1 I do not support this release, and here are my reasons --- Finally had time to check it (and note down what I did for the future). Apologies for it being a late -1. -1: Usage of Simian. This is a commercial product which requires a license. They state that they will grant a license to OSS, but we should confirm whether ASF/Jakarta has such a license. The simplest thing for now is to remove this report from the website until the PMC can confirm the legal position. -1: jar file manifest: Built-By: hacker I assume 'hacker' is a username of yours. However, I think its unsuitable for an ASF distribution. -0: jar file manifest: Build-Jdk: 1.4.2_04 Also, I assume that the build-jdk has come from the jdk running maven and is not the version configuration supports? Not sure what the solution to this is except using ant for the build running JDK 1.3. -0: The xdocs are not included in the src download. Other recommended changes: - Digester dependency states v1.5, but v1.6 is now released. - You specify the two separate beanutils jar files when you could specify just beanutils-core (there is no dependency on beanutils-collections). Other optional ideas: - Ensure that the source zip unzips to a directory name ending with -src. There is a maven setting for this, but I can't find it quickly. - Include a -src-ide.zip file in the binary release. See commons-io. This can only be done with ant AFAIK. - Line endings. It seems that you are converting txt files in the root folder. Personally I would like to see all text files in the root folder converted. This can only be done with ant AFAIK. - Ensure that the jar uploaded to ibiblio is exactly the same as that in the binary release - including date and timestamp. This makes problem resolution easier. This can only be done manually AFAIK. You may notice that ant is needed to achieve much of the above. But maven vs ant is a debate for a separate thread. Stephen - 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] Sorry to be so late checking / trying to help. I am +1 for the release assuming Stephen's points (other than the ones listed as optional) and the following issues are addressed: - You should either modify configs, fix issues or eliminate PMD and checkstyle reports - Javadoc errors should be fixed so javadoc report is clean - Package javadoc is missing from three of the packages - Apologies if I missed this posted somewhere, but have you done a clirr or jdiff report against 1.0? If there have been incompatible changes since 1.1, these should be called out to users. Its hard to tell from the changes report. Here are some additional comments that you are free to ignore, but which may be useful. 1) The username in the jar manifest is a PITA, since the maven dist plugin does not seem to pay attention to the user.name property that it is supposed to control this (yes, I know, need to open ticket). To work around this, I provide this on the command line: maven -Duser.name=psteitz dist. That works4me. 2) I think the workaround mentioned above for the sun jar is OK, though I don't think its that bad to force the local repo surgery, with a doco note somewhere. 3) You can use maven.compile.executable as described above to force compilation on jdk 1.3 (I personally do not view this as necessary, as long as you test the build on 1.3) and then use the maven.jar.manifest property (http://maven.apache.org/maven-1.x/reference/plugins/jar/properties.html) to specify a text file with lines to be merged in to the manifest to fix the version spec. If you go this route, you should probably check that file into svn so
Re: [VOTE] Release Configuration 1.2
Sorry Oliver I was on vacation this week. Here is my +1 Emmanuel Bourg Oliver Heger wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( Oliver Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - 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
Nicolas De Loof schrieb: 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. 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 - 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
On 12/1/05, Nicolas De Loof [EMAIL PROTECTED] wrote: 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 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]
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]
RE: [VOTE] Release Configuration 1.2
Hi Oliver, Oliver Heger wrote on Thursday, December 01, 2005 9:26 AM: 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. So, where's the problem (yeah, I know Stephen's blog about Compiling with older JDK)? Use 1.4 to compile it and have source/target as 1.3. For M2 you can have dependencies depending on the JDK version. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Jörg Schaible wrote: 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. So, where's the problem (yeah, I know Stephen's blog about Compiling with older JDK)? Use 1.4 to compile it and have source/target as 1.3. For M2 you can have dependencies depending on the JDK version. But as stated in his blog you have to set the bootclasspath too. Currently (temporary) I have a similar problem in commons-vfs. And if it is somehow possible I would like to avoid to release such a construct. If you would like to compile such a beast you have to have two JDKs installed. :-( IMHO Not that nice. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
snip/
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
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
I think simply checking for a JDK 1.3 may not be enough because you can
use the maven.compile.executable property to select a compiler from a
different JDK. Then compilation may take place on a JDK 1.3, but maven
is actually running on a JDK 1.4 or whatever.
I just tested the following approach: In maven.xml I added the following
goal:
!-- Adds the jdbc-stdext to the dependency classpath if the
dependency.jdbc property is defined.
--
preGoal name=java:compile
j:if test=${dependency.jdbc != ''}
path id=extended.dependency.path
pathelement path=${dependency.jdbc}/
/path
maven:addPath id=maven.dependency.classpath
refid=extended.dependency.path/
/j:if
/preGoal
Now in your build.properties you can define the dependency.jdbc
variable to point to the jdbc jar. If it is set, the dependency will be
added to the classpath; otherwise not. Given that this setup is clearly
documented, do you think this solution is practical?
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( Oliver Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - 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 Configuration 1.2
+0 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( Oliver Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - 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] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
+0 Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( Oliver Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - 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] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Oliver Heger wrote: --- [ ] +1 I support this release and am willing to help [X] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
On Wed, 2005-11-30 at 15:07 +0100, Oliver Heger wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( sorry for join a little late :-/ hopefully stephen, phil and the rest of the release experts will jump in sometime soon... i have a few small points: 1 i'm not very happy about the download page (http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/downloads.html) in the project documentation section. should be directing people to use the official mirrors and should be some notes about checking signatures or sums. 2 (minor point this one) the release notes could be improved: don't forget that these will be well distributed and indexed so it's a good idea to add at least a few specific details. so i'd be inclined to add at least one new feature to There are some new features as well. 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. 4 i see you are distributing reports generated by simian. i trust that you have an appropriate license. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
On Wed, 2005-11-30 at 22:32 +0100, Mario Ivankovits wrote: 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. perhaps it would be possible to satisfy this with an alternate jdbc dependency? Unhappily a wrong decision by me. But this might explain why a jdk1.4 were used. i wouldn't be too critical about that decision... ideally, it would be better to find another way of satisfying that dependency. if that isn't possible then it's important to ensure that users are clearly informed about the minimum JDK version. even if there is a 1.4 library dependency, it's best to use the source switches so that the rest of the library could be used on 1.3. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
robert burrell donkin schrieb: On Wed, 2005-11-30 at 22:32 +0100, Mario Ivankovits wrote: 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. perhaps it would be possible to satisfy this with an alternate jdbc dependency? Unhappily a wrong decision by me. But this might explain why a jdk1.4 were used. i wouldn't be too critical about that decision... ideally, it would be better to find another way of satisfying that dependency. if that isn't possible then it's important to ensure that users are clearly informed about the minimum JDK version. even if there is a 1.4 library dependency, it's best to use the source switches so that the rest of the library could be used on 1.3. - robert Thanks for your feedback. The classes were indeed compiled on a JDK 1.3 using the maven.compile.executable property. Unfortunately the jar manifest refers to the 1.4 JDK (probably because this is the JDK that runs maven). Is there a way around this? I also had to tweak my local pom because of that jdbc dependency. I agree that this is not an ideal situation, especially because that dependency is only needed by a test class. Will see whether I can get rid of it. I will also take care of the points you mentioned, Robert. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Configuration 1.2
Here is my +1. Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - 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]
[VOTE] Release Configuration 1.2
Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
