Re: svn commit: r1449206 - /commons/proper/logging/trunk/pom.xml
On 2013-02-23 09:01, Thomas Neidhart wrote: On 02/23/2013 12:21 AM, Dennis Lundberg wrote: On 2013-02-22 21:38, t...@apache.org wrote: Author: tn Date: Fri Feb 22 20:38:59 2013 New Revision: 1449206 URL: http://svn.apache.org/r1449206 Log: Fix jar deploy, add osgi bundle metadata. Modified: commons/proper/logging/trunk/pom.xml Modified: commons/proper/logging/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1449206r1=1449205r2=1449206view=diff == --- commons/proper/logging/trunk/pom.xml (original) +++ commons/proper/logging/trunk/pom.xml Fri Feb 22 20:38:59 2013 @@ -189,11 +189,6 @@ under the License. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId -configuration - archive -manifestFilesrc/conf/MANIFEST.MF/manifestFile - /archive -/configuration executions execution !-- @@ -253,6 +248,21 @@ under the License. /excludes /configuration /execution + + !-- +- Define the full jar last, the deploy/install plugin seems to be broken +- and takes the last definition from here. +-- What kinds of problems are you seeing? This shouldn't be needed. I thought so too, but if this is not present, the following happens when doing a deploy/install: [INFO] Installing /home/tn/workspace/apache/logging/target/commons-logging-adapters-1.1.2-SNAPSHOT.jar to /home/tn/.m2/repository/commons-logging/commons-logging/1.1.2-SNAPSHOT/commons-logging-1.1.2-SNAPSHOT.jar It looks like the last execution definition overrides something. I see, let me see if I can make it work... Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1449206 - /commons/proper/logging/trunk/pom.xml
On 2013-02-22 21:38, t...@apache.org wrote:
Author: tn
Date: Fri Feb 22 20:38:59 2013
New Revision: 1449206
URL: http://svn.apache.org/r1449206
Log:
Fix jar deploy, add osgi bundle metadata.
Modified:
commons/proper/logging/trunk/pom.xml
Modified: commons/proper/logging/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1449206r1=1449205r2=1449206view=diff
==
--- commons/proper/logging/trunk/pom.xml (original)
+++ commons/proper/logging/trunk/pom.xml Fri Feb 22 20:38:59 2013
@@ -189,11 +189,6 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
-configuration
- archive
-manifestFilesrc/conf/MANIFEST.MF/manifestFile
- /archive
-/configuration
executions
execution
!--
@@ -253,6 +248,21 @@ under the License.
/excludes
/configuration
/execution
+
+ !--
+- Define the full jar last, the deploy/install plugin seems to
be broken
+- and takes the last definition from here.
+--
What kinds of problems are you seeing?
This shouldn't be needed.
+ execution
+idfulljar/id
+phasepackage/phase
+goals
+ goaljar/goal
+/goals
+configuration
+ jarName${project.artifactId}-${project.version}/jarName
+/configuration
+ /execution
/executions
/plugin
@@ -544,7 +554,14 @@ under the License.
commons.binary.suffix-bin/commons.binary.suffix
commons.jira.idLOGGING/commons.jira.id
commons.jira.pid12310484/commons.jira.pid
-commons.surefire.version2.12/commons.surefire.version
+commons.surefire.version2.12/commons.surefire.version
skipSurefireReporttrue/skipSurefireReport
+
+commons.osgi.import
+ javax.servlet;version=[2.1.0, 3.0.0);resolution:=optional,
+ org.apache.avalon.framework.logger;version=[4.1.3,
4.1.5];resolution:=optional,
+ org.apache.log;version=[1.0.1, 1.0.1];resolution:=optional,
+ org.apache.log4j;version=[1.2.15, 2.0.0);resolution:=optional
+/commons.osgi.import
/properties
/project
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On 2013-01-12 15:03, Thomas Neidhart wrote: Hi, Hi Thomas A while back I made changes to the Maven build so that it produces the same output as the Ant build. The should mean that we can get rid of the old Ant build if we want to. One thing that I'd like to do is to restructure the source code into several separate Maven modules, so that there is a specific module for commons-logging-api. The current setup is error prone, as it is extracting certain files from certain archives and then repackaging them again, with the risk of loosing meta data like MANIFEST.MF. I would like to do a similar cleanup as for email also for logging and aim for a 1.2 release in the coming weeks. The things I have in mind: * update to Java 5 I'm -1 on this change. I don't see any reason to do it. We don't need features from a more recent Java version in commons-logging. As others have said: most users of commons-logging are old and older apps. * comply to default maven structure +1 * update to Junit 4 +1 * fix the open issues wrt thread safety Are there patches available for these issues? Which issues are we talking about? * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see LOGGING-119) What do you think? Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On 2013-01-15 09:56, Christian Grobmeier wrote: On Sat, Jan 12, 2013 at 8:49 PM, Mark Thomas ma...@apache.org wrote: On 12/01/2013 19:29, Christian Grobmeier wrote: On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas ma...@apache.org wrote: On 12/01/2013 17:36, Christian Grobmeier wrote: Basically I am +1 on moving to newer JDKs. But in this case I just see use for old and older applications. That said, I just checked and saw tomcat is still using commons-logging: http://svn.apache.org/repos/asf/tomcat/trunk/build.xml Maybe Mark will comment here. Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever the latest version is. Just out of interest... why the love with Commons Logging and not for example slf4j? It was the best choice at the time and no-one has made a good argument for changing. Tomcat used C-L to create JULI which is package renamed (to avoid conflicts if a webapp uses C-L), hard coded to use java.util.logging and has a custom LogManager that actually works properly in a multi-classloader container environment - don't get me started on how bad the default one is. There is an optional package that adds back in the (still package renamed) full version of commons logging and provides an adaptor for log4j. So Tomcat's requirements are: - easy to package rename (technically and legally) - pluggable for multiple back-ends - won't clash with anything a webapp does Commons Logging meets all of those requirements. Other logging frameworks may also meet them but they'd have to offer an awful lot more to justify the work that would be required to refactor JULI to use them. It isn't as if there are any features missing in C-L that Tomcat needs/wants. Thanks for the insight. Maybe it would be interesting to change the targets of commons-logging. Currently it is in direct competition with slf4j (logging facade which connects to different other frameworks). And as that its pretty outdated and just of use for a few. But what if commons-logging would have the target to be minimal, easy to repackage and maybe does even provide a basic logging implementation. It already includes a basic logging implementation: SimpleLog. The other frameworks come up with a lot of features which often comes with a lot of complexity and sometimes a cost in performance. commons-logging could solve this. Christian Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On 2013-01-15 19:20, Gary Gregory wrote: On Tue, Jan 15, 2013 at 1:17 PM, Dennis Lundberg denn...@apache.org wrote: On 2013-01-12 15:03, Thomas Neidhart wrote: Hi, Hi Thomas A while back I made changes to the Maven build so that it produces the same output as the Ant build. The should mean that we can get rid of the old Ant build if we want to. One thing that I'd like to do is to restructure the source code into several separate Maven modules, so that there is a specific module for commons-logging-api. The current setup is error prone, as it is extracting certain files from certain archives and then repackaging them again, with the risk of loosing meta data like MANIFEST.MF. I would like to do a similar cleanup as for email also for logging and aim for a 1.2 release in the coming weeks. The things I have in mind: * update to Java 5 I'm -1 on this change. I don't see any reason to do it. We don't need features from a more recent Java version in commons-logging. As others have said: most users of commons-logging are old and older apps. * comply to default maven structure +1 * update to Junit 4 +1 You need Java 5 to use JUnit 4 properly. @Test... Yes, but requiring Java 5 to build is not the same thing as setting the minimum runtime Java version to Java 5. Using something like animal sniffer we can make sure that we don't break the compatibility with older JDKs. However we might need to up the target version from 1.1 to 1.2 since there are no signatures available for Java 1.1. http://mojo.codehaus.org/animal-sniffer-maven-plugin/ Gary * fix the open issues wrt thread safety Are there patches available for these issues? Which issues are we talking about? * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see LOGGING-119) What do you think? Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1432688 - /commons/proper/logging/trunk/pom.xml
On 2013-01-13 19:14, t...@apache.org wrote: Author: tn Date: Sun Jan 13 18:14:24 2013 New Revision: 1432688 URL: http://svn.apache.org/viewvc?rev=1432688view=rev Log: Upgrade test dependencies: log4j 1.2.17, avalong-framework 4.1.5 These are not test dependencies - they are real dependencies used in the implementations of Log4JLogger and AvalonLogger respectively. Do we really want to upgrade these? Modified: commons/proper/logging/trunk/pom.xml Modified: commons/proper/logging/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1432688r1=1432687r2=1432688view=diff == --- commons/proper/logging/trunk/pom.xml (original) +++ commons/proper/logging/trunk/pom.xml Sun Jan 13 18:14:24 2013 @@ -444,7 +444,7 @@ under the License. dependency groupIdlog4j/groupId artifactIdlog4j/artifactId - version1.2.12/version + version1.2.17/version optionaltrue/optional /dependency dependency @@ -456,7 +456,7 @@ under the License. dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId - version4.1.3/version + version4.1.5/version optionaltrue/optional /dependency dependency -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Build failed in Jenkins: Commons FileUpload #1
/FILEUPLOAD_1_1_1_RC1/src/test/org/apache/commons/fileupload/ParameterParserTest.java A tags/FILEUPLOAD_1_1_1_RC1/src/java A tags/FILEUPLOAD_1_1_1_RC1/src/java/org A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/DiskFileUpload.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/FileUploadBase.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/DefaultFileItem.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/FileUploadException.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/FileUpload.java A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/servlet AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/servlet/ServletRequestContext.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/servlet/ServletFileUpload.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/servlet/package.html AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/FileItemFactory.java A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/portlet AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/portlet/PortletRequestContext.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/portlet/PortletFileUpload.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/portlet/package.html A tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/disk AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/disk/DiskFileItem.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/disk/package.html AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/DefaultFileItemFactory.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/MultipartStream.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/ParameterParser.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/RequestContext.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/FileItem.java AU tags/FILEUPLOAD_1_1_1_RC1/src/java/org/apache/commons/fileupload/package.html A tags/FILEUPLOAD_1_1_1_RC1/src/conf AUtags/FILEUPLOAD_1_1_1_RC1/src/conf/MANIFEST.MF AUtags/FILEUPLOAD_1_1_1_RC1/build.xml AUtags/FILEUPLOAD_1_1_1_RC1/NOTICE.txt AUtags/FILEUPLOAD_1_1_1_RC1/LICENSE.txt A tags/FILEUPLOAD_1_1_1_RC1/doap_fileupload.rdf AUtags/FILEUPLOAD_1_1_1_RC1/project.properties AUtags/FILEUPLOAD_1_1_1_RC1/PROPOSAL.html AUtags/FILEUPLOAD_1_1_1_RC1/fileupload_checks.xml AUtags/FILEUPLOAD_1_1_1_RC1/build-gump.xml AUtags/FILEUPLOAD_1_1_1_RC1/maven.xml AUtags/FILEUPLOAD_1_1_1_RC1/project.xml AUtags/FILEUPLOAD_1_1_1_RC1/gump.xml At revision 1397916 Parsing POMs ERROR: No such file https://builds.apache.org/job/Commons%20FileUpload/ws/pom.xml Perhaps you need to specify the correct POM file path in the project configuration? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Could we reference the Apache licence in commons-parent POM?
Hi Duncan This is already available in the Apache parent POM, which commons-parent inherits from. See http://repo1.maven.org/maven2/org/apache/apache/11/apache-11.pom On 2012-10-05 11:28, Duncan Jones wrote: Hi everyone, Plugins such as org.codehaus.mojo:license-maven-plugin will search POM files for licence declarations, allowing for automatic download and inclusion in generated artifacts. Has any thought been given to including a licence statement in the commons-parent POM? project ... licenses license nameThe Apache Software License, Version 2.0/name urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url distributionrepo/distribution /license /licenses ... /project Some commons projects do list the licence in their own project POM, but the support for this is patchy. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
On 2012-09-17 21:24, Sébastien Brisard wrote: Hi, I'm looking into extending the user's guide of Commons-Math for special functions. xdoc seems to be offering only very crude formatting possibiliities, and apt seems much better. It should work out of the box, alongside with existing xdoc pages. However, I can't seem to make it work, and I was wondering (being no maven expert) if there was anything in commons-parent that prevented from using apt? Should I change anything in our pom.xml? Nothing in our parent prevents you from using apt documents. Just put them in the src/site/apt folder and make sure they have a .apt extension. For an example have a look at the source for Maven Site Plugin itself: https://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/site/ It uses documents in apt, xdoc and fml flavors. That being said, I think you'll find the formating options to be about equal between the two. At the moment, I'm just toying with the idea. I want to give apt a go locally, and see how it goes. I haven't found (yet) a commons project that uses this format. Is there a good reason? Should I stick with xdoc instead? Thanks for your advice! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] maven-changes-plugin failed to parse JIRA XML.
On 2012-08-30 23:18, Dennis Lundberg wrote: Hi You've stumbled upon http://jira.codehaus.org/browse/MCHANGES-285 due to the recent upgrade of the ASF JIRA instance. The 2.8 version of the Changes Plugin has now been released. Do you want me to add the necessary configuration to use it in commons-parent? On 2012-08-30 15:20, Gary Gregory wrote: I've started to see this SAXParseException in [codec] trunk and other commons components. Ideas? [INFO] Generating JIRA Report report--- maven-changes-plugin:2.7.1 Aug 30, 2012 9:16:52 AM org.apache.commons.httpclient.HttpMethodBase getResponseBody WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. [INFO] Downloading from JIRA at: http://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rsspid=12310464statusIds=5 ype=2type=3type=4type=5type=6sorter/field=fixVersionssorter/order=DESCsorter/field=issuetypesorter/order=ASCsorter pMax=100reset=truedecorator=none [WARNING] org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML. at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132) at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108) at org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755) at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.xml.sax.SAXParseException: The entity name must immediately follow the '' in the entity reference. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source
Re: [VOTE] Release Commons Codec 1.7-RC1
-046/ The tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1 The site: https://people.apache.org/builds/commons/commons-codec/1.7/RC1/ Note that the JIRA report is empty and it is a known issue in the Maven JIRA plugin and that requires a new plugin version. Thank you, Gary Gregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] maven-changes-plugin failed to parse JIRA XML.
Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:128) ... 30 more -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1363623 - /commons/proper/logging/trunk/pom.xml
On 2012-07-20 23:26, sebb wrote:
On 20 July 2012 22:02, Dennis Lundberg denn...@apache.org wrote:
If this is an integration test, the proper way to exclude it is to
change its name so that it ends with ITCase.java, see
see ... what?
It's not an integration test - I'm excluding WeakHashTableTestCase
from the existing integration tests.
I see, so it's the other way around.
The integration tests should be executed by maven-failsafe-plugin, and
the unit tests should be executed by maven-surefire-plugin. I know that
commons-logging has some fairly complex integration tests. I'll try to
see if I can get the Maven build to follow Maven best practices.
The rest of the patch just allows the IT to work.
On 2012-07-20 04:04, s...@apache.org wrote:
Author: sebb
Date: Fri Jul 20 02:04:51 2012
New Revision: 1363623
URL: http://svn.apache.org/viewvc?rev=1363623view=rev
Log:
Add missing property definitions for integration tests
Modified:
commons/proper/logging/trunk/pom.xml
Modified: commons/proper/logging/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1363623r1=1363622r2=1363623view=diff
==
--- commons/proper/logging/trunk/pom.xml (original)
+++ commons/proper/logging/trunk/pom.xml Fri Jul 20 02:04:51 2012
@@ -343,10 +343,16 @@ under the License.
includes
include**/*TestCase.java/include
/includes
+ excludes
+exclude**/WeakHashTableTestCase.java/exclude
+ /excludes
systemPropertyVariables
!--
org.apache.commons.logging.diagnostics.destSTDOUT/org.apache.commons.logging.diagnostics.dest
--
+ log4j12${log4j:log4j:jar}/log4j12
+ logkit${logkit:logkit:jar}/logkit
+
servlet-api${javax.servlet:servlet-api:jar}/servlet-api
commons-loggingtarget/${project.build.finalName}.jar/commons-logging
commons-logging-apitarget/${project.artifactId}-api-${project.version}.jar/commons-logging-api
commons-logging-adapterstarget/${project.artifactId}-adapters-${project.version}.jar/commons-logging-adapters
@@ -371,6 +377,19 @@ under the License.
tarLongFileModegnu/tarLongFileMode
/configuration
/plugin
+ !-- Define properties for referencing dependencies --
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-dependency-plugin/artifactId
+version2.4/version
+executions
+ execution
+goals
+ goalproperties/goal
+/goals
+ /execution
+/executions
+ /plugin
/plugins
/build
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1362959 - in /commons/proper/logging/trunk/src: java/org/apache/commons/logging/ java/org/apache/commons/logging/impl/ test/org/apache/commons/logging/tccl/
On 2012-07-20 23:30, sebb wrote:
On 20 July 2012 21:53, Dennis Lundberg denn...@apache.org wrote:
Hi sebb
Some of these might have been put in there to avoid warnings from tools
like Checkstyle.
If CheckStyle insists on adding redundant semi-colons then it's badly
configured or broken.
Haha :)
No, the checks I had in mind are to make sure that there are no code
paths that do nothing, unless it is explicitly documented by an
annotation. I think that someone took the easy way out at some point,
and just added a semicolon. I'll check svn history and see if I find
some hints...
Should look at whether the warning count has increased
after this change. If so there are special annotations that can be used
to suppress these warnings explicitly.
Should not be necessary to use annotations for redundant semicolons ..
On 2012-07-18 16:14, s...@apache.org wrote:
Author: sebb
Date: Wed Jul 18 14:14:29 2012
New Revision: 1362959
URL: http://svn.apache.org/viewvc?rev=1362959view=rev
Log:
Redundant semi-colons
Modified:
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogSource.java
commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/NullTCCLTestCase.java
Modified:
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=1362959r1=1362958r2=1362959view=diff
==
---
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
(original)
+++
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Wed Jul 18 14:14:29 2012
@@ -511,7 +511,7 @@ public abstract class LogFactory {
+ : [ + trim(e.getMessage())
+ ]. Trying alternative implementations...);
}
-; // ignore
+// ignore
} catch(RuntimeException e) {
// This is not consistent with the behaviour when a bad
LogFactory class is
// specified in a services file.
@@ -588,7 +588,7 @@ public abstract class LogFactory {
+ : [ + trim(ex.getMessage())
+ ]. Trying alternative implementations...);
}
-; // ignore
+// ignore
}
}
@@ -922,7 +922,7 @@ public abstract class LogFactory {
* we can make a distinction.
*/
if (e.getTargetException() instanceof SecurityException) {
-; // ignore
+// ignore
} else {
// Capture 'e.getTargetException()' exception for
details
// alternate: log 'e.getTargetException()', and pass
back 'e'.
Modified:
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogSource.java
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogSource.java?rev=1362959r1=1362958r2=1362959view=diff
==
---
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogSource.java
(original)
+++
commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogSource.java
Wed Jul 18 14:14:29 2012
@@ -115,7 +115,7 @@ public class LogSource {
setLogImplementation
(org.apache.commons.logging.impl.NoOpLog);
} catch (Throwable u) {
-;
+// ignored
}
}
} else {
@@ -135,7 +135,7 @@ public class LogSource {
setLogImplementation
(org.apache.commons.logging.impl.NoOpLog);
} catch (Throwable u) {
-;
+// ignored
}
}
}
Modified:
commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java?rev=1362959r1=1362958r2=1362959view=diff
==
---
commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
(original)
+++
commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
Wed Jul 18 14:14:29 2012
@@ -140,7 +140,7 @@ public class SimpleLog implements Log, S
try {
prop
Re: svn commit: r1362959 - in /commons/proper/logging/trunk/src: java/org/apache/commons/logging/ java/org/apache/commons/logging/impl/ test/org/apache/commons/logging/tccl/
(InvocationTargetException e) {
/**
* InvocationTargetException is thrown by 'invoke' when
@@ -680,7 +680,7 @@ public class SimpleLog implements Log, S
* we can make a distinction.
*/
if (e.getTargetException() instanceof SecurityException)
{
-; // ignore
+// ignore
} else {
// Capture 'e.getTargetException()' exception for
details
// alternate: log 'e.getTargetException()', and pass
back 'e'.
@@ -690,7 +690,7 @@ public class SimpleLog implements Log, S
}
} catch (NoSuchMethodException e) {
// Assume we are running on JDK 1.1
-; // ignore
+// ignore
}
}
Modified:
commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/NullTCCLTestCase.java
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/NullTCCLTestCase.java?rev=1362959r1=1362958r2=1362959view=diff
==
---
commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/NullTCCLTestCase.java
(original)
+++
commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/NullTCCLTestCase.java
Wed Jul 18 14:14:29 2012
@@ -28,7 +28,7 @@ import junit.framework.TestCase;
*/
public class NullTCCLTestCase extends TestCase {
-public static Test suite() throws Exception {;
+public static Test suite() throws Exception {
PathableTestSuite suite = new
PathableTestSuite(NullTCCLTestCase.class, null);
return suite;
}
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1363623 - /commons/proper/logging/trunk/pom.xml
If this is an integration test, the proper way to exclude it is to
change its name so that it ends with ITCase.java, see
On 2012-07-20 04:04, s...@apache.org wrote:
Author: sebb
Date: Fri Jul 20 02:04:51 2012
New Revision: 1363623
URL: http://svn.apache.org/viewvc?rev=1363623view=rev
Log:
Add missing property definitions for integration tests
Modified:
commons/proper/logging/trunk/pom.xml
Modified: commons/proper/logging/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1363623r1=1363622r2=1363623view=diff
==
--- commons/proper/logging/trunk/pom.xml (original)
+++ commons/proper/logging/trunk/pom.xml Fri Jul 20 02:04:51 2012
@@ -343,10 +343,16 @@ under the License.
includes
include**/*TestCase.java/include
/includes
+ excludes
+exclude**/WeakHashTableTestCase.java/exclude
+ /excludes
systemPropertyVariables
!--
org.apache.commons.logging.diagnostics.destSTDOUT/org.apache.commons.logging.diagnostics.dest
--
+ log4j12${log4j:log4j:jar}/log4j12
+ logkit${logkit:logkit:jar}/logkit
+ servlet-api${javax.servlet:servlet-api:jar}/servlet-api
commons-loggingtarget/${project.build.finalName}.jar/commons-logging
commons-logging-apitarget/${project.artifactId}-api-${project.version}.jar/commons-logging-api
commons-logging-adapterstarget/${project.artifactId}-adapters-${project.version}.jar/commons-logging-adapters
@@ -371,6 +377,19 @@ under the License.
tarLongFileModegnu/tarLongFileMode
/configuration
/plugin
+ !-- Define properties for referencing dependencies --
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-dependency-plugin/artifactId
+version2.4/version
+executions
+ execution
+goals
+ goalproperties/goal
+/goals
+ /execution
+/executions
+ /plugin
/plugins
/build
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [imaging][csv][configuration][net] mvn -Prc install doesn't generate zip/tar.gz/tar.bz2 files?
On 2012-06-04 11:53, Damjan Jovanovic wrote: On Sun, Jun 3, 2012 at 7:07 PM, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 03.06.2012 15:56, schrieb Gary Gregory: I use http://wiki.apache.org/commons/UsingNexus Gary On Jun 3, 2012, at 4:25, Damjan Jovanovicdam...@apache.org wrote: Hi I am trying to make an RC release of Commons Imaging, and according to http://commons.apache.org/releases/prepare.html the command which is meant to generate the release artifacts is: mvn -Prc -DcreateChecksum=true install However this only generates .jar/javadoc.jar/sources.jar files, not the bin/src .zip, .tar.gz or .tar.bz2. I've tried it on several other Commons projects: csv - command fails because assembly descriptors are missing configuration - also only generates .jar files net - also only generates .jar files Is that web page wrong? Is there some other command that is meant to be used? Or is there some kind of problem in all these projects? For [configuration] I used to follow the instructions on this page. The full distribution is created by the shell script in the section Create the Release Candidate Website. This worked for me. Oliver The command mvn -Prc -DcreateChecksum=true install is taken verbatim from that very Create the Release Candidate Website page, and neither it, nor that entire script, are working, for either Imaging or Configuration from the latest SVN trunk. According to http://www.mail-archive.com/dev@commons.apache.org/msg23476.html this is a known regression in the maven-assembly-plugin. A bit of searching finds http://jira.codehaus.org/browse/MASSEMBLY-553 which appears to be the problem. I've had another look at this and have fixed the problem in the trunk of commons-parent. Workaround (taken from http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?revision=1169875view=markup): build pluginManagement plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-5/version /plugin /plugins /pluginManagement /build Please add that to the website (or how can I add it?). Also if Plexus is the current official way of releasing Commons components, why isn't that documented? This is now the 3rd build-breaking bug in Maven plugins I've found in my casual usage... This one was not a Maven plugin bug. The intended behavior deliberately changed in version 2.2 of the plugin in question. Unfortunately this was change was not advertised enough. Thank you Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] maven: Problem with clirr
)
at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:355)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
---CUT---
Does anyone have an idea of what can cause this?
Yep, that's a bug in the clirr-maven-plugin that was fixed in the latest
release.
Please use version 2.4 of clirr-maven-plugin.
In the meantime, I'd be glad to be able to disable this tool... :-{
It didn't work.
mvn -Dclirr.skip
works for me.
Doesn't work here! Using:
$ mvn -version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.7.0_03-icedtea, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 2.6.32-5-vserver-amd64, arch: amd64,
family: unix
Can you try with M221? Maybe the system property is no longer passed to the
forked process ... :-/
Or try to use the check-no-fork goal instead.
I'm launching the site target. I really don't know much about maven. How
can I do that?
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Maven bugs when building Sanselan
On 2012-03-02 17:54, sebb wrote: On 2 March 2012 05:28, Damjan Jovanovic damjan@gmail.com wrote: On Thu, Mar 1, 2012 at 11:37 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-02-29 19:00, Damjan Jovanovic wrote: Hi As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am having showstopper problems with Maven. The first problem, now fixed, was that mvn assembly:assembly failed due to the Maven Assembly plugin failing to add a non-ASCII filename to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515), because Plexus Archiver had a bug that wrongly assumed number of chars = number of bytes, an assumption that quickly fails on UTF-8 locales (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to Plexus Archiver, they quickly included that patch in the next release, and Maven Assembly then made a 2.3 release which unknowingly pulled in that new release of Plexus Archiver. So by increasing the needed version of Maven Assembly to 2.3, I got that working now :). I see someone recently patched the Commons parent POM with the same version change - even better. The second is that mvn site fails because Clirr can't compare some inner classes properly, and the Maven Clirr plugin doesn't properly count and delete classes that can't be compared, leading to ArrayIndexOutOfBoundsException (http://jira.codehaus.org/browse/MCLIRR-36 and probably http://jira.codehaus.org/browse/MCLIRR-25 and http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a working patch to that bug, but there's been no response yet and the project seems dead :(. I am unable to reproduce this error using current trunk of Sanselan. Are you using some local modifications to your pom.xml that specifies which artifact Clirr should compare against? All I get is this: [INFO] Unable to find a previous version of the project in the repository [INFO] Not generating Clirr report as there is no previous version of the library to compare against Clirr doesn't find the 0.97 release because the groupId and artifactId for it were different. It breaks for me because I somehow have Sanselan 0.98 (a version that was never released) in my ~/.m2 directory. But there is still a Clirr bug here which will affect future releases even if it doesn't affect this one. I will attach the minimum set of Sanselan 0.98 files needed to reproduce this bug to the bug report. I don't think applies here, but I have seen Clirr failures in the past that went away when the code was compiled with a different compiler. The failure occurred for me when code compiled by Eclipse was being checked (as can happen if using Eclipse to develop). Using mvn clean before running clirr fixed the issue. [It was a while ago; I think that was the the way it happened, rather than the reverse] See also the issue I raised a year ago: https://jira.codehaus.org/browse/MCLIRR-36 It would be good if someone in Maven-land could take a look; fixing the array bug should be trivial for someone that is familiar with building Maven plugins. Hi Just wanted to let you know that Clirr Maven Plugin 2.4 has been released. It includes a fix for MCLIRR-36. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Promote [csv] to Commons proper
+1 On 2012-03-06 18:42, Emmanuel Bourg wrote: Commons CSV is approaching a releasable state. Considering the general interest in this component I think it's time to promote it to Commons proper. There are a few points I'd like to address before a release: - Handle CSV headers, a CSV API looks incomplete to me without this - Examine the feasibility of adding a simple bean mapping feature - Extract the unicode unescaping feature as an implementation of java.io.Reader, and maybe contribute it to Commons IO - Improve the documentation [ ] +1 Promote it! [ ] -1 Let it crawl in the sandbox because... Emmanuel Bourg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Karma for Continuum on vmbuild
On 2012-02-29 22:25, sebb wrote: On 29 February 2012 21:14, Dennis Lundberg denn...@apache.org wrote: Hi Can someone please grant me karma @ http://vmbuild.apache.org/continuum I'd like to add some missing modules. My account in Continuum is dennisl which is backed by my ASF e-mail address. Try now. Thanks Sebb, work's fine now. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Maven bugs when building Sanselan
On 2012-03-01 06:23, Damjan Jovanovic wrote: On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-02-29 19:00, Damjan Jovanovic wrote: Hi As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am having showstopper problems with Maven. The first problem, now fixed, was that mvn assembly:assembly failed due to the Maven Assembly plugin failing to add a non-ASCII filename to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515), because Plexus Archiver had a bug that wrongly assumed number of chars = number of bytes, an assumption that quickly fails on UTF-8 locales (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to Plexus Archiver, they quickly included that patch in the next release, and Maven Assembly then made a 2.3 release which unknowingly pulled in that new release of Plexus Archiver. So by increasing the needed version of Maven Assembly to 2.3, I got that working now :). I see someone recently patched the Commons parent POM with the same version change - even better. The second is that mvn site fails because Clirr can't compare some inner classes properly, and the Maven Clirr plugin doesn't properly count and delete classes that can't be compared, leading to ArrayIndexOutOfBoundsException (http://jira.codehaus.org/browse/MCLIRR-36 and probably http://jira.codehaus.org/browse/MCLIRR-25 and http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a working patch to that bug, but there's been no response yet and the project seems dead :(. I'll take a look at the patch and see if I can push for a release of the Clirr plugin. Great, thank you! Damjan Hi I had some trouble building Sanselan locally with Java 5, so I added Sanselan to our Continuum CI server. The first build gives the same result as I got locally, which is a compilation failure. The full report is here: http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556projectId=251 The error message is: [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37] cannot find symbol symbol : method copyOfRange(byte[],int,int) location: class java.util.Arrays That seems to be a Java 6 method. Someone should have a look at that. I'll continue chasing Clirr-bugs using Java 6 for the time being. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Maven bugs when building Sanselan
On 2012-03-01 20:45, Gary Gregory wrote: On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-03-01 06:23, Damjan Jovanovic wrote: On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-02-29 19:00, Damjan Jovanovic wrote: Hi As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am having showstopper problems with Maven. The first problem, now fixed, was that mvn assembly:assembly failed due to the Maven Assembly plugin failing to add a non-ASCII filename to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515), because Plexus Archiver had a bug that wrongly assumed number of chars = number of bytes, an assumption that quickly fails on UTF-8 locales (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to Plexus Archiver, they quickly included that patch in the next release, and Maven Assembly then made a 2.3 release which unknowingly pulled in that new release of Plexus Archiver. So by increasing the needed version of Maven Assembly to 2.3, I got that working now :). I see someone recently patched the Commons parent POM with the same version change - even better. The second is that mvn site fails because Clirr can't compare some inner classes properly, and the Maven Clirr plugin doesn't properly count and delete classes that can't be compared, leading to ArrayIndexOutOfBoundsException (http://jira.codehaus.org/browse/MCLIRR-36 and probably http://jira.codehaus.org/browse/MCLIRR-25 and http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a working patch to that bug, but there's been no response yet and the project seems dead :(. I'll take a look at the patch and see if I can push for a release of the Clirr plugin. Great, thank you! Damjan Hi I had some trouble building Sanselan locally with Java 5, so I added Sanselan to our Continuum CI server. The first build gives the same result as I got locally, which is a compilation failure. The full report is here: http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556projectId=251 The error message is: [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37] cannot find symbol symbol : method copyOfRange(byte[],int,int) location: class java.util.Arrays That seems to be a Java 6 method. Someone should have a look at that. I'll continue chasing Clirr-bugs using Java 6 for the time being. Why are we chasing Clirr-bugs when this is not released? I'm trying to fix bugs in Maven Clirr Plugin. The JIRA tickets uses Commons Sanselan as an example project that shows the bugs in action. That's what got me building Sanselan. Gary -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Maven bugs when building Sanselan
On 2012-02-29 19:00, Damjan Jovanovic wrote: Hi As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am having showstopper problems with Maven. The first problem, now fixed, was that mvn assembly:assembly failed due to the Maven Assembly plugin failing to add a non-ASCII filename to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515), because Plexus Archiver had a bug that wrongly assumed number of chars = number of bytes, an assumption that quickly fails on UTF-8 locales (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to Plexus Archiver, they quickly included that patch in the next release, and Maven Assembly then made a 2.3 release which unknowingly pulled in that new release of Plexus Archiver. So by increasing the needed version of Maven Assembly to 2.3, I got that working now :). I see someone recently patched the Commons parent POM with the same version change - even better. The second is that mvn site fails because Clirr can't compare some inner classes properly, and the Maven Clirr plugin doesn't properly count and delete classes that can't be compared, leading to ArrayIndexOutOfBoundsException (http://jira.codehaus.org/browse/MCLIRR-36 and probably http://jira.codehaus.org/browse/MCLIRR-25 and http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a working patch to that bug, but there's been no response yet and the project seems dead :(. I am unable to reproduce this error using current trunk of Sanselan. Are you using some local modifications to your pom.xml that specifies which artifact Clirr should compare against? All I get is this: [INFO] Unable to find a previous version of the project in the repository [INFO] Not generating Clirr report as there is no previous version of the library to compare against Otherwise, what is the procedure for renaming the project to Apache Commons Imaging? Thank you Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Maven bugs when building Sanselan
On 2012-02-29 19:00, Damjan Jovanovic wrote: Hi As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am having showstopper problems with Maven. The first problem, now fixed, was that mvn assembly:assembly failed due to the Maven Assembly plugin failing to add a non-ASCII filename to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515), because Plexus Archiver had a bug that wrongly assumed number of chars = number of bytes, an assumption that quickly fails on UTF-8 locales (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to Plexus Archiver, they quickly included that patch in the next release, and Maven Assembly then made a 2.3 release which unknowingly pulled in that new release of Plexus Archiver. So by increasing the needed version of Maven Assembly to 2.3, I got that working now :). I see someone recently patched the Commons parent POM with the same version change - even better. The second is that mvn site fails because Clirr can't compare some inner classes properly, and the Maven Clirr plugin doesn't properly count and delete classes that can't be compared, leading to ArrayIndexOutOfBoundsException (http://jira.codehaus.org/browse/MCLIRR-36 and probably http://jira.codehaus.org/browse/MCLIRR-25 and http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a working patch to that bug, but there's been no response yet and the project seems dead :(. I'll take a look at the patch and see if I can push for a release of the Clirr plugin. Otherwise, what is the procedure for renaming the project to Apache Commons Imaging? Thank you Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Karma for Continuum on vmbuild
Hi Can someone please grant me karma @ http://vmbuild.apache.org/continuum I'd like to add some missing modules. My account in Continuum is dennisl which is backed by my ASF e-mail address. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Name of the committer? (was: Re: svn commit: r1184888 - /commons/proper/ognl/trunk/src/changes/changes.xml)
Hi The docs are not correct. I'll update them. You can either use an id that matches a developer/id in the POM, or the name of the developer. In the first case a link to that developer at the team-page is created. On Sunday, October 16, 2011, Christian Grobmeier grobme...@gmail.com wrote: Sorry: http://maven.apache.org/plugins/maven-changes-plugin/changes.html#class_action This MUST be the name of the developer as described in the developers section of the pom.xml file. Is it really the id of the pom.xml? I understood it so as it would be the name? No preference, just want to know On Sun, Oct 16, 2011 at 7:56 PM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Sun Oct 16 17:56:20 2011 New Revision: 1184888 URL: http://svn.apache.org/viewvc?rev=1184888view=rev Log: committers names replaced by ids Modified: commons/proper/ognl/trunk/src/changes/changes.xml Modified: commons/proper/ognl/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/ognl/trunk/src/changes/changes.xml?rev=1184888r1=1184887r2=1184888view=diff == --- commons/proper/ognl/trunk/src/changes/changes.xml (original) +++ commons/proper/ognl/trunk/src/changes/changes.xml Sun Oct 16 17:56:20 2011 @@ -24,18 +24,18 @@ body release version=4.0-incubating date=TBD description=First ASF release under Incubation. action issue=OGNL-27 type=update dev=simonetripodiMove toString implementations into visitor pattern./action - action issue=OGNL-26 type=update dev=Christian GrobmeierJUnit Tests produce confusing output./action - action issue=OGNL-21 type=update dev=Christian GrobmeierRemove dead and broken code from OgnlRuntime/SimpleNode (with contributions by Daniel Pitts)/action - action issue=OGNL-24 type=update dev=Christian GrobmeierSupport visitor pattern on AST (contributed by Daniel Pitts)/action - action issue=OGNL-15 type=update dev=Simone TripodiOGNL needs a new Logo/action - action issue=OGNL-14 type=update dev=Maurizio CucchiaraDocumentation site has to be published/action - action issue=OGNL-13 type=update dev=Simone TripodiAnt maintenance/action - action issue=OGNL-10 type=update dev=Simone TripodiUpdate the User/Developer guide according the Commons standard/action - action issue=OGNL-9 type=update dev=Maurizio Cucchiara, Simone TripodiUpgrade JUnit to version4/action - action issue=OGNL-8 type=update dev=Christian Grobmeierenabled generation of javacc Parser classes/action - action issue=OGNL-6 type=update dev=Simone TripodiUpgrade groupId/artifactId/version on pom/action + action issue=OGNL-26 type=update dev=grobmeierJUnit Tests produce confusing output./action + action issue=OGNL-21 type=update dev=grobmeierRemove dead and broken code from OgnlRuntime/SimpleNode (with contributions by Daniel Pitts)/action + action issue=OGNL-24 type=update dev=grobmeierSupport visitor pattern on AST (contributed by Daniel Pitts)/action + action issue=OGNL-15 type=update dev=simonetripodiOGNL needs a new Logo/action + action issue=OGNL-14 type=update dev=mcucchiaraDocumentation site has to be published/action + action issue=OGNL-13 type=update dev=simonetripodiAnt maintenance/action + action issue=OGNL-10 type=update dev=simonetripodiUpdate the User/Developer guide according the Commons standard/action + action issue=OGNL-9 type=update dev=mcucchiara, simonetripodiUpgrade JUnit to version4/action + action issue=OGNL-8 type=update dev=grobmeierenabled generation of javacc Parser classes/action + action issue=OGNL-6 type=update dev=simonetripodiUpgrade groupId/artifactId/version on pom/action action issue=OGNL-2 type=update dev=Update legals to all OGNL file/action - action issue=OGNL-1 type=update dev=Lukasz LenartImport the OGNL codebase/action + action issue=OGNL-1 type=update dev=lukaszlenartImport the OGNL codebase/action /release /body /document -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg
Re: [DISCUSS] Restyling the commons-skin
Hi I've had a closer look at bootstrap and have thought some more about this. This made me come to the conclusion that it would be worth while to have generic Maven skin based on bootstrap. With this in mind, do you think the Commons project could use such a skin, if it was possible to tweak colors and such easily? On 2011-10-09 22:22, Simone Tripodi wrote: Hi all guys, looks like there are not objections on working towards a new skin, so according to Dennis' proposal, I'm going to copy the current trunk on a branch in order to start working with bootstrap library. Thanks for the feedbacks and support, and thanks in advance for any help! Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Oct 8, 2011 at 5:01 PM, Greg Sterijevski gsterijev...@gmail.com wrote: +1 from me. Looks great! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Restyling the commons-skin
Hi Simone That looks very nice! Let's get the ball rolling on this. I currently have limited time, but I'm here to help with anything Maven-related in the skin. For me there is no need to do this work on a branch, I don't see us releasing another version of the current skin any time soon. If the need arises to release a new version of the old skin, we could just create a maintenance branch from the last tag. On 2011-10-07 18:33, Simone Tripodi wrote: Hi all guys, we already discussed in the past that we would like to have a nice new style for the site, and I would like to take advantage from a discussion born in the incubator ML[1] to renew the discussion, because our commons-fellow Christian Grobmeier came out with nice (IMHO) improvements[2] just adopting a style provided from Twitter[3] (ASL Licensed) called Bootstrap. I just did a 5 minute experiment[4], pasting in one of default template the commons-site HP text, that makes IMHO the commons-site really better. There would be the opportunity to improve the existing skin - that started looking so '90 - and I propose working on a new skin in a separate branch, adopting the bootstrap FW. WDYT? Many thanks in advance, all the best!!! Simo [1] http://markmail.org/message/f5r7mp5lxcc7pep5 [2] http://code.grobmeier.de/incubator-draft-v2/ [3] http://twitter.github.com/bootstrap/ [4] http://people.apache.org/~simonetripodi/commons/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] maven build issue
Hi You need to use findbugs plugin 2.3 or later with Maven 3. See https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html On 9/9/11, Greg Sterijevski gsterijev...@gmail.com wrote: Hello All, I am seeing this. My build is on a Mac. Does anyone have any clues? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on project commons-math: failed to get Reports: Unable to parse configuration of mojo org.codehaus.mojo:findbugs-maven-plugin:2.1:findbugs for parameter localRepository: Abstract class or interface 'org.apache.maven.artifact.repository.DefaultArtifactRepository' cannot be instantiated - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException Here is the result mvn --version Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) Maven home: /usr/share/maven Java version: 1.5.0_30, vendor: Apple Inc. Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.5.8, arch: i386, family: unix Thank you, -Greg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Nightly snapshots
- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] mvn Release and EU Mirror Lags
On 2011-07-27 06:20, Stefan Bodewig wrote: Hi, I just did a mvn release:prepare for Compress and it failed in the tagging stage. Since I live in Germany I access our EU svn mirror and the revision that I had created for the non-SNAPSHOT POM had not been replicated back to the mirror so it failed with no such revision. This is something I'm used to and it usually means wait a few seconds and try again - but I don't know how to try again in the middle of a failed release:prepare. You just run 'mvn relese:prepare' again after waiting for a little while. I made a patch for the release plugin to handle this more gracefully. It was added in version 2.2. See http://jira.codehaus.org/browse/MRELEASE-613 So far I created the tag manually, changed the POM to 1.3-SNAPSHOT and started the further release process from a checked out copy of the tag. I.e. I basically switched to the manual mode of doing releases. Is there anything else the release plugin would have done? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[graph] Do we have any documentation or examples?
Hi I have an idea that requires a library that can construct graphs and turn them into images. A quick look at the source tree for Commons Graph shows no sign of examples or documentation. Are there any? Would Commons Graph fit into my requirements above? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: JIRA report usefulness (was: [VOTE] Release Commons NET 3.0.1 based on RC3)
On 2011-06-04 19:33, Henri Yandell wrote: On Fri, Jun 3, 2011 at 7:43 PM, Phil Steitz phil.ste...@gmail.com wrote: On 6/3/11 7:27 PM, Henri Yandell wrote: On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi simonetrip...@apache.org wrote: I think that is also best practice - resolve when fixed in SVN, close when fix version is released. I couldn't agree more!!! +1! I just close directly. The resolve then close is a workflow waiting for a reason :) The reason is that until a release has been cut including the fix, it is still a problem faced by users. Just fixing in svn should not close the issue. Not a good enough reason imo. If 'Resolved' was called 'Committed' and 'Closed' was 'Released', then maybe. As it is we'll have a workflow that is meaningless to anyone but the committers; and they can already look at whether the fix version has been released or not. If Atlassian hadn't made the mistake of a 2 stage resolution as their default; we wouldn't be looking for a solution. As they did everyone (not just here, it's a JIRA anti-pattern) tries to apply a workflow to the Resolve/Close step. The way I try to use this over in Maven land, is like this. When I have committed a fix for an issue and have deployed a new SNAPSHOT of it to a public repo, I Resolve the issue. In an ideal world the user then tries the new SNAPSHOT to verify that it solves his/her problem, and the user then Close the issue. Or he/she asks the developer to do it for them by stating that the issue has been fixed. If the user is no longer around I just close the issue *before* the release is made. The Status field doesn't tell us whether the fix has been released or not. That is what the Fix version/s field is for. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: JIRA report strategy; how to handle duplicates?
On 2011-06-04 17:06, sebb wrote: I've been doing some experimentation with the JIRA report. The following configuration IMO produces a reasonable-looking report [1]: onlyCurrentVersionfalse/onlyCurrentVersion columnNamesFix Version,Key,Summary,Type,Resolution,Status/columnNames !-- Sort cols have to be reversed in JIRA 4 -- sortColumnNamesKey DESC,Type,Fix Version DESC/sortColumnNames resolutionIdsFixed/resolutionIds statusIdsResolved,Closed/statusIds !-- Don't include sub-task -- typeIdsBug,New Feature,Task,Improvement,Wish,Test/typeIds As mentioned elsethread, issues should be marked as resolved with the appropriate fix version when fixed in SVN; and issues should only be closed after the release has been published. What is not so clear is how to handle duplicate reports. If these are to be included in the report, then the Fix versions will have to be maintained. IMO duplicates should not be included in the report. If they are descriptions of the same problem, then they do not add any value in the report. If not, then it's important that all duplicates are resolved as Duplicate rather than Fixed. Yes, that my preference as well. I usually create a Duplicates link between the two issues in JIRA first and then immediately Close the latest issue as Duplicate. Views? [1] http://people.apache.org/~sebb/NET_3_0_1RC3/jira-report.html Additionally filtered as follows: fixVersionIds3.0.1,3.0,2.2/fixVersionIds - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discovery] dropping the ant stuff
Phil Steitz skrev 2011-04-10 16:42: On 4/10/11 12:48 AM, Simone Tripodi wrote: Hi all guys, the ant build is no longer working anymore, build.properties files are missing and lib/*.jar too, I propose to remove ant stuff before RC2. Do you agree? Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Let me have a look at it. Where possible, I think it is best to maintain working Ant builds. If the original Ant build file doesn't do anything fancy, we could use the Maven Ant Plugin [1] to generate a working Ant build.xml file based on the pom.xml. [1] http://maven.apache.org/plugins/maven-ant-plugin/ Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] consistent website page titles
+1 On 2011-03-27 15:33, sebb wrote: Our website page titles are currently rather inconsistent: For example, sample LANG titles are as follows Lang - Home (on index page): Lang - Building Lang - Download Commons Lang Lang - Home (this is on the release history page!) And NET Commons Net - Apache Commons Net I think it would be clearer if the first part of the title (defined in the site.xml project name attribute) were always Apache Commons Foo, and individual pages would then not need to mention the component name again, just the content of the page. For example, LANG page titles would become: Apache Commons Lang - Home Apache Commons Lang - Building Apache Commons Lang - Release History etc. I don't think there's any need to fix this retrospectively, but it would be good to fix this for new site depoloyments. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Commons Skin 3 and Commons Parent 20 released
On 2011-03-19 03:50, sebb wrote: Commons Skin and Parent have been updated, mainly to support the new PMC trademark guidelines, but some plugins were also updated. In particular maven-site-plugin was updated to 2.2.1. Version 2.2 in Parent 17 and 18 has a bug which causes problems with some sites. This must be a typo of some kind. There is no 2.2.1 version of Maven Site Plugin. 2.2 is the latest released version. Commons Skin 3 changes (from 2) = - commons parent 5 = 18 - added support for code prettify - site.css now uses relative url for referencing css files, so offline sites work better - added template to support trademark footer; also supports $relativePath resolution; adds TM overlay support; allows absolute URLs in banner elements Commons Parent 19 changes (from 18) == - Apache Parent Pom 7= 9 - maven-antrun-plugin 1.3 = 1.5 - antrun config: change deprecated tasks to target - updated site plugin to 2.2.1 (2.2 is broken) - surefire 2.7.1 = 2.7.2 - javadoc 2.5 = 2.7 - add AL header to site.xml - use local copy of commons-logo, rather than linking to commons.a.o - always use absolute link for http://commons.a.o/ - commons skin 2=3 - added prettify css/javascript to improve source code formatting - license now points to http://www.apache.org/licenses/ as per branding guidelines - synchronise common menu items with commons-site - moved ApacheCon logo under ASF menu, and made it clickable - added trademark references to page footers - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [parent] maven 3 vs. 2 trick not inherited from commons-parent
On 2011-03-11 08:32, Jochen Wiedmann wrote: Stupid question: Is there any reason for not using the 3.x site plugin with Maven 2? There were quite a lot of internal changes made in Maven 3, that requires a different approach to site generation compared to Maven 2. Some work has begun where we're trying to see if it's possible to make the 3.x Site Plugin compatible with Maven 2, but it's in its still infancy. On Thu, Mar 10, 2011 at 10:08 PM, Gary Gregory garydgreg...@gmail.com wrote: In [paren] v18, we have a nice trick to use maven-site-plugin 2.x with Maven 2.x and maven-site-plugin 3.x with Maven 3.x . See http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html If you want to look at the parent POM, look for: profile idmaven-3/id But, this does not work. When I have the same bit of XML in [codec]'s POM for example, it works. Any ideas what needs to be done for this to work without adding the XML to every project? For [codec], it just works, you invoke m2 or m3 without additional arguments. -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
done so it will never attempt to download it again. This means that even if we were allowed to update a new variant of commons-email:commons-email:1.0 with relocation info in it, users who have already downloaded commons-email:commons-email:1.0 will still use the old variant of the POM. What we would have now is a nightmare - the build would work correctly (only one version of commons-email in the classpath) on one machine but not on another (two versions of commons-email in the classpath). The policy of the central repository was put in place in order to have consistent builds across *all* machines. In the case of Commons-email, the process was not actually followed, so Maven does not eliminate the additional mail jar. The process was followed as far as it was allowed to. When 1.1 was released under the org.apache.commons groupId a relocation POM was uploaded at the old groupId for the *new* (1.1) version. But not for the *old* (1.0) version, because it is not allowed. Commons-email had only one or two formal releases under the old groupId, so the amount of work to be done was quite small. [Even so, it was not all done]. For a component with lots of versions, it will take some while to assemble all the required files, and it will take a while to upload them. So there is a chance that builds during the transition process will fail. By careful sequencing of updates, it may be possible to reduce the likelihood of failures, but I'm not sure it is possible to eliminate them entirely. [Who wants to be responsible for relocating commons-logging?] I'm not saying we should not change groupIds if we want, but I think the single example of commons-email is insufficient to show that it will be trouble-free unless a lot of care is taken when doing the migration. Does anyone know if there is an automated process for doing this? It is not a matter of whether it can be done manually or automatically. Either way - it will not work, for the reasons I gave above. What we are left with is a compromise: when we release a binary incompatible version of a component, we change the package name and the groupId at the same time. This is not an ideal solution, but it works and it'll keep our users sane in the long run. Niall Niall I do not understand enough about the Maven guts to grok the consequences... Thanks in advance for any clarification. Gary Gary On Tue, Mar 8, 2011 at 9:28 PM, Gary Gregory garydgreg...@gmail.com wrote: Reverting and will do for 2.0. Gary On Tue, Mar 8, 2011 at 8:00 PM, sebb seb...@gmail.com wrote: On 9 March 2011 00:02, ggreg...@apache.org wrote: Author: ggregory Date: Wed Mar 9 00:02:12 2011 New Revision: 1079608 URL: http://svn.apache.org/viewvc?rev=1079608view=rev Log: Use org.apache.commons groupId If you change the groupId you'll probably need to change the package name as well .. Otherwise Maven can add two copies of the jar to the classpath, which is not good when there are two copies of the same classes. Modified: commons/proper/codec/trunk/pom.xml Modified: commons/proper/codec/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/codec/trunk/pom.xml?rev=1079608r1=1079607r2=1079608view=diff == --- commons/proper/codec/trunk/pom.xml (original) +++ commons/proper/codec/trunk/pom.xml Wed Mar 9 00:02:12 2011 @@ -25,7 +25,7 @@ version18/version /parent modelVersion4.0.0/modelVersion - groupIdcommons-codec/groupId + groupIdorg.apache.commons/groupId artifactIdcommons-codec/artifactId version1.5-SNAPSHOT/version nameCommons Codec/name - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1079608 - /commons/proper/codec/trunk/pom.xml
On 2011-03-10 15:01, sebb wrote: On 10 March 2011 13:46, Dennis Lundberg denn...@apache.org wrote: On 2011-03-10 00:36, sebb wrote: On 9 March 2011 12:01, Niall Pemberton niall.pember...@gmail.com wrote: On Wed, Mar 9, 2011 at 11:20 AM, sebb seb...@gmail.com wrote: On 9 March 2011 10:30, Niall Pemberton niall.pember...@gmail.com wrote: On Wed, Mar 9, 2011 at 2:46 AM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Mar 8, 2011 at 9:34 PM, sebb seb...@gmail.com wrote: On 9 March 2011 02:31, Gary Gregory garydgreg...@gmail.com wrote: Does having the old style of groupId mean that deploying will not work, per http://wiki.apache.org/commons/UsingNexus#top All Commons components that use the org.apache.commons groupId are already set up to use Nexus. And if not... what happens? Nexus won't let you upload. Two options: - use the old methods. These can work, but are error prone. - use JIRA to request a Nexus entry for the project. Ug, I cannot change the groupId because I cannot change the package. Codec 1.5 fixes some long standing bugs introduced in 1.4. IMO our build system should never be the driving factor behind changing the package name. If I change the groupId... Are we talking end of the Maven world or wasted memory? No, potentially users could end up with two versions of codec on their classpath - if the dependency is inherited from other dependencies that use the different groupIds. They can resolve this easily by adding exclude elements to their pom. But what if the dependency is from someone elses component? Does that work? Yes, you do something like the following: dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-codec/artifactId version1.5/version /dependency dependency groupIdfoo/groupId artifactIdbar/artifactId version3.1/version exclusions exclusion groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId /exclusion /exclusions /dependency dependencies A bit of a PITA, but not the end of the world. Ideally though you would put re-location poms in place for the old vesions of codec and move them to the new groupid. The downside to that is that if people have the old versions already locally, maven doesn't go back to the repo and misses the relocation. This is also easily resolved, by people removing those versions from the local maven repo. That should always be possible. commons-email re-located to the new groupid quite a while ago and theres been no complaints so far - see: http://repo2.maven.org/maven2/commons-email/commons-email/1.1/ http://repo2.maven.org/maven2/org/apache/commons/commons-email/ Although there will be some pain, I think we should bite the bullet and relocate commons components. I'd like to see some testing first, especially before we relocate low level components such as commons-logging. You can test away on commons-email - :) Have just tried it. There are only 3 proper versions of commons-email (1.0, 1.1, 1.2) Here is what I set up: module1 depends on o.a.c:c-mail:1.2 and module2 module2 depends on c-mail:c-mail:1.1 and module3 module3 depends on c-mail:c-mail:1.0 mvn dependency:build-classpath includes two copies of commons-email: D:\repository\commons-email\commons-email\1.0\commons-email-1.0.jar D:\repository\org\apache\commons\commons-email\1.2\commons-email-1.2.jar Maven has eliminated c-mail:c-mail:1.1 because it has a relocation pom which means it is regarded as the same as 1.2. c-mail:c-mail:1.0 does not have a relocation pom, so Maven thinks it is a different component, and keeps it in the classpath. Yes, I could have excluded c-mail:1.0 in module1, but in general it would not be at all obvious that there was a duplicate classpath entry. The order in which classes are referenced and loaded may vary, and only some orderings may cause problems for an application. Could be hard to track down such problems. == This makes sense now. Provided *all* old groupId versions have a relocation pom (and provided that the local workspace is refreshed if necessary), then clearly Maven does have the information needed to realise that the two groupIds are the same. I don't understand why no-one replied with this information when I asked on the mailing list. You are correct in your conclusions here. So in this regard relocation POMs do work. The real problem is that the policy of the central Maven repository prevents us from uploading relocation POMs for all old groupId version. This policy states that you cannot upload new variants of files that are already in the repository, i.e. we are not allowed to upload a new variant of the POM for commons-email:commons-email:1.0 that contains relocation information. The reasons for this are technical. Maven will download
Re: [SITE] skin discussion (was: [SITE] commons-build - is it still used?)
, it would not be enough to redeploy commons-site and all the components. It just seems wrong to have the source for some of the key CSS files stored in an component that cannot easily be deployed (commons-build uses Maven 1). And even if one did deploy it, AFAICT the only useful output is the style directory - the rest seems to be old documentation that would then have to be overwritten by deploying commons-site. The reason I need to do this now is that I need to create a new version of commons-theme.css without the ApacheCon background logo. This will be referenced in the new commons-skin via the site.css file. I think it makes more sense to store the style files in commons-site, so they will be uploaded whenever the commons-site is redeployed. This will make changes easier going forward. Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1074931 - /commons/proper/commons-skin/trunk/src/main/resources/META-INF/maven/site.vm
/prettify.css);
/style
link rel=stylesheet href=$relativePath/css/print.css
type=text/css media=print /
-script type=text/javascript
src=$relativePath/js/prettify.js/script
-script type=text/javascript
-window.onload=function() {
-prettyPrint();
-}
-/script
-#foreach( $author in $authors )
+#foreach( $author in $authors )
meta name=author content=$author /
-#end
+#end
#if ( $dateCreation )
meta name=Date-Creation-mmdd content=$dateCreation /
#end
#if ( $dateRevision )
meta name=Date-Revision-mmdd content=$dateRevision /
#end
+#if ( $locale )
+meta http-equiv=Content-Language content=$locale.language /
+#end
#if ( $decoration.body.head )
#foreach( $item in $decoration.body.head.getChildren() )
## Workaround for DOXIA-150 due to a non-desired behaviour in p-u
## @see org.codehaus.plexus.util.xml.Xpp3Dom#toString()
## @see org.codehaus.plexus.util.xml.Xpp3Dom#toUnescapedString()
-#set ( $documentHeader = ?xml version=\1.0\
encoding=\UTF-8\? )
-#set ( $documentHeader = $documentHeader.replaceAll( \\, ) )
+#set ( $documentHeader = '?xml version=1.0 encoding=UTF-8?' )
#if ( $item.name == script )
$StringUtils.replace( $item.toUnescapedString(), $documentHeader,
)
#else
@@ -354,45 +498,52 @@
#end
#end
#end
+$headContent
+#googleAnalytics( $decoration.googleAnalyticsAccountId )
/head
- body
-div id=wrapper
-div id=banner
- #banner( $decoration.bannerLeft bannerLeft )
- #banner( $decoration.bannerRight bannerRight )
- div class=clear
-hr/
- /div
-/div
-div id=breadcrumbs
- #publishDate( left $decoration.publishDate $decoration.version )
- div class=xright#links( $decoration.body.links )#publishDate(
right $decoration.publishDate $decoration.version )/div
- div class=clear
-hr/
- /div
-/div
-div id=leftColumn
- div id=navcolumn
- #publishDate( navigation-top $decoration.publishDate
$decoration.version )
- #mainMenu( $decoration.body.menus )
- #poweredByLogo( $decoration.poweredBy )
- #publishDate( navigation-bottom $decoration.publishDate
$decoration.version )
- /div
-/div
-div id=bodyColumn
- div id=contentBox
-$bodyContent
- /div
-/div
-div class=clear
- hr/
-/div
-div id=footer
- div class=xrightCopyright #169;#copyright()All Rights
Reserved.#publishDate( bottom $decoration.publishDate $decoration.version
)/div
- div class=clear
-hr/
- /div
-/div
+ body class=composite
+div id=banner
+ #banner( $decoration.bannerLeft bannerLeft )
+ #banner( $decoration.bannerRight bannerRight )
+ div class=clear
+hr/
+ /div
+/div
+div id=breadcrumbs
+ #publishDate( left $decoration.publishDate $decoration.version )
+ div class=xright#links( $decoration.body.links )#publishDate(
right $decoration.publishDate $decoration.version )/div
+ div class=clear
+hr/
+ /div
+/div
+div id=leftColumn
+ div id=navcolumn
+ #publishDate( navigation-top $decoration.publishDate
$decoration.version )
+ #mainMenu( $decoration.body.menus )
+ #poweredByLogo( $decoration.poweredBy )
+ #publishDate( navigation-bottom $decoration.publishDate
$decoration.version )
+ /div
+/div
+div id=bodyColumn
+ div id=contentBox
+$bodyContent
+ /div
+/div
+div class=clear
+ hr/
+/div
+div id=footer
+#if ( $decoration.custom.getChild(footer) )
+ ## See DOXIA-150
+ #set ( $documentHeader = '?xml version=1.0 encoding=UTF-8?' )
+ #foreach( $item in $decoration.custom.getChild(footer).getChildren()
)
+ $StringUtils.replace( $item.toString().trim(), $documentHeader, )
+ #end
+#end
+ div class=xrightCopyright #169;#copyright()All Rights
Reserved.#publishDate( bottom $decoration.publishDate $decoration.version
)/div
+ div class=clear
+hr/
+ /div
/div
/body
/html
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SITE] Updates for Branding requirements
On 2011-02-26 01:41, Simone Tripodi wrote: Hi all guys, following the skin guide on [1], once imported the default-site.vm (I need to inject JS) even without altering it, when rendering the site the layout is completely a disaster ;( Does anyone knows some details I shall be aware of about the common skin before I continue debugging? If you copied the trunk of default-site.vm, you'd need to use the latest Doxia (which the default-site.vm is a part of). The easiest way to do that is to use the latest version of Maven Site Plugin, which is 2.3-SNAPSHOT at the moment. We (the Maven community) need to document this better, but until recently not many changes have been made to the default-sit.vm file. You say that the layout is a disaster, can you send me a screen shot or post one somewhere? Many thanks in advance! Simo [1] http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 7:14 PM, Simone Tripodi simonetrip...@apache.org wrote: Sure, will be ready in a short while. It's almost time for dinner now here in Italy, once done I'll make the patch! chat l8r, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 5:31 PM, Gary Gregory garydgreg...@gmail.com wrote: I like the code syntax highlighting. Gary On Feb 25, 2011, at 11:10, Simone Tripodi simonetrip...@apache.org wrote: Hi all, maybe I'm a little off-topic, but I'd like to take advantage to restyle a little the commons-skin, just adding the code syntax highlighter like I did for the Cocoon skin[1]. WDYT? Have a nice day!!! Simo [1] http://cocoon.apache.org/3.0/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 4:40 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Feb 25, 2011 at 2:57 PM, sebb seb...@gmail.com wrote: On 25 February 2011 02:52, sebb seb...@gmail.com wrote: We have just been through the exercise of updating the HttpComponents site [2] to try to conform with the branding requirements [1]. In the process, we found the standard Maven site templates a bit limiting, so we created a Maven skin [3] to make the process easier. As it turned out, the skin did not need any HC-specific code, so it can be used on other sites if required - it might be helpful here in Commons. I'd overlooked that commons already has a Maven skin (which is specific to Commons). However, it would be possible to take a copy of the VM template from the HC skin and add it to the Commons skin to get the new functionality. Sounds good. Remember you need to first release commons-skin, then commons-parent. Niall For the ApacheCon logo, we used a a poweredBy tag [4] - this has the advantage that it allows the logo to be clickable. [1] http://www.apache.org/foundation/marks/pmcs [2] http://hc.apache.org/ [3] http://hc.apache.org/dev-docs.html#Maven_Skin_details [4] https://svn.apache.org/repos/asf/httpcomponents/project/src/site/site.xml - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SITE] Updates for Branding requirements
On 2011-02-26 15:24, Simone Tripodi wrote: Just 1 question: last released version is commons-skin-2, on trunk we still have 2-SNAPSHOT, do you agree shall be 3-SNAPSHOT? Yes, it should be 3-SNAPSHOT http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Feb 26, 2011 at 3:21 PM, sebb seb...@gmail.com wrote: On 26 February 2011 14:02, Simone Tripodi simonetrip...@apache.org wrote: Hi Sebastian, the skin has been fixed, you can see the results on http://people.apache.org/~simonetripodi/digester3-2/guide/core.html Let me know what you prefer * I make a patch; * I commit directly. You might as well update commons-skin directly. I can then apply the changes from HC. Just let me know, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Feb 26, 2011 at 2:41 PM, Simone Tripodi simonetrip...@apache.org wrote: Indeed, I can't figure how - and from where - it was imported in the previous version, in the meanwhile I uploaded the skin with the syntax-highlighter, just to let you see the result http://people.apache.org/~simonetripodi/digester3-2/guide/core.html I'll let you know asap, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Feb 26, 2011 at 2:25 PM, sebb seb...@gmail.com wrote: On 26 February 2011 12:54, Simone Tripodi simonetrip...@apache.org wrote: Hi Dennis, thanks a lot for your help, I uploaded the Digester3 site on my apache space so you can review the generated site, you can reach it on http://people.apache.org/~simonetripodi/digester3/ It looks like there are some CSS files missing - e.g. maven-base.css. Thanks!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Feb 26, 2011 at 1:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-02-26 01:41, Simone Tripodi wrote: Hi all guys, following the skin guide on [1], once imported the default-site.vm (I need to inject JS) even without altering it, when rendering the site the layout is completely a disaster ;( Does anyone knows some details I shall be aware of about the common skin before I continue debugging? If you copied the trunk of default-site.vm, you'd need to use the latest Doxia (which the default-site.vm is a part of). The easiest way to do that is to use the latest version of Maven Site Plugin, which is 2.3-SNAPSHOT at the moment. We (the Maven community) need to document this better, but until recently not many changes have been made to the default-sit.vm file. You say that the layout is a disaster, can you send me a screen shot or post one somewhere? Many thanks in advance! Simo [1] http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 7:14 PM, Simone Tripodi simonetrip...@apache.org wrote: Sure, will be ready in a short while. It's almost time for dinner now here in Italy, once done I'll make the patch! chat l8r, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 5:31 PM, Gary Gregory garydgreg...@gmail.com wrote: I like the code syntax highlighting. Gary On Feb 25, 2011, at 11:10, Simone Tripodi simonetrip...@apache.org wrote: Hi all, maybe I'm a little off-topic, but I'd like to take advantage to restyle a little the commons-skin, just adding the code syntax highlighter like I did for the Cocoon skin[1]. WDYT? Have a nice day!!! Simo [1] http://cocoon.apache.org/3.0/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Feb 25, 2011 at 4:40 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Feb 25, 2011 at 2:57 PM, sebb seb...@gmail.com wrote: On 25 February 2011 02:52, sebb seb...@gmail.com wrote: We have just been through the exercise of updating the HttpComponents site [2] to try to conform with the branding requirements [1]. In the process, we found the standard Maven site templates a bit limiting, so we created a Maven skin [3] to make the process easier. As it turned out, the skin did not need any HC-specific code, so it can be used on other sites if required - it might be helpful here in Commons. I'd overlooked that commons already has a Maven skin (which is specific to Commons). However, it would be possible to take a copy of the VM template from the HC skin and add it to the Commons skin to get the new functionality. Sounds good. Remember you need to first release commons-skin, then commons-parent. Niall For the ApacheCon logo, we used a a poweredBy tag [4] - this has the advantage that it allows the logo to be clickable. [1] http://www.apache.org/foundation/marks/pmcs [2] http://hc.apache.org/ [3] http://hc.apache.org/dev-docs.html#Maven_Skin_details [4] https://svn.apache.org/repos/asf/httpcomponents/project/src/site/site.xml
Re: [site][commons-parent] Build with Maven 2 and 3.
On 2011-01-20 17:45, Gary Gregory wrote: Hi All, I recently added a profile to commons-parent that allows a build to use the Maven site 2.x plugin on Maven 2.x and Maven site 3.x plugin on Maven 3.x. I just got [codec] to build both ways using this profile (in codec's POM.) I had to override a couple of things in codec's pom.xml. I would like to push these changes up to commons-parent: - maven-site-plugin 2.0.1 - 2.2 - maven-project-info-reports-plugin 2.1.2 - 2.3.1 Thoughts? +1 for the change Note that this will require at least Maven 2.2.0, which in practice means Maven 2.2.1. That in turn requires Java 5. These requirements are for running Maven with the plugins mentioned above. Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.commailto:ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.comhttp://www.seagull.rocketsoftware.com/ -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [site][commons-parent] Build with Maven 2 and 3.
On 2011-01-20 21:05, Gary Gregory wrote: -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, January 20, 2011 14:59 To: Commons Developers List Subject: Re: [site][commons-parent] Build with Maven 2 and 3. On 2011-01-20 17:45, Gary Gregory wrote: Hi All, I recently added a profile to commons-parent that allows a build to use the Maven site 2.x plugin on Maven 2.x and Maven site 3.x plugin on Maven 3.x. I just got [codec] to build both ways using this profile (in codec's POM.) I had to override a couple of things in codec's pom.xml. I would like to push these changes up to commons-parent: - maven-site-plugin 2.0.1 - 2.2 - maven-project-info-reports-plugin 2.1.2 - 2.3.1 Thoughts? +1 for the change Note that this will require at least Maven 2.2.0, which in practice means Maven 2.2.1. That in turn requires Java 5. These requirements are for running Maven with the plugins mentioned above. Yes indeed. And don't forget your passport to the 21st century! :) IMO, requiring Java 5 to build is a more than reasonable requirement. Yes, I totally agree. I just wanted to point it out in case someone encounters problems. Gary Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.commailto:ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.comhttp://www.seagull.rocketsoftware.com/ -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-parent] Using maven-site-plugin 2.x with Maven 2.x and maven-site-plugin 3.x with Maven 3.x
On 2011-01-19 16:06, Gary Gregory wrote:
Hi All:
I'd like to get Maven 3 working with various projects and [codec] today.
To get Maven 3 to work, I'd like to add the following profile to the
commons-parent POM.
See http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html
Any objections or thoughts?
Go ahead and do it.
Thank you,
Gary
Index: pom.xml
===
--- pom.xml(revision 1060831)
+++ pom.xml (working copy)
@@ -759,6 +759,45 @@
module../vfs/module
/modules
/profile
+
+ !--
+ Using maven-site-plugin 2.x with Maven 2.x and
maven-site-plugin 3.x with Maven 3.x
+ See
http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html
+ --
+profile
+ idmaven-3/id
+ activation
+file
+ !-- The basedir expression is only recognized by Maven 3.x (see
MNG-2363) --
+ exists${basedir}/exists
+/file
+ /activation
+ build
+pluginManagement
+ plugins
+plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-site-plugin/artifactId
+ version3.0-beta-3/version
+/plugin
+ /plugins
+/pluginManagement
+plugins
+ plugin
+artifactIdmaven-site-plugin/artifactId
+executions
+ execution
+idattach-descriptor/id
+goals
+ goalattach-descriptor/goal
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+
/profiles
properties
Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
Tel: +1.404.760.1560
Email: ggreg...@seagullsoftware.commailto:ggreg...@seagullsoftware.com
Web: seagull.rocketsoftware.comhttp://www.seagull.rocketsoftware.com/
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] time to move groupId?
When you say consistent, what are you referring to? The fact that lang has done it once? It is not the Maven way to change the artifactId when a new major version comes out. And since we are talking about the Maven coordinates (groupId, artifactId, version) I think it is best to follow the standard Maven way of doing it. On 2010-10-16 00:28, James Carman wrote: I didn't say it was required. I said it was a good idea, because it would keep things consistent. On Fri, Oct 15, 2010 at 5:39 PM, Dennis Lundberg denn...@apache.org wrote: Changing the artifactId is not necessary. At least if we predict that we will not change the groupId again. In Maven the combination of groupId, artifactId and version is unique. So org.apache.commons:commons-pool:2.0 and org.apache.commons:commons-pool:3.0 are two unique artifacts. On 2010-10-15 20:43, James Carman wrote: If we do change the package name to pool2, then I'd suggest the artifact id change too so that everything stays consistent. So, the new artifact id would be commons-pool2 rather than commons-pool. On Fri, Oct 15, 2010 at 2:40 PM, James Carman ja...@carmanconsulting.com wrote: If you change the group id, it's probably best to go ahead and change the package names also, in case two versions show up on the same classpath. Maven won't know that org.apache.commons:common-pool is the same as commons-pool:commons-pool, so it would potentially put both on the classpath. I believe there are also binary compatibility issues (hence the 2.0), so changing that would mean we'd want to change it also. On Fri, Oct 15, 2010 at 2:34 PM, Phil Steitz phil.ste...@gmail.com wrote: +1 for 2.0. We should also talk about the ugliness that we should probably also do for 2.0: o.a.c.pool2 or somesuch. On Oct 15, 2010, at 12:20 PM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all mates, is this the right time to move the pool grouId to org.apache.commons? Many thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] time to move groupId?
On 2010-10-16 16:58, James Carman wrote: On Sat, Oct 16, 2010 at 10:52 AM, sebb seb...@gmail.com wrote: Why? I don't see the point. We had this discussion long ago. Let me try to summarize for you. Suppose Project X wants to use commons foo version 2. Suppose also that Project X uses Project Y as a dependency and Project Y uses commons foo version 1 (jar hell). Now, foo version 1 and 2 are binary incompatible. If we leave them with the same group/artifact and with different versions, then Maven will only allow foo version 2 on the classpath as a dependency because it is the most recent. So, the code in Project Y won't work. However, if foo version 2 changes its artifact id and changes its package name, the code in Project X can code against org.apache.commons.foo2 and the code in Project Y can code against org.apache.commons.foo and both will stay happy. Also, Maven will allow both on the classpath at the same time since they're not the same artifact id. Thanks for that explanation James. This is a use case that requires a change in artifactId. It would allow a project to use multiple versions of a commons library (which are in different Java packages) at the same time. Note: yes I know this problem goes away with OSGi, but not everyone is using OSGi, nor should we require them to do so. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] time to move groupId?
Changing the artifactId is not necessary. At least if we predict that we will not change the groupId again. In Maven the combination of groupId, artifactId and version is unique. So org.apache.commons:commons-pool:2.0 and org.apache.commons:commons-pool:3.0 are two unique artifacts. On 2010-10-15 20:43, James Carman wrote: If we do change the package name to pool2, then I'd suggest the artifact id change too so that everything stays consistent. So, the new artifact id would be commons-pool2 rather than commons-pool. On Fri, Oct 15, 2010 at 2:40 PM, James Carman ja...@carmanconsulting.com wrote: If you change the group id, it's probably best to go ahead and change the package names also, in case two versions show up on the same classpath. Maven won't know that org.apache.commons:common-pool is the same as commons-pool:commons-pool, so it would potentially put both on the classpath. I believe there are also binary compatibility issues (hence the 2.0), so changing that would mean we'd want to change it also. On Fri, Oct 15, 2010 at 2:34 PM, Phil Steitz phil.ste...@gmail.com wrote: +1 for 2.0. We should also talk about the ugliness that we should probably also do for 2.0: o.a.c.pool2 or somesuch. On Oct 15, 2010, at 12:20 PM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all mates, is this the right time to move the pool grouId to org.apache.commons? Many thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1022277 - /commons/proper/pool/trunk/pom.xml
Checkstyle plugin 2.4+ uses Checkstyle 5, which has a slightly altered
configuration format. If you upgrade to 2.4+ you also need to change the
Checkstyle configuration file. Let me know if you need details, and I'll
dig them up for you.
On 2010-10-13 22:13, Niall Pemberton wrote:
Would be better to upgrade to the more recent checkstyle plugin (2.6)
- see details in the commit log:
http://svn.apache.org/viewvc?view=revisionrevision=1005273
Niall
On Wed, Oct 13, 2010 at 9:06 PM, ggreg...@apache.org wrote:
Author: ggregory
Date: Wed Oct 13 20:06:41 2010
New Revision: 1022277
URL: http://svn.apache.org/viewvc?rev=1022277view=rev
Log:
maven-checkstyle-plugin 2.1 - 2.3 (2.4 fails with Embedded error: Error
rendering Maven report: Failed during checkstyle configuration TreeWalker is
not allowed as a parent of Header)
Modified:
commons/proper/pool/trunk/pom.xml
Modified: commons/proper/pool/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1022277r1=1022276r2=1022277view=diff
==
--- commons/proper/pool/trunk/pom.xml (original)
+++ commons/proper/pool/trunk/pom.xml Wed Oct 13 20:06:41 2010
@@ -246,7 +246,7 @@
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
- version2.1/version
+ version2.3/version
configuration
configLocation${basedir}/checkstyle.xml/configLocation
enableRulesSummaryfalse/enableRulesSummary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Preparing for Maven 3
On 2010-10-07 03:46, Niall Pemberton wrote: The vote for Maven 3 is underway - http://markmail.org/message/4itian33hycyt4iz I have tested the builds for all the components in trunks-proper (using mvn -Prc clean package) and they worked, except for test failures with configuration, email and jci - but I get those using m2 as well. Thanks for testing Niall. Theres an issue with the commons-build-plugin which I need to look at and I had a problem with the gpg plugin when doing mvn -Prc install on a component. Probably the biggest issue though is getting the sites working. The reporting section is deprecated in m3 and reports need to be configured differently and a new (m3 specific) version of the site plugin used. I've tried this out adding m3 profiles to branches of commons-parent and chain: https://svn.apache.org/repos/asf/commons/proper/commons-parent/branches/maven-3-test/ https://svn.apache.org/repos/asf/commons/proper/chain/branches/test-maven3-profile/ The above have a profile which *activates* when m3 is used - as described here: https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html This profile approach to support both m2 and m3 is one way - but would create a mess of duplicated configuration in all poms. It would be much cleaner and less maintenance if we just adopted m3 and dropped m2 support :) We should be able to put the m3 profile in commons-parent to avoid the duplication. I guess it will take a while for a consensus on this (if ever) but its something to consider. In the meantime there is stuff we can do to prepare for m3. It would be good to put reporting plugins into the pluginManagement section of commons-parent. The Site Plugin for Maven 3 will work with (almost) the same configuration as the Site Plugin for Maven 2. It will transform the old configuration format to the new one on-the-fly. To be able to have our builds support both Maven 2 and Maven 3, there are only a few things that we need to do. Once we (the Maven team) get the Site Plugin for Maven 3 into a good enough state, I'll get back with more info. Quite a few components are on old versions of reporting plugins, so testing and upgrading to the latest would be good. The one I had most problems with was Checkstyle - details in the commit log: http://svn.apache.org/viewvc?view=revisionrevision=1005273 Updating plugins is a good idea, especially to versions that support Maven 3, for more info see https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] problems on pushing the RC2
Just run the same command again after waiting for 10 second or so. mvn release:prepare See also http://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven On 2010-09-16 14:37, Simone Tripodi wrote: Hi all guys, even if it not blocking, I'd like to know why the maven-release-plugin fails when committing the tag. When launching --- mvn -Prc release:prepare --- when prompt, I insert these data: --- What is the release version for Commons Digester? (commons-digester:commons-digester) 2.1: : What is SCM release tag or label for Commons Digester? (commons-digester:commons-digester) commons-digester-2.1: : DIGESTER_2_1_RC2 What is the new development version for Commons Digester? (commons-digester:commons-digester) 2.2-SNAPSHOT: : 2.1-SNAPSHOT --- The build arrives until signing the artifacts, then fails when committing the tag: --- [INFO] Executing: /bin/sh -c cd /XXX/commons-digester svn --non-interactive commit --file /var/folders/tA/tAi8rfQBEXu-Q2YdN8j4ZU+++TQ/-Tmp-/maven-scm-832812699.commit --targets /var/folders/tA/tAi8rfQBEXu-Q2YdN8j4ZU+++TQ/-Tmp-/maven-scm-1900525631622526321-targets [INFO] Working directory: /XXX/commons-digester [INFO] Tagging release with the label DIGESTER_2_1_RC2... [INFO] Executing: /bin/sh -c cd /XXX/commons-digester svn --non-interactive copy --file /var/folders/tA/tAi8rfQBEXu-Q2YdN8j4ZU+++TQ/-Tmp-/maven-scm-1520634295.commit --revision 997717 https://svn.apache.org/repos/asf/commons/proper/digester/trunk https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER_2_1_RC2 [INFO] Working directory: /XXX/commons-digester [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: No such revision 997717 --- It happened twice :( Can anyone help me to understand please? Many thanks in advance! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] NPE when generating JIRA report
On 2010-09-05 16:54, Simone Tripodi wrote: DONE!!! the scp has been successfully completed :) Now waiting to see the update site online :P If you are impatient, like I am, you can use a proxy to make sure that the site looks ok before it goes into production. Read about the proxy at http://www.apache.org/dev/project-site.html#intro Personally I use the QuickProxy add-in in Firefox to quickly switch between using and not using the proxy. Namaste, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Sep 5, 2010 at 4:44 PM, Simone Tripodi simone.trip...@gmail.com wrote: OK sorry for the misunderstanding :P Namaste, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Sep 5, 2010 at 4:42 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sun, Sep 5, 2010 at 10:39 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi Rahul, sure, but I'd suggest to add the 2.1 and remove the 1.8 not at this stage, that we're just publishing the snapshot site. WDYT? snip/ Yes, indeed, thats what I meant (post release). Please go ahead with mvn site-deploy :-) -Rahul Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Sep 5, 2010 at 4:31 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sun, Sep 5, 2010 at 10:25 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi Rahul, thanks, just tried with the 2.3 version and it worked!!! Now trying the assemblies and other plugins... In the meanwhile, do you think I can run mvn site-deploy to publish the current site? snip/ Yes, that'd be good as a preview before the release. We should remove the 1.8 release from the LHS menu (so post release, we'd have 1.8.1, 2.0 and 2.1 there). -Rahul Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Sep 5, 2010 at 4:14 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sun, Sep 5, 2010 at 6:18 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all guys, while attempting to run the mvn site-deploy command I got an NPE when generating the JIRA report; even if not blocking I stopped the execution, can anyone please suggest me how to fix it? Follows below the stacktace, thanks in advance!!! snip/ Searched and found MCHANGES-126 [1]. Bumped plugin to latest version 2.3 in r992789 [2]. Site builds for me now. It'd be good to check if all plugins are using the best version possible before release. -Rahul [1] http://jira.codehaus.org/browse/MCHANGES-126 [2] http://svn.apache.org/viewvc?view=revisionrevision=992789 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Snapshot for 1.1 using Nexus
On 2010-08-09 17:30, Christian Grobmeier wrote: Just looked at the site plugin. There is a chance we could use mvn site:stage for this task: http://maven.apache.org/plugins/maven-site-plugin/usage.html One can stage with: mvn site:stage-deploy -DstagingDirectory=C:\fullsite -DstagingSiteURL=scp://www.mycompany.com/www/project/ or with: site idstagingSite /id nameApache Staging Website/name urlscp://path_to_staging_area/compress//url /site If no objections, I will try to use the commandline version of site:stage-deploy tomorrow. If that works we could add such a section in the project poms This is what we currently do over in Maven land to stage the site for a release. We use a specially crafted stagingSiteURL that is specified in a parent, which causes the staged site to end up on the normal web server, but in a versioned directory. For your use case I'd just put the staged site in your home dir on people.a.o Regards, Christian But I still need to stage the site. I understand now that release:perform should do it in the old way. Any ideas how we do it now? I could build it with mvn site and upload it to my apache webspace at people... but... Regards, Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Snapshot for 1.1 using Nexus
On 2010-08-08 13:38, Christian Grobmeier wrote: Does it distribute the artifacts to the dist folders also? Unfortunately not. Nexus currently only handles Maven artifacts. http://markmail.org/message/wmhm556j56757xt3#query:%22[Nexus]%20Only%20for%20Maven%20snapshots%20%2F%20releases%22+page:1+mid:wmhm556j56757xt3+state:results thanks for the link. So we need solutions for the following problems: 1) how can we stage a site to vote? 2) how do we create tags in svn (mvn release:prepare is too much, since its also staging build artifacts) No it doesn't. Here's what release:prepare does: http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html We have used it for ant based project because it so easy and helpful in handling the whole tagging business. 3) how do we move the Nexus artifacts to the dist area when they succeed. Its also about security here Did I miss another discussion around these topics? Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Parent Pom almost ready for snapshot deploy
On 2010-06-18 17:38, sebb wrote: I think the parent pom is almost ready for a snapshot deploy if anyone (e.g. Niall?) wants to do this: mvn -N deploy [-Ptest-deploy] Use the test-deploy profile to create the output under target/deploy. Not sure why, but the site.xml seems to be deployed along with the pom.xml. It is supposed to be deployed along with the pom.xml. The reason is that projects that inherit from commons-parent will also inherit the site.xml. At least with Nexus, that can easily be deleted before the site is promoted... [I just checked, and the same issue happens with the pom before the recent changes] S/// - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] preparing initial commit
up the module system with Dojo, and I think it is the most elegant possible approach, given the constraints of the technology. Please let me know what you think about this. Thanks, Jake [0] http://requirejs.org/docs/api.html#rhino - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DOC] Generating release notes from changes.xml
On 2010-04-14 04:04, Phil Steitz wrote: sebb wrote: It is useful to be able to generate both the announce message and release notes from changes.xml. One way to do this is as currently implemented in Compress: add a profile relnotes which overrides the changes template with the release-notes.vm template. One can then do: mvn changes:announcement-generate # = announcement.vm mvn changes:announcement-generate -Prelnotes # = release-notes.vm The template is assumed to be in src/changes, but it would be better if a shared template could be used, for example in commons-site. Have you tested moving it around? IIRC, I tried to move it but the plugin seemed to be hardcoded to start its path in src/site/resources. Could be I missed something or this has been fixed since I last tried. Is that the best place for it? I guess the release notes could - almost - be generically generated this way. I always end up post-editing, but other than formatting, I guess it can all be standardized. On the release announcements, I will personally continue to hand-craft those; but have no objection to maintaining a boilerplate . BTW, in order to allow for different workspace layouts, the template directory should be expressed as a property, which users can override in their settings.xml if they need to. To minimise the need for overrides, the default value for this property should reflect a popular workspace layout. In my case commons-compress and commons-parent etc are all at the same level, but perhaps it is more usual to use some other layout. This seems ugly. I guess there is no way to specify the file using a URL? Back in the m1 days, we used to all have to have commons-build checked out in the right location for site builds to work and that was a PITA. If the choice is between fiddling with settings.xml and/or other local workspace requirements and just duplicating the velocity templates, I would opt to duplicate the templates for those who wish to use them. The less mysterious, not-in-the-component-checkout stuff we have to deal with, the better. It is possible to have one or more templates in a separate resources-module with its own release cycle. Any component that wishes to use the template can add a dependency on the resources-module and thereby get access to the templates in it. We have this set up at my day job. Let me know if you want me to set it up for Commons. Phil [The idea would be to add the profile to the next release of commons-parent] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Non-standard maven source and test directories
On 2010-04-13 17:29, sebb wrote: On 12/04/2010, Dennis Lundberg denn...@apache.org wrote: On 2010-04-12 21:21, sebb wrote: On 12/04/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Sat, Apr 10, 2010 at 4:16 PM, sebb seb...@gmail.com wrote: 22 commons-proper projects are still using non-standard source and test directories, i.e. they are using: sourceDirectorysrc/java/sourceDirectory testSourceDirectorysrc/test/testSourceDirectory rather than the default: sourceDirectorysrc/main/java/sourceDirectory testSourceDirectorysrc/test/java/testSourceDirectory Do we want to fix those? I think its better to use the standard m2 layout but I don't think its a big deal. The one downside I see is that it can screw up existing patches - those can be fixed/manually edited but its an extra effort. Good point. So best to fix components when there aren't (m)any patches outstanding. I propose to create JIRA issues to track these standardisation efforts. Should the issues be filed per component, or would a catchall issue plus subtasks be better for this? I would prefer a separate issue per component. That way it will show up in the generated changes report for the component. This is beneficial to our users. OK, agreed. However, I'd like to avoid having to repeat the same information in every JIRA issue. So I propose creating a dummy parent issue in COMMONSSITE/CommonsAll. Then I would add issues for each component, which link back to - relates to - the common parent issue. One issue to keep track of the overall progress of converting Commons to Maven standard directory layout? Sure, that's a good idea. [Unfortunately one cannot create subtasks in another JIRA project] Does that sound reasonable? Any pitfalls to watch out for? There may be other similar issues that crop up - e.g. where the parent pom now handles what originated in a few component poms - so it might be easier to track these as a catchall JIRA. Niall This would involve renaming the directories, removing the entries from the pom files and updating any other build scripts e.g. Ant that may be present. The projects are: betwixt cli codec collections configuration daemon dbcp dbutils digester discovery el email fileupload io jxpath launcher logging modeler net pool primitives transaction - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Non-standard maven source and test directories
+1 On 2010-04-10 17:16, sebb wrote: 22 commons-proper projects are still using non-standard source and test directories, i.e. they are using: sourceDirectorysrc/java/sourceDirectory testSourceDirectorysrc/test/testSourceDirectory rather than the default: sourceDirectorysrc/main/java/sourceDirectory testSourceDirectorysrc/test/java/testSourceDirectory Do we want to fix those? This would involve renaming the directories, removing the entries from the pom files and updating any other build scripts e.g. Ant that may be present. The projects are: betwixt cli codec collections configuration daemon dbcp dbutils digester discovery el email fileupload io jxpath launcher logging modeler net pool primitives transaction - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
. The referenced URL also mentions things like cutting the release tag for you, but I am pretty sure this is functionality that has existed in mvn for quite some time; in fact the details of how to support the RC-based approach we use @ Commons would be my only question/concern. As a member of both the Commons and Maven PMCs, and the other suspect in this case, I wonder if Ralph would have more useful details for us here; Dennis's input would be similarly welcome. In my view the most important gain of using Nexus is the fact that a release will never be accidental. Any attempt to release a component will halt in Nexus, until the RM goes there to promote it. This usually happens after a vote has been held. This will effectively prevent any rogue SNAPSHOT making its way to the Central repository. We do have some safeguards against this in the current Commons parent POM, but they require the use of profiles. We've been using Nexus in the release process for Maven itself for a while now. As with any new system there are a couple of tasks that you need to learn simply because they are new to you. The documentation (as linked to by Matt) is now very good and includes screen shots of the web UI that you use to promote a release. -Matt Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. Niall http://people.apache.org/~niallp/commons/ http://svn.apache.org/viewvc?view=revisionrevision=922120 Niall [1] http://svn.apache.org/viewvc?view=revisionrevision=922094 [2] http://svn.apache.org/viewvc/commons/proper/commons-site/ [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/ [4] http://people.apache.org/~niallp/commons/downloads/index.html Still shows external links for me. [5] http://people.apache.org/~niallp/commons/team-list.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 16:53, sebb wrote: On 13/03/2010, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. Is it possible to add a section to the commons-site pom that generates a warning message if the -Preporting param is not used? Sorry, what I wrote wasn't clear. The -Preporting parameter is only needed when the site of a *component* is deployed - not when *commons-site* is deployed. I can help with this if you think it's a good idea. Niall http://people.apache.org/~niallp/commons/ http://svn.apache.org/viewvc?view=revisionrevision=922120 Niall [1] http://svn.apache.org/viewvc?view=revisionrevision=922094 [2] http://svn.apache.org/viewvc/commons/proper/commons-site/ [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/ [4] http://people.apache.org/~niallp/commons/downloads/index.html Still shows external links for me. [5] http://people.apache.org/~niallp/commons/team-list.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 16:54, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. I think the small amount of duplication (mailing list information) is probably better. It also didn't work out that well inheriting the site.xml from commons-proper. The old m1 site had expanding menus for components/sandbox/dormant. We don't want to put that in the commons-parent site.xml as it would mean we needed to release commons-parent every time we wanted to do a menu change for a new module - or moved module. Also there is less control over the main site menu - because it needs to be geared towards being inherited by components - this way we are freed up to have a slightly different menu - no constrained by what modules require. I understand. We could create another POM project to handle this. Move the stuff that is only interesting for components to a commons-component-parent and let all our components inherit from that POM. What is left in commons-parent should work well for commons-site and other non-components that might occur. commons-parent (minus reporting and component-specific navigation) | +-- commons-site | +-- commons-component (reporting and component-specific navigation) | +-- commons-bar | +-- commons-foo ... Niall Niall http://people.apache.org/~niallp/commons/ http://svn.apache.org/viewvc?view=revisionrevision=922120 Niall [1] http://svn.apache.org/viewvc?view=revisionrevision=922094 [2] http://svn.apache.org/viewvc/commons/proper/commons-site/ [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/ [4] http://people.apache.org/~niallp/commons/downloads/index.html Still shows external links for me. [5] http://people.apache.org/~niallp/commons/team-list.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 17:33, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 16:54, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. I think the small amount of duplication (mailing list information) is probably better. It also didn't work out that well inheriting the site.xml from commons-proper. The old m1 site had expanding menus for components/sandbox/dormant. We don't want to put that in the commons-parent site.xml as it would mean we needed to release commons-parent every time we wanted to do a menu change for a new module - or moved module. Also there is less control over the main site menu - because it needs to be geared towards being inherited by components - this way we are freed up to have a slightly different menu - no constrained by what modules require. I understand. We could create another POM project to handle this. Move the stuff that is only interesting for components to a commons-component-parent and let all our components inherit from that POM. What is left in commons-parent should work well for commons-site and other non-components that might occur. commons-parent (minus reporting and component-specific navigation) | +-- commons-site | +-- commons-component (reporting and component-specific navigation) | +-- commons-bar | +-- commons-foo ... The disadvantage of this is that we now would have two parent poms that we need to release but besides that I don't see how this is any better than just having commons-site inherit directly from Apache parent. With reporting and component-specific navigation removed from commons-parent, I see that POM having fewer releases going forward. The benefit of this setup is that you get a clear separation between what is needed for Commons components and other Commons projects. In fact since we never release commons-site - then not having to depend on anything else we release seems like a big advantage to me. Since commons-site is constantly evolving and deployed you don't necessarily need for it to have a non-SNAPSHOT parent when you deploy it. So the number of ancestors in the POM hierarchy should not matter. Also as I said before the duplication is very minimal and what is there now in commons-site is very straight forward. So I don't see any advantage in over-complicating this and the rest of our
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 17:58, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 17:33, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 16:54, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. I think the small amount of duplication (mailing list information) is probably better. It also didn't work out that well inheriting the site.xml from commons-proper. The old m1 site had expanding menus for components/sandbox/dormant. We don't want to put that in the commons-parent site.xml as it would mean we needed to release commons-parent every time we wanted to do a menu change for a new module - or moved module. Also there is less control over the main site menu - because it needs to be geared towards being inherited by components - this way we are freed up to have a slightly different menu - no constrained by what modules require. I understand. We could create another POM project to handle this. Move the stuff that is only interesting for components to a commons-component-parent and let all our components inherit from that POM. What is left in commons-parent should work well for commons-site and other non-components that might occur. commons-parent (minus reporting and component-specific navigation) | +-- commons-site | +-- commons-component (reporting and component-specific navigation) | +-- commons-bar | +-- commons-foo ... The disadvantage of this is that we now would have two parent poms that we need to release but besides that I don't see how this is any better than just having commons-site inherit directly from Apache parent. With reporting and component-specific navigation removed from commons-parent, I see that POM having fewer releases going forward. It would still mean an additional pom to release though. Yes it would. The benefit of this setup is that you get a clear separation between what is needed for Commons components and other Commons projects. What other commons projects - besides the main site? commons-build commons-build-plugin commons-skin In fact since we never release commons-site - then not having to depend on anything else we release seems like a big advantage to me. Since commons-site is constantly evolving and deployed you don't necessarily need
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 18:35, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 17:58, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 17:33, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 16:54, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. I think the small amount of duplication (mailing list information) is probably better. It also didn't work out that well inheriting the site.xml from commons-proper. The old m1 site had expanding menus for components/sandbox/dormant. We don't want to put that in the commons-parent site.xml as it would mean we needed to release commons-parent every time we wanted to do a menu change for a new module - or moved module. Also there is less control over the main site menu - because it needs to be geared towards being inherited by components - this way we are freed up to have a slightly different menu - no constrained by what modules require. I understand. We could create another POM project to handle this. Move the stuff that is only interesting for components to a commons-component-parent and let all our components inherit from that POM. What is left in commons-parent should work well for commons-site and other non-components that might occur. commons-parent (minus reporting and component-specific navigation) | +-- commons-site | +-- commons-component (reporting and component-specific navigation) | +-- commons-bar | +-- commons-foo ... The disadvantage of this is that we now would have two parent poms that we need to release but besides that I don't see how this is any better than just having commons-site inherit directly from Apache parent. With reporting and component-specific navigation removed from commons-parent, I see that POM having fewer releases going forward. It would still mean an additional pom to release though. Yes it would. The benefit of this setup is that you get a clear separation between what is needed for Commons components and other Commons projects. What other commons projects - besides the main site? commons-build This is an m1 project, so doesn't apply. commons-build-plugin This is like a component so will always inherit from the same pom
Re: [all] Replace Commons Site m1 build with m2 version
On 2010-03-13 20:50, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 18:35, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 17:58, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 17:33, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-13 16:54, Niall Pemberton wrote: On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-12 11:34, Niall Pemberton wrote: On Fri, Mar 12, 2010 at 3:12 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Mar 12, 2010 at 2:07 AM, sebb seb...@gmail.com wrote: On 12/03/2010, Niall Pemberton niall.pember...@gmail.com wrote: I have created a m2 site for Commons[1][2] as (hopefully) a replacement for the m1 site[3] that we currently have - you can see it here: http://people.apache.org/~niallp/commons/ IMO its a PITA to have to switch to m1 to build the commons site and its time to move to m2. +1, thanks for doing this. * The new releases page[4] points to the download pages on the components' sites (removing the need for the current XSLT ant task to generate the downloads) * I've put PMC members in the pom - so we have a page showing them[5] Feel free to jump in and correct/improve anything. Opinions/feedback on switching from the old m1 site to this m2 site would be welcome. If anyone objects please shout or I'll assume people are OK with this. There seem to be rather too many links marked as external. I don't know if this is a side effect of creating a demo build or whether this would be seen in a live deployment - if so, then this needs to be fixed. OK fixed alot of them - some of these links are now broken on my *demo* site - but would be fine once deployed to the normal location: Thanks! BTW, I updated the parent pom.xml in trunk to get rid of the post links for Commits and Issues. Just noticed that Announce is missing from the list ;-) The Surefire report is not relevant - and is confusing - but I could not work out how to get rid of it. I've changed the pom's parent from commons-parent to apache - this means we don't inherit the reports specified (such as surefure) and also the site.xml. Not inheriting site.xml from commons-parent gives us more control over the main sites navigation. We could move all the reposting stuff in commons parent to a reporting profile. This is a common way to achieve two things: - Make the build faster if you don't want the reports - Prevent some children (like commons-site) from inheriting stuff unless you explicitly activate the profile The only drawback is that you need to supply the -Preporting parameter when you deploy the site, but this can easily be documented in our release instructions. I can help with this if you think it's a good idea. I think the small amount of duplication (mailing list information) is probably better. It also didn't work out that well inheriting the site.xml from commons-proper. The old m1 site had expanding menus for components/sandbox/dormant. We don't want to put that in the commons-parent site.xml as it would mean we needed to release commons-parent every time we wanted to do a menu change for a new module - or moved module. Also there is less control over the main site menu - because it needs to be geared towards being inherited by components - this way we are freed up to have a slightly different menu - no constrained by what modules require. I understand. We could create another POM project to handle this. Move the stuff that is only interesting for components to a commons-component-parent and let all our components inherit from that POM. What is left in commons-parent should work well for commons-site and other non-components that might occur. commons-parent (minus reporting and component-specific navigation) | +-- commons-site | +-- commons-component (reporting and component-specific navigation) | +-- commons-bar | +-- commons-foo ... The disadvantage of this is that we now would have two parent poms that we need to release but besides that I don't see how this is any better than just having commons-site inherit directly from Apache parent. With reporting and component-specific navigation removed from commons-parent, I see that POM having fewer releases going forward. It would still mean an additional pom to release though. Yes it would. The benefit of this setup is that you get a clear separation between what is needed for Commons components and other Commons projects. What other commons projects - besides the main site? commons-build
Re: [all] commons-parent-13 problems
On 2010-03-09 02:42, Niall Pemberton wrote: Unfortunately the upgrade of the maven-site-plugin from 2.0.1 to 2.1 has caused the site generation for Chain, Configuration and DBCP to now fail. I'm looking into this to see whether its something we can fix in the components or whether we need to downgrade the site plugin version. I have reverted the maven-bundle-plugin version to 1.4.3 and the maven-remote-resources-plugin to 1.0 (version 1.1 inherited from apache parent 7) - this restores JDK 1.4 compatibility for mvn package/install. http://svn.apache.org/viewvc?view=revisionrevision=920607 maven-site-plugin 2.1 requires maven 2.1 to run (which AFAIK needs JDK 1.5) - so currently the site won't generate using JDK 1.4 - reverting to 2.0.1 of the site plugin is required to run under JDK 1.4 - do we need that? Maven 2.1.0 is the last version of Maven to run under Java 1.4. But as has already been noted Maven 2.1.0 has other problems. Also I noticed in the apache parent the following comment for the maven-javadoc-plugin: NOTE: 2.6.x is generally unusuable due to MJAVADOC-275 http://jira.codehaus.org/browse/MJAVADOC-275 So probably we should revert to 2.5 for the javadoc plugin Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] commons-parent-13 problems
On 2010-03-10 18:49, Gary Gregory wrote: -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Wednesday, March 10, 2010 09:42 To: Commons Developers List Subject: Re: [all] commons-parent-13 problems On 2010-03-09 02:42, Niall Pemberton wrote: Unfortunately the upgrade of the maven-site-plugin from 2.0.1 to 2.1 has caused the site generation for Chain, Configuration and DBCP to now fail. I'm looking into this to see whether its something we can fix in the components or whether we need to downgrade the site plugin version. I have reverted the maven-bundle-plugin version to 1.4.3 and the maven-remote-resources-plugin to 1.0 (version 1.1 inherited from apache parent 7) - this restores JDK 1.4 compatibility for mvn package/install. http://svn.apache.org/viewvc?view=revisionrevision=920607 maven-site-plugin 2.1 requires maven 2.1 to run (which AFAIK needs JDK 1.5) - so currently the site won't generate using JDK 1.4 - reverting to 2.0.1 of the site plugin is required to run under JDK 1.4 - do we need that? Maven 2.1.0 is the last version of Maven to run under Java 1.4. But as has already been noted Maven 2.1.0 has other problems. Can we run builds on Java 1.5? You can, but you need to make sure that your code doesn't use features that was introduced in a version of Java that is greater than the one you are targeting. One way to this is to use a tool called Animal Sniffer [1] to inspect your code and failing it if it find something suspicious. I haven't yet used the tool myself. [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/ Also I noticed in the apache parent the following comment for the maven-javadoc-plugin: NOTE: 2.6.x is generally unusuable due to MJAVADOC-275 http://jira.codehaus.org/browse/MJAVADOC-275 So probably we should revert to 2.5 for the javadoc plugin Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Next version of IO - should this be 2.0?
On 2010-03-07 12:41, Niall Pemberton wrote: On Sat, Mar 6, 2010 at 12:15 AM, sebb seb...@gmail.com wrote: The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the next release should be 2.0 rather 1.5, as IO now requires Java 1.5, that requires a major version change. The plan was to release it as 2.0 - but IMO its not a requirement. Does that make sense? If so, then the maven id can also be fixed (see IO-125). -1 - see comments on JIRA ticket We need to make this switch sooner rather than later. Currently every release with a groupId och commons-* requires manual work from the people who manage Maven central repository. We're just about the only Apache project left not using a groupId of org.apache.*. We have previously said that we should make the switch to a groupId of org.apache.commons when we do a major release. IMO we need to stick by that decision. Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Next version of IO - should this be 2.0?
On 2010-03-07 16:45, Niall Pemberton wrote: On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-07 12:41, Niall Pemberton wrote: On Sat, Mar 6, 2010 at 12:15 AM, sebb seb...@gmail.com wrote: The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the next release should be 2.0 rather 1.5, as IO now requires Java 1.5, that requires a major version change. The plan was to release it as 2.0 - but IMO its not a requirement. Does that make sense? If so, then the maven id can also be fixed (see IO-125). -1 - see comments on JIRA ticket We need to make this switch sooner rather than later. Currently every release with a groupId och commons-* requires manual work from the people who manage Maven central repository. We're just about the only Apache project left not using a groupId of org.apache.*. I thought it was only when we did the first m2 release for a component and not for subsequent m2 releases for the group. Is that not the case? It used to be that way, but it has changed. The repo maintainers want to remove all manual stuff, including anything from Apache that is not under groupId org.apache.*. We (the ASF) don't want anything pushed to the central repository that is from under groupId other than org.apache.*. It is only a matter of time before our current way (groupid commons-*) will be shut down completely. If people have opinions about this I suggest that you take them to reposit...@a.o for discussion. We have previously said that we should make the switch to a groupId of org.apache.commons when we do a major release. IMO we need to stick by that decision. I don't remember that decision, do you have a link to the thread? Even if we did - this is going to cause problems for users who change their dependency to the latest - but also depend on other artifacts that have an older dependency on commons-io. Is this user pain worth it? I found this thread, which touches the issue: http://markmail.org/message/l3oezqvhehscm67l For such a change to be totally transparent we cannot rely on the relocation feature of Maven, which has been discussed before. We would have to change the package name, which I think was done in lang, from org.apache.commons.io to org.apache.commons.io2. Niall Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Changing maven groupIDs [WAS: [IO] Next version of IO - should this be 2.0?]
On 2010-03-07 22:53, Luc Maisonobe wrote: Phil Steitz a écrit : Niall Pemberton wrote: On Sun, Mar 7, 2010 at 5:28 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-07 16:45, Niall Pemberton wrote: On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg denn...@apache.org wrote: On 2010-03-07 12:41, Niall Pemberton wrote: On Sat, Mar 6, 2010 at 12:15 AM, sebb seb...@gmail.com wrote: The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the next release should be 2.0 rather 1.5, as IO now requires Java 1.5, that requires a major version change. The plan was to release it as 2.0 - but IMO its not a requirement. Does that make sense? If so, then the maven id can also be fixed (see IO-125). -1 - see comments on JIRA ticket We need to make this switch sooner rather than later. Currently every release with a groupId och commons-* requires manual work from the people who manage Maven central repository. We're just about the only Apache project left not using a groupId of org.apache.*. I thought it was only when we did the first m2 release for a component and not for subsequent m2 releases for the group. Is that not the case? It used to be that way, but it has changed. The repo maintainers want to remove all manual stuff, including anything from Apache that is not under groupId org.apache.*. We (the ASF) don't want anything pushed to the central repository that is from under groupId other than org.apache.*. It is only a matter of time before our current way (groupid commons-*) will be shut down completely. If people have opinions about this I suggest that you take them to reposit...@a.o for discussion. OK I think we need to have that discussion. We (Commons) are happy to contribute to and subsequently follow ASF policy on how we publish maven artifacts. Unless I missed it on repository@, though, we have not as ASF agreed on a policy to retire the legacy groupIds. We also seem to be lacking consensus / clarity on how exactly we can accomplish relocation without potentially serious implications for the users of heavily-depended-on components. Does retiring legacy groupIds imply removing them from repository ? I don't think so, but would like to be sure. One of the important features in maven is to be able to reproduce builds long after the release. In my field, we sometimes need to maintain software for a very long time (think more than 20 years). Of course in our case we also use our own repositories, but I think other people may need a few years later to rebuild something despite they did not backup anything. The current policy of Maven central repository is that nothing is ever deleted from it. So old releases will still be there in the future. Therefore here in commons, I think we have agreed that we will move to org.apache.commons groupId when we make incompatible changes in a new release. That *must* coincide with a major release and it *may* coincide with a change in package name. It is possible, as in the present case with [io], that a major release will not introduce incompatible API changes, in which case we will not change the groupId. I see us cutting patch releases using legacy IDs for some time to come. I would prefer to adopt the new groupIds as fast as possible, perhaps at major releases even if they don't break API, but this is not a strong statement from me. Luc Please commons ppl respond if you disagree with the statements above. Assuming we are in agreement, we can continue the discussion on repository@ Phil We have previously said that we should make the switch to a groupId of org.apache.commons when we do a major release. IMO we need to stick by that decision. I don't remember that decision, do you have a link to the thread? Even if we did - this is going to cause problems for users who change their dependency to the latest - but also depend on other artifacts that have an older dependency on commons-io. Is this user pain worth it? I found this thread, which touches the issue: http://markmail.org/message/l3oezqvhehscm67l For such a change to be totally transparent we cannot rely on the relocation feature of Maven, which has been discussed before. We would have to change the package name, which I think was done in lang, from org.apache.commons.io to org.apache.commons.io2. I'm sorry but having the build-tool/repository force a package rename is nuts. Niall Niall Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr
Re: [IO] OK to drop Maven1 build files?
+1 sebb wrote: Is it OK to delete the Maven1 build files from IO? The code now requires Java 1.5. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: M2 SNAPSHOTS at repository.a.o WAS Re: FaltFile.jar @ us...@commons.a.o
Matt Benson wrote: On Jan 5, 2010, at 10:16 AM, Jörg Schaible wrote: Matt Benson wrote: FWIW, there is a [flatfile] M2 snapshot published at repository.apache.org. Which should be definitely not there! Only official reelases can go to the repository. Does the repository == the Nexus instance at repository.apache.org? It's quite obviously intended to host SNAPSHOTs, so do we have a communication problem here or am I unaware of a Commons protocol that says either that publishing SNAPSHOTs is forbidden, or that publishing SNAPSHOTs of sandbox components is? For deployment to Nexus @ repository.apache.org to work the project needs to have the proper configuration for it. The easiest way is to have the project inherit from version 7 [1] of the Apache parent POM. The current commons parent POM inherits from Apache parent 4, which uses the old SNAPSHOT repository at [2]. [1] http://svn.eu.apache.org/viewvc/maven/pom/tags/apache-7/pom.xml?revision=893967view=markup [2] http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-flatfile/1.0-SNAPSHOT/ Thanks, Matt - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Re: getClassLoader vs AccessController
(LogFactoryImpl.java:604) ... 26 more Where all classes except org.mobicents.tests.SecTestSbb have AllPermissions Fix seems easy and if it is desired I can gladly contribute. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Using maven 2 on non-MSFT platform to build JEXL
henrib wrote: To be complete, the site is generated ok when the commons-parent pom is just above jexl's trunk with parent parent version 12. But then the rc publishing fails later when the site is regenerated from what was published (lacking the parent pom above.) Seems to me this is related to the getRelativePath bug on Unix (which looks like a *major* loss of functionality); it is fixed but there is no release that includes it. A release is in the works. henrib wrote: No, that does not change the output. But with a parent pom version 11, it looks ok. Niall Pemberton wrote: ... Does it make any difference if you remove the leading slash from the href=/...html attribute on the item elements in site.xml? ... -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3 release problems
Phil Steitz wrote: I am running into some problems preparing for dbcp-1.3. I would appreciate comments / patches on any of the issues below. 1. Findbugs is showing some real (inconsistent synch) and not so real (e.g. serialization issues on classes that IMO should not be serializable, but we can't fix until 2.0). The full report is here: http://commons.apache.org/dbcp/findbugs.html I would appreciate suggestions/patches/commits for what to fix and how. 2. We can't compile commons-pool-1.3.jar against JDK 1.6 (JDBC 4) and expect it to work for JDK 1.4/1.5 (JDBC 3) clients (at least not as the code stands today). So we need to create two jar artifacts. The question is which one gets the 1.3 name, what is the other named and how do we package the distros? I see two possible naming schemes for this, both of them using classifiers in the same way that Maven does. 1. commons-pool-1.3-jdk14.jar and commons-pool-1.3-jdk16.jar 2. commons-pool-1.3-jdbc3.jar and commons-pool-1.3-jdbc4.jar Both of these schemes have a classifier on *both* artifacts. If you want to eliminate one of the classifiers I'd propose to skip the classifier on the JDBC 3 artifact, since that is what is currently out there in the 1.2.x versions of commons-dbcp. Then it would be 3. commons-pool-1.3.jar and commons-pool-1.3-jdk16.jar 4. commons-pool-1.3.jar and commons-pool-1.3-jdbc4.jar 3. I assume it is OK at this point to drop the nojdbc3 Ant target and compiler flags for JDBC 2. TIA Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] JIRA issues building up
I'm available to be RM if we want to make a release. Henri Yandell wrote: Various JIRA issues building up on Logging. Do we have any plans for more Logging releases? Ignoring the obvious that something could mean doing a 1.1.2 release. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Problems running mvn site - anyone else seeing this?
Niall Pemberton wrote: I'm hitting the following problem trying to build the site for a couple of components: http://maven.markmail.org/message/nwrpf3ym4wanajyq Tony's solution works for me (adding the commons lang dependency to the site plugin in the parent pom) - just wondered if anyone else is seeing this (could be related to the new parent pom version)? Anyway I have not been able to reproduce this on my machine: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.5.0_21 Java home: C:\Program\Java\jdk1.5.0_21\jre Default locale: sv_SE, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows I think that you have some bad metadata and/or pom.xml file in your local repository. The following line in the output suggests that the problem lies with the Project Information Reports Plugin. [INFO] Generating Project Team report. You could try to delete the directory .../org/apache/maven/plugins/maven-project-info-reports-plugin/ from your local repository. This will trigger a new download of that plugin the next time it is used. if noone obejcts I'm going to apply the following to commons parent: Niall Index: commons-parent/pom.xml === --- commons-parent/pom.xml(revision 827828) +++ commons-parent/pom.xml(working copy) @@ -187,6 +187,18 @@ /plugin plugin groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-site-plugin/artifactId + version2.0.1/version + dependencies + dependency + groupIdcommons-lang/groupId + artifactIdcommons-lang/artifactId + version2.4/version + /dependency + /dependencies +/plugin +plugin + groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.1.1/version /plugin - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Problems releasing commons-parent 12
Siegfried Goeschl wrote: Hi Niall, basically I had all problems you mentioned +) SVN 1.5 works and all newer version seems to be broken with M2 (SVN 1.5.4 and 1.6 did not work) For full details on this issue see http://jira.codehaus.org/browse/SCM-406 +) Maven 2.2.1 worked but not 2.0.9 2.0.10 +) some SVN problems stem from the fact you are committing on Europe SVN server This is most likely what happened to Niall. Siegfried Goeschl Dennis Lundberg wrote: Niall Pemberton wrote: On Tue, Oct 20, 2009 at 10:36 PM, James Carman ja...@carmanconsulting.com wrote: I did not rollback the commit. OK that worked for the release:prepare command - now I'm stuck on release:perform - it gets to the deploy:deploy stage and I get the following message: [INFO] The authenticity of host 'people.apache.org' can't be established. [INFO] DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9 Then it just hangs - any ideas? I think there was a change made on the repository side of this, that requires a fix for Maven (the application). It has been fixed, but I can't remember in which version. You can try using Maven 2.2.1 to see if it solves the problem. Niall On Tue, Oct 20, 2009 at 5:34 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Oct 20, 2009 at 10:25 PM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 20, 2009 at 5:21 PM, Niall Pemberton niall.pember...@gmail.com wrote: I've tried it four times and it has failed with the same problem each time. One of the changes in this release was to upgrade the maven-release-plugin from version 2.0-beta-7 to 2.0-beta-9. Perhaps I should try reverting that changes and see if that fixes it. Can't think of anything else to try, unless someone else wants to have a go and see if it works for them. I've had trouble with the release plugin lately, too. What I did to fix my problem was try the release, get the failure because of SVN issues, then do svn update, then retry the release. Did you rollback the commit - or is it smart enough to carry on from where it failed? Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Problems releasing commons-parent 12
Niall Pemberton wrote: On Tue, Oct 20, 2009 at 10:25 PM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 20, 2009 at 5:21 PM, Niall Pemberton niall.pember...@gmail.com wrote: I've tried it four times and it has failed with the same problem each time. One of the changes in this release was to upgrade the maven-release-plugin from version 2.0-beta-7 to 2.0-beta-9. Perhaps I should try reverting that changes and see if that fixes it. Can't think of anything else to try, unless someone else wants to have a go and see if it works for them. I've had trouble with the release plugin lately, too. What I did to fix my problem was try the release, get the failure because of SVN issues, then do svn update, then retry the release. Did you rollback the commit - or is it smart enough to carry on from where it failed? I forgot to mention that you should not roll back the changes. The plugin keeps a log of how far it got and continues from where it left off in the previous run. Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Problems releasing commons-parent 12
Niall Pemberton wrote: On Tue, Oct 20, 2009 at 10:36 PM, James Carman ja...@carmanconsulting.com wrote: I did not rollback the commit. OK that worked for the release:prepare command - now I'm stuck on release:perform - it gets to the deploy:deploy stage and I get the following message: [INFO] The authenticity of host 'people.apache.org' can't be established. [INFO] DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9 Then it just hangs - any ideas? I think there was a change made on the repository side of this, that requires a fix for Maven (the application). It has been fixed, but I can't remember in which version. You can try using Maven 2.2.1 to see if it solves the problem. Niall On Tue, Oct 20, 2009 at 5:34 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Oct 20, 2009 at 10:25 PM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 20, 2009 at 5:21 PM, Niall Pemberton niall.pember...@gmail.com wrote: I've tried it four times and it has failed with the same problem each time. One of the changes in this release was to upgrade the maven-release-plugin from version 2.0-beta-7 to 2.0-beta-9. Perhaps I should try reverting that changes and see if that fixes it. Can't think of anything else to try, unless someone else wants to have a go and see if it works for them. I've had trouble with the release plugin lately, too. What I did to fix my problem was try the release, get the failure because of SVN issues, then do svn update, then retry the release. Did you rollback the commit - or is it smart enough to carry on from where it failed? Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Problems releasing commons-parent 12
Run the exact same command once more. This has been known to happen from time to time. Niall Pemberton wrote: I'm having problems doing the release of commons-parent 12 Running the following command: mvn -Prelease release:prepare -Dusername=niallp -Dpassword=*** ...works partially. It updates the pom.xml (version scm tags) and commits the changes but then fails when it tries to tag with the following output: - [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: No such revision 827754 - The revision number indicated was the one from the commit of the previous pom changes. Any ideas anyone? Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-parent 12
+1 Niall Pemberton wrote: I updated the pom to add the clean and deploy plugins to the pluginManagement section and remove the idea plugin: http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=826258r2=678413diff_format=h Niall On Sat, Oct 17, 2009 at 3:11 AM, Niall Pemberton niall.pember...@gmail.com wrote: Hi, I'd like to release version 12 of the commons-parent pom - the changes since the last release are: - the javadoc jar now has standard entries (e.g. version, title) added to its MANIFEST.MF file - the sources jar now has standard entries (e.g. version, title) added to its MANIFEST.MF file - project.build.sourceEncoding added and set to iso-8859-1 - project.reporting.outputEncoding added and set to iso-8859-1 - inceptionYear removed - Update plugin versions to the latest release - idea plugin locked down in pluginManagement - plugin list now sorted - sanselan compress added to modules A full diff of the pom.xml can be found at this address: http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=826156r2=678413diff_format=h The version number in the pom will be updated automatically during the release process. [ ] +1 [ ] =0 [ ] -1 Vote is open for 72 hours Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] M2 release plugin fails with SVN error ...
Siegfried Goeschl wrote: Hi Dennis, +) I downgraded to SVN 1.5.0 but still got an SVN error (the SVN sync issue) +) re-running the maven release plugin did the trick (before I hit the next problem) Great! Perhaps I can help with the next problem as well? Cheers, Siegfried Goeschl Dennis Lundberg wrote: Siegfried Goeschl wrote: Hi folks, I have simply no commons luck at the moment :-( ... see below +) using Maven 2.0.10 on Mac OS X +) I upgraded from SVN 1.5.4 to 1.6.5 to no avail Try to downgrade to subversion 1.5.0 to work around the issue mentioned by Olivier. +) I switched to svn.us.apache.org to no avail I've been told not to do that. Just use svn.apache.org and let the geo-ip thingy do its job. Any other things I can do? Try to run the Maven release command once again. The release plugin will continue from where it left off. This is actually the first thing I would try. Thanks in advance Siegfried Goeschl [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1022494886.commit --targets /tmp/maven-scm-4458577529896422471-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Tagging release with the label EXEC_1_0_1_RC3... [INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-81043225.commit . https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1_RC3 [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Transforming 'Commons Exec'... [INFO] Not removing release POMs [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1635210307.commit --targets /tmp/maven-scm-6673381375296967061-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: The specified baseline is not the latest baseline, so it may not be checked out. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] M2 release plugin fails with SVN error ...
Siegfried Goeschl wrote: Hi folks, I have simply no commons luck at the moment :-( ... see below +) using Maven 2.0.10 on Mac OS X +) I upgraded from SVN 1.5.4 to 1.6.5 to no avail Try to downgrade to subversion 1.5.0 to work around the issue mentioned by Olivier. +) I switched to svn.us.apache.org to no avail I've been told not to do that. Just use svn.apache.org and let the geo-ip thingy do its job. Any other things I can do? Try to run the Maven release command once again. The release plugin will continue from where it left off. This is actually the first thing I would try. Thanks in advance Siegfried Goeschl [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1022494886.commit --targets /tmp/maven-scm-4458577529896422471-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Tagging release with the label EXEC_1_0_1_RC3... [INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-81043225.commit . https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1_RC3 [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Transforming 'Commons Exec'... [INFO] Not removing release POMs [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1635210307.commit --targets /tmp/maven-scm-6673381375296967061-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: The specified baseline is not the latest baseline, so it may not be checked out. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] Created: (SANSELAN-26) Move Image magic numbers to constants
I have switched the notification scheme in JIRA from Sanselan notifications to Apache Commons Notification Scheme so these emails will go to the correct mailing list. I have not deleted the Sanselan notifications from JIRA, but I guess that should be done as well. The Issue Type Scheme should be changed from Default Issue Type Scheme to Apache Default Issue Type Scheme, but that would require two issues of type Question to change issue type. Ashish Paliwal (JIRA) wrote: Move Image magic numbers to constants - Key: SANSELAN-26 URL: https://issues.apache.org/jira/browse/SANSELAN-26 Project: Commons Sanselan Issue Type: Improvement Affects Versions: 0.94-incubator Environment: All Reporter: Ashish Paliwal Priority: Minor All the Image magic numbers used in Sanselan.guessFormat() API can be moved to constants. As of now they are hardcoded within the API -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] M2 release fails with SVN error message
Do you have your source checked out from the EU svn mirror? If so try to check out and do the release against svn.apache.org instead. Apparently the dynamic DNS currently used for the ASF svn servers messes up releases using Maven's Release Plugin. If not, try to run the release command one more time. The Release Plugin will continue from the point where it stopped during the previous run. Siegfried Goeschl wrote: Hi folks, anyone out there having an idea what to do with? It is a reproducible SVN problem but this is the only thing I know for the moment :-( Thanks in advance Siegfried Goeschl PS: Was using mvn -Prc release:prepare on commons-exec === START === [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 4 minutes 18 seconds [INFO] Finished at: Tue Jul 14 18:25:40 CEST 2009 [INFO] Final Memory: 68M/122M [INFO] [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1680689570.commit --targets /tmp/maven-scm-3481365182813304861-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Tagging release with the label EXEC_1_0_1_RC2... [INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-2080104901.commit . https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1_RC2 [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] Transforming 'Commons Exec'... [INFO] Not removing release POMs [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-298400765.commit --targets /tmp/maven-scm-3447475345724908690-targets [INFO] Working directory: /Users/siegfriedgoeschl/work/asf/commons/proper/exec/trunk [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: The specified baseline is not the latest baseline, so it may not be checked out. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 5 minutes 39 seconds [INFO] Finished at: Tue Jul 14 18:26:13 CEST 2009 [INFO] Final Memory: 5M/10M [INFO] === END === - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Incorrect release info in the doap files
Emmanuel Bourg wrote: I noticed that most of the Commons components listed on projects.apache.org have an empty release history. This is due to an incorrect syntax in the doap files. The releases are defined with: revision namecommons-codec/name created2004-07-10/created version1.3/version /revision but it should be: Version namecommons-codec/name created2004-07-10/created revision1.3/revision /Version that's, the revision tags become Version (case sensitive), and version becomes revision. The following projects use the right syntax: CLI I've been trying to find a definite resource for the syntax to use, I don't understand the RDF schema at http://usefulinc.com/ns/doap. That being said, the validator at W3C doesn't like the new syntax any better than the old one: http://www.w3.org/RDF/Validator/ARPServlet?URI=http%3A%2F%2Fsvn.eu.apache.org%2Frepos%2Fasf%2Fcommons%2Fproper%2Fcli%2Ftrunk%2Fdoap_cli.rdfPARSE=Parse+URI%3A+TRIPLES_AND_GRAPH=PRINT_TRIPLESFORMAT=PNG_EMBED Are you only allowed to have one Version under the release element? Configuration Modeler Pool Validator Could everyone look at their projects and fix the files please? Thank you, Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging version 0.0.0-EMPTY
Ceki Gulcu wrote: Dennis Lundberg wrote: Ceki Gulcu wrote: Hello all, I have created an empty Maven project with groupId commons-logging, artifactId commons-logging and version 0.0.0-EMPTY. There is very little content (around 500 bytes) in the whole project. This is to be expected as the original aim was to produce an empty jar file. For the actual source code, see https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/ Anyway, as discussed previously, how do we go about publishing this empty jar on ibiblio (Maven's central repository). Is a vote warranted, or would that be premature? Hi Ceki I'm not convinced that the approach that you are proposing will work seamlessly for most of our users, i.e. those that really want to have commons-logging in their classpath. Seamlessly? The whole idea is for the version 0.0 to be declared explicitly in the end-user's project POM. We do not want version 0.0 to override a later version *seamlessly*. Those who wish to have a rel commons-logging on their class path do not have to do anything. I think you misunderstood me. I'm concerned for the people that want the real version of commons-logging on their class path. We do not want to mess with their builds. They should be able to continue using commons-logging like they always have, even after a potential 0.0 anti-artifact is released. We are making use of Maven's notion of nearest definition # Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the nearest definition which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.4 it was not defined which one would win, but since Maven 2.0.5 it's the order in the declaration that counts: the first declaration wins. * nearest definition means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A - B - C - D 2.0 and A - E - D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0 Source: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html The key phrase being: You can always guarantee a version by declaring it explicitly in your project's POM. Forgive me for asking, but were you aware of the above. And if you were, would you care to explain a scenario in mind which is troubling you? Yes I'm aware of that. My concern is for those people who don't know about that. What will happen if they declare commons-logging:commons-logging without a version in their POM? Or declare the special token LATEST as a version for commons-logging? Will they get 1.1.1 or 0.0 or what? Therefor I'd like to bring this over to d...@maven.a.o to get some input from the people who knows the inner workings of Maven. I will bring any feedback back here later on. Please do. Done http://www.nabble.com/Need-your-input-on-a-repository-%22hack%22-to23605666.html -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging version 0.0.0-EMPTY
Ceki Gulcu wrote: Hello all, I have created an empty Maven project with groupId commons-logging, artifactId commons-logging and version 0.0.0-EMPTY. There is very little content (around 500 bytes) in the whole project. This is to be expected as the original aim was to produce an empty jar file. For the actual source code, see https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/ Anyway, as discussed previously, how do we go about publishing this empty jar on ibiblio (Maven's central repository). Is a vote warranted, or would that be premature? Hi Ceki I'm not convinced that the approach that you are proposing will work seamlessly for most of our users, i.e. those that really want to have commons-logging in their classpath. Therefor I'd like to bring this over to d...@maven.a.o to get some input from the people who knows the inner workings of Maven. I will bring any feedback back here later on. by the way, ibiblio is not Maven's central repository - although it used to back in the days. Maven's central repository is currently located at repo1.maven.org. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging version 0.0.0-EMPTY
Craig L Russell wrote: Hi, On May 18, 2009, at 10:00 AM, sebb wrote: On 18/05/2009, Ceki Gulcu c...@qos.ch wrote: Hello, Thank you for this suggestion. Unfortunately, adding references to parent pom, addDefaultImplementationEntries and addDefaultSpecificationEntries creates a manifest file which includes OSGi directives, which is really not desirable. These can be suppressed. Just for my information, why is it not desirable to package this as an OSGi compliant jar? Also, why is the maven group id commons-logging and not org.apache.commons? Is this just a historical curiosity or was there a purpose? The groupId for Commons Logging has always been commons-logging. There have been numerous discussions trying to change it to the more correct org.apache.commons, but they have always failed. The main reason being that there is no smooth way to migrate from one groupId to another. That is especially important for an artifact as widely used as Commons Logging. Thanks, Craig However, surely referencing the apache pom as a parent pom does not do this? I just tried, and using the default tags works OK for me. I changed the contents of the name element to Commons Logging. sebb wrote: Thanks, although IMO it would have been better to use manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest rather than hard-coding the values. Also, the pom name is wrong, it should be nameCommons Logging/name as per the existing pom.xml in logging/trunk. The pom.xml for empty_logging should also have as parent either the commons parent, or at least the apache parent. That would allow the use of the default manifest entries as above. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [resources] Working with JIRA
I've added you as a project administrator for RESOURCES in JIRA. Dave Meikle wrote: Hi, I was looking to go through some of the issues reported on Commons Resources in JIRA, but I don't have rights to manage the project and therefore the issues. Is this something I would be able to get access to? Cheers, Dave -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Sure, but I'd start with describing and discussing new features before starting to code. Torsten Curdt wrote: What if one would create an JCL 2.0 experimental branch? Would that be OK for everyone? cheers -- Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Ralph Goers wrote: On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote: On Tue, Apr 21, 2009 at 5:01 PM, sebb seb...@gmail.com wrote: Well, the SLF4J website specifically says it is not necessary to recompile: http://www.slf4j.org/manual.html#swapping i.e. SLF4J chooses the logging implementation based in which logging implementation it finds on the classpath; there must be only one such. I'm not saying SLF4J is better or worse than CL, but they both allow the implementation to be configured without recompilation. Thanks, that means that I'll drawback from this discussion. I'd only like to note that I'd clearly prefer, if we all could stick to a single logging system, regardless what. Thanks. But I'd really like to get back to what this topic was meant to be about. Commons currently uses Commons Logging. It is a very minimal API (too minimal if you ask me) and apparently still has some issues with how it binds to its implementation. I'm not that experienced in writing portlets or how the portlet container works. Can you please try to explain in more detail what the problem is. Commons Logging works great in a servlet container like Tomcat. Every webapp can have their own version of commons-logging and their own configuration. How does the portlet container use case differ from this? Do you configure Commons Logging explicitly, by using a commons-logging.properties file or are you relying on auto discovery? In my experience you you should *always* configure the logging implementation explicitly if you want deterministic results. The basic question is, what is next for Commons Logging? Is there any point in enhancing it to emulate SLF4J? Should it just stay more or less as it is while it slowly loses its customer base? I don't think there is much point in discussing what logging system Commons projects should use in the future without answering this. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Sorry, I wasn't being clear. I was not talking about configuring the *level* of logging, but rather the logging implementation being used. Paul Libbrecht wrote: allow me to chim in, does it make sense to expect *predictable results* ? What you should always configure is the default logging, and that's done, traditionally, by making the normal threshold either info or error in the programme, maybe that could be enhanced (preferred-level ?). Full predictability does not make sense though. I almost never configure my logging, only when I start to explore, dig, and debug. paul On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote: Do you configure Commons Logging explicitly, by using a commons-logging.properties file or are you relying on auto discovery? In my experience you you should *always* configure the logging implementation explicitly if you want deterministic results. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Yes, it most certainly can. It seems to be a common misconception what the logging implementation cannot be predictably configured. Just put a commons-logging.properties file in your class path with the following line in it: org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger That will choose log4j for you. Paul Libbrecht wrote: Ah, that's more clear. But again, it cannot be predictable and pluggeable, or? paul Le 21-avr.-09 à 22:27, Dennis Lundberg a écrit : Sorry, I wasn't being clear. I was not talking about configuring the *level* of logging, but rather the logging implementation being used. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
