Re: New M2 snapshots use org.apache.commons?
On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote: For development of new releases, should the commons-* folders be forgone and use org.apache.commons now? Check the list archives for some past discussion... it has to be handled carefully with old releases relocated in the central repository, or downstream users will be adversely affected. Nabble turns up a few relevant posts: http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Dennis Lundberg [EMAIL PROTECTED] wrote: This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. Since you have a policy against releasing sandbox components, why not just deploy snapshots of the sandbox parent pom, and advance to the next snapshot version (without a release) when there is a change? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
On 5/20/07, Phil Steitz [EMAIL PROTECTED] wrote: Should have been more clear in my question. If you partially configure a plugin in the parent, can you then just add stuff, such as the version, in a child without repeating the things specified in the parent config? If the answer to that is no then there is no value in partially configuring plugins in the parent. At a minimum, the parent would only mention the plugin version numbers in pluginManagement. That's what will pin the plugin version number and increase the likelyhood of having reproducible builds. pluginManagement only kicks in when a child project uses the plugin, either with a declaration in pluginsplugin or using the defaults without configuration. (For example, the 'clean' plugin usually isn't configured.) If the project wants a different plugin version, then it can specify that in pluginsplugin along with any project-specific configuration. The important part is that the version number is configured somewhere in the pom hierarchy, rather than depending on the latest release which could change. You can also put configuration in pluginsplugin in the parent pom that will be inherited, but only things that are common to all projects should go there. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: We haven't yet released a version 1.3.2. Of course, if we had, then I'd never dare to call this 1.3.2 again. In a perfect world, a non-snapshot version gets built exactly once and either promoted or discarded. Since the world isn't perfect, sometimes we delete the tag and try again. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] parent pom repositories
On 5/16/07, Torsten Curdt [EMAIL PROTECTED] wrote:
As we talked about on how to do release on at commons I am wondering
if these profiles really make sense:
...
idrc/id
distributionManagement
repository
idapache.snapshots/id
nameApache Development Snapshot Repository/name
url${commons.deployment.protocol}://people.apache.org/
www/people.apache.org/repo/m2-snapshot-repository/url
Briefly, in no particular order...
Stage each release in a separate repository, such as
people.a.o/builds/commons/[project name]/${version}/m2-staging-repository
There is a utility for promoting staged releases to the rsynced repo.
(Actually for merging one repository into another, including the
metadata.)
The latest release of the gpg plugin will prompt for a passphrase if
one is not supplied.
Signing the release distributions... The gpg plugin will sign them if
you deploy them to the repository (attached assemblies). There's a
bit of renaming and copying to do that I haven't figured out how to
automate yet. Then you have to decide if you want the distributions
in the Maven repo.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] parent pom repositories
On 5/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/5/17, Wendy Smoak [EMAIL PROTECTED]: There is a utility for promoting staged releases to the rsynced repo. (Actually for merging one repository into another, including the metadata.) What utility? Maybe I missed something that could be useful. http://www.nabble.com/Note-on-copying-staged-repositories-t3627047s177.html I haven't tried it. I'd practice somewhere other than the rsycned repo to make sure it does what you want and check on maven-dev or #maven irc for any known issues before using. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] parent pom repositories
On 5/17/07, Torsten Curdt [EMAIL PROTECTED] wrote:
So it should be
idrc/id
repositories
repository
idrc/id
urlhttp://people.apache.org/builds/commons/$
{project.name}/${project.version}/m2-staging-repository/url
snapshotsenabledfalse/enabled/snapshots
releasesenabledtrue/enabled/releases
/repository
/repositories
${project.name} is likely to be something like Commons Math not the
commons-math that would be more appropriate in a directory name. If
you can't find something suitable in the pom, you may want to
introduce an arbitrary property in each project's pom and use that in
the url. (I think $artifactId would only work for single-module
projects.)
mvn stage:copy \
-Dsource=http://people.apache.org/builds/commons/$
{project.name}/${project.version}/m2-staging-repositoryg \
-Dtarget=scp://people.apache.org/www/people.apache.org/repo/
m2-ibiblio-rsync-repository \
-Dversion=${project.version}
Any chance to have the project name and version injected
automatically there?
Not afaik. You should know what you're promoting. :)
The latest release of the gpg plugin will prompt for a passphrase if
one is not supplied.
Great ...last time I tried it did not work for me (although it was
supposed to according to the docs)
Specify a version in the pom to make sure you're really using the
latest. Open a bug if it's not working... I gave up and just put the
passphrase in settings.xml. (You may not like being prompted-- I have
a feeling it's going to prompt more than once!)
Signing the release distributions... The gpg plugin will sign them if
you deploy them to the repository (attached assemblies). There's a
bit of renaming and copying to do that I haven't figured out how to
automate yet.
WDYM? ...seems like the signing worked just fine for the jci RC1.
Then you have to decide if you want the distributions
in the Maven repo.
WDYM? The usual artifacts? Sure!
No, the .zip and .tar.gz release distributions, the assemblies.
Not so sure what to do with the bin/src dists from the assembly though.
Right. :)
Take a look at the last section of my Archiva release page, under
'Release Distribution':
http://wiki.wsmoak.net/cgi-bin/wiki.pl?Archiva09Alpha2Release
The assemblies get deployed under their artifactIds, not the final
name that we want for the public distribution. Plus Maven's checksum
files aren't formatted correctly for md5sum -c.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release commons jci RC1 as 1.0
On 4/15/07, Torsten Curdt [EMAIL PROTECTED] wrote: Niall wrote: A number of components have done this recently and it means less chance of something going wrong after the vote passes as it simply becomes a case of copying the jars/distros that have been voted on rather than building a whole new set when cutting a release. True and makes total sense. Unfortunately the maven release process does not really adhere to that - unless I am missing something. mvn release:prepare -Prc mvn release:perform -Prc Creates the tag and deploy to the snapshot repo. mvn release:prepare -Prelease mvn release:perform -Prelease Would be next but that would not match our (or the quite common) process of turning a RC into a release. Instead of deploying straight to m2-ibiblio-rsync-repository, stage the release somewhere else for the vote. The two ways that work right now are: 1. Use an alternate deployment repository configured in the pom or on the command line. See http://maven.apache.org/developers/release/releasing.html which talks about how to release parts of the Maven project. 2. Override distributionManagementrepository in your project pom. Many projects use space under http://people.apache.org/builds/ to do this, for example: http://people.apache.org/builds/tiles/2.0.3/ . This has the source and binary distributions at the top, and then a staging repo for the Maven artifacts, which can be merged (or just copied) into the rsynced repo after the vote. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.1.1 release?
On 3/9/07, Simon Kitching [EMAIL PROTECTED] wrote: Option 1 is for the maven buildfile to ensure that all compilation and unit tests are done with an external jdk of version 1.2. That's tricky though. I researched this question earlier this week. There are some links on the compiler plugin wiki page: http://docs.codehaus.org/display/MAVENUSER/Compiler+Plugin -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498529 - /jakarta/commons/proper/dbcp/trunk/release-notes.jsl
On 1/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: psteitz Date: Sun Jan 21 21:30:00 2007 New Revision: 498529 URL: http://svn.apache.org/viewvc?view=revrev=498529 Log: Added known issues section. Modified: jakarta/commons/proper/dbcp/trunk/release-notes.jsl ... +Known Issues (signicant open issues at time of release): s/signicant/significant/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Digester] Change of Maven Group Id
On 11/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: I presume that this is being done as part of some Commons-wide policy change? If so, it's incumbent on us to clearly document the impact of this change on downstream users, because it is going to be pretty disruptive until all downstream users have rev'd their POMs to reflect the new versions. It shouldn't be disruptive at all if the artifacts are properly relocated in the Maven repo. ISTR Dennis Lundberg was working on it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Digester] Change of Maven Group Id
On 11/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: Does that mean that you will be able to use commons-digester:commons-digester:1.8 *or* org.apache.commons:commons-digester:1.8 after Digester 1.8 is released? For a specific example, consider an app that uses, say, Shale and MyFaces 1.1.4. Even if we update the Shale dependency to the new groupId, an application will still inherit a transitive dependency on the old version until a new MyFaces release with an updated dependency. You relocate the existing releases that are already in the repository. Then Maven is able to figure out that commons-digester:commons-digester:1.7 is really org.apache.commons:commons-digester:1.7, and is the same artifact as org.apache.commons:commons-digester:1.8. That will stop it from including both. The whole of Commons doesn't have to switch at once. The trick is to relocate _all_ of the old artifacts for any given component, then start releasing that component under the new groupId. Maven will then print warnings that this artifact has been relocated... which will prompt people to switch over. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r474943 - in /jakarta/commons/proper/digester/trunk: pom.xml src/assembly/ src/assembly/bin.xml src/assembly/src.xml
On 11/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: And now I remember why I wanted to retain 'bin' as the descriptor ID. The nightly script looks for a descriptor with ID 'bin' for assembling the binary distro (if we move to m2 for the nightlies). Looks like we need pack options in the assembly plugin to tweak the packaging. Okay, put the id back, and try setting 'appendAssemblyId' to false inside configuration. http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html (Those are the latest docs from svn. If it doesn't work, it's possible that the parameter was added after the last release of the assembly plugin.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml
On 11/18/06, Simon Kitching [EMAIL PROTECTED] wrote: It would be really nice if Maven would report an error if the scope value is invalid rather than silently ignoring the dependency completely (as 2.0.4 evidently does). I'll try to check with mvn trunk and request an enhancement if this behaviour is still the same (unless someone has the latest maven trunk checked out and can check more easily?). Neither the Maven 2.0.5 nor 2.1 snapshot complains about an invalid scope, I just get the same compilation failure. I'll go see if there's an issue open already. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r474035 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
The release plugin removed the license header in this commit, and it's deployed to the Maven repo without one: http://repo1.maven.org/maven2/org/apache/commons/commons-parent/1/ I wonder if moving the license inside the project element would help, since the rest of the comments weren't removed. -- Wendy On 11/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dennisl Date: Sun Nov 12 12:36:46 2006 New Revision: 474035 URL: http://svn.apache.org/viewvc?view=revrev=474035 Log: [maven-release-plugin] prepare release commons-parent-1 Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=474035r1=474034r2=474035 == --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Sun Nov 12 12:36:46 2006 @@ -1,23 +1,4 @@ -!-- - - Licensed to the Apache Software Foundation (ASF) under one or more - contributor license agreements. See the NOTICE file distributed with - this work for additional information regarding copyright ownership. - The ASF licenses this file to You under the Apache License, Version 2.0 - (the License); you may not use this file except in compliance with - the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - --- ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r474035 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
On 11/18/06, Wendy Smoak [EMAIL PROTECTED] wrote: The release plugin removed the license header in this commit, and it's deployed to the Maven repo without one: http://repo1.maven.org/maven2/org/apache/commons/commons-parent/1/ I wonder if moving the license inside the project element would help, since the rest of the comments weren't removed. On [EMAIL PROTECTED], Brett said: That is a bug in the release plugin if you have new lines in the root element. I think it's fixed in trunk. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml
On 11/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: skitching Date: Fri Nov 17 19:41:32 2006 New Revision: 476429 URL: http://svn.apache.org/viewvc?view=revrev=476429 Log: Add comments about unusual dependency-handling approach. ... if we declare them optional then +- when JCL is *compiled* we get none of them in the classpath. Are you saying that if you mark the dependencies optional, you get compilation errors? That doesn't sound right. If you mark it optional, it will be excluded from transitive dependency resolution when a project depends on commons-logging. But it should be on the compile-time classpath. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven2 POM Question
On 11/17/06, Simon Kitching [EMAIL PROTECTED] wrote: Sorry :-). That's exactly the purpose. I'll add a comment now. I saw the commit before the thread, so commented there. Marking a dependency 'optional' excludes it from transitive dependency resolution, nothing more. It should still be on the compile time classpath. (For example, that's how we compile Shale Test against HtmlUnit and Cargo, but don't impose those dependencies on every Shale Test user.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r476429 - /jakarta/commons/proper/logging/trunk/pom.xml
On 11/17/06, Simon Kitching [EMAIL PROTECTED] wrote: Are you saying that if you mark the dependencies optional, you get compilation errors? That doesn't sound right. Well, that's exactly what happens. Found it. Optional is not a scope, it's a separate element. Instead of scopeoptional/scope, use optionaltrue/optional. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Building openpgp
On 9/14/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: I have the whole commons-sandbox checked out. I try to build openpgp and I see : ... [INFO] Failed to resolve artifact. GroupId: org.apache.commons ArtifactId: commons Version: 1-SNAPSHOT Reason: Unable to download the artifact from any repository ... Any idea how to fix that ? It's here: http://svn.apache.org/repos/asf/jakarta/commons/trunks-proper/pom.xml Check it out (or just download it) and 'mvn install' so it is in your local repository. HTH, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/4/06, Phil Steitz [EMAIL PROTECTED] wrote: OK - I guess that's why I couldn't find it ;-) I assume the latest (released) site plugin (2.0-beta-5) is OK to use, right? 2.0-beta-5 has some annoying issues... Shale and Struts are still using 2.0-beta-4 until there is another release. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons and Maven 2 (Was: VOTE: Migrate commons-fileupload to Maven 2)
On 9/4/06, Phil Steitz [EMAIL PROTECTED] wrote: Thanks, Wendy. How do you force maven to use an earlier version? Adding a plugin element for the site plugin with a version spec did not seem to work for me - at least according to what I saw from -X. Where do you put the plugin element to specify the older version? We have it in pluginManagement in the parent pom: http://svn.apache.org/repos/asf/struts/struts1/trunk/pom.xml If it's in the pom for the actual module, then pluginsplugin...version should work. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][maven 2 configuration]
On 8/29/06, Phil Steitz [EMAIL PROTECTED] wrote: I have one more question / concern with the current setup. Should we override the distributionManagement section to null out the releases section ... We've talked about this some on [EMAIL PROTECTED] IMO, we need to use a staging repository for releases and have an easy way to promote a build from staging to ibiblio-rsync. (Right now it's hard to move or copy artifacts between repos, at least if you want the repository metadata to be somewhat correct.) Struts and Shale currently have distributionManagement/repository pointed at apache.snapshots, while MyFaces uses a staging repo on their zone. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][maven 2 configuration]
On 8/31/06, Phil Steitz [EMAIL PROTECTED] wrote: Looks like something like this will actually work (so inline profiles can override distributionManagement): That looks great. A component can always override distributionManagement if necessary, so this is still flexible. How and where will you deploy release candidates? This is something that doesn't seem to happen now, but I'd like to see Commons RCs available in a Maven 2 repository. What about a rc profile that points distributionManagement/repository to apache.snapshots? That would allow a release manager to go through the same process for a release candidate, except for using -Prc instead of -Prelease. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][maven 2 configuration]
On 8/27/06, Phil Steitz [EMAIL PROTECTED] wrote: I suggest that we make the following changes: ... At the top of your pom hierarchy, you can inherit from org.apache:apache, and you'll pick up the m2 snapshot repo both in repositories and distributionManagement. http://www.ibiblio.org/maven2/org/apache/apache/3 If you're going to define it again, (for example, to set releases=true if you're going to deploy non-SNAPSHOT versions there,) then I think you should keep the id of 'apache.snapshots' so Maven doesn't think it's a different repository. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Commons SCXML 0.5 published in a Maven repository somewhere?
On 8/26/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Thanks for that. You're welcome. And it's fixed, thanks to Carlos. :) http://www.ibiblio.org/maven2/commons-scxml/commons-scxml/0.5/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Commons SCXML 0.5 published in a Maven repository somewhere?
On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I did put it in the m1-rsync repo [1] and it seems to have been mirrored on ibiblio [2] but last time I checked I couldn't get it into another m1 build so I might need to ping the Maven folks about that. And nothing m2 yet. That shouldn't happen. Unless something has changed, only the Maven 2 repo actually exists, and the Maven 1 repo is done with rewrite rules. I'll go ask on [EMAIL PROTECTED] -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!
On 7/27/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/26/06, Mario Ivankovits [EMAIL PROTECTED] wrote: @phil: What do you think, can we have this? Or is it a bad idea to do this for all projects by default? I can setup my own cronjob to create the link then. +1. The jars we're deploying seem useless currently if people can't depend on them in a snapshot way. Do we even need the dated one? Should it be SNAPSHOT-MMDD? I'm not sure what the recommended way is to do snapshots nowadays. I think it needs to end in -SNAPSHOT for Maven to recognize it. Do you have a way to get the currentVersion out of project.xml/pom.xml ? For VFS it's 1.0-RC8-SNAPSHOT. The dated ones have some value. If something goes wrong in the latest nightly, you can change your pom to depend on yesterday's until you sort out the problem. This doesn't address Vincent's concern of having a stable build to depend on, but that's what releases are for. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r425929 - in /jakarta/commons/sandbox/js2j/trunk: maven.xml pom.xml project.properties project.xml src/ src/main/ src/main/java/ src/main/java/org/
Should the groupId be org.apache.commons instead? -- Wendy On 7/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mrdon Date: Wed Jul 26 19:01:57 2006 New Revision: 425929 URL: http://svn.apache.org/viewvc?rev=425929view=rev Log: Adding Maven 2 build, seeding code from Struts flow ... Added: jakarta/commons/sandbox/js2j/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/sandbox/js2j/trunk/pom.xml?rev=425929view=auto ... + modelVersion4.0.0/modelVersion + nameJS2J/name + groupIdcommons-js2j/groupId + artifactIdcommons-js2j/artifactId + version0.1-SNAPSHOT/version - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!
[moved to commons-dev instead of -user] On 7/26/06, Vincent Massol [EMAIL PROTECTED] wrote: Someone just told me that Cargo is not building anymore because the 20060719 snapshot is no longer there! I checked and it's not there... It looks like there is an automated process to keep a week's worth of nightly builds. Files from 7/20 to 7/26 are present right now: http://people.apache.org/repo/m1-snapshot-repository/commons-vfs/jars/ (Changing the build to publish both -MMDD.jar and -SNAPSHOT.jar might help, then the latest code would always be available at a fixed filename.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On 7/20/06, Henri Yandell [EMAIL PROTECTED] wrote: Is it as important for contributors? If I understand it correctly, the idea of this change (a bunch of projects seem to be moving this way) is that the developers see exactly what they used to see and the contributors get a less spammy list and thus get more involved. It also allows people to choose not only what they receive, but how. Email isn't the only way to 'subscribe' to the lists, you can also get the Atom feed from the ASF mail archives, or use a forum interface like Nabble. (I'd keep dev@ for discussion only, and send wiki diffs to [EMAIL PROTECTED] While we're on the subject, will there be CI server notifications?) Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs][all] nightly build changed?
On 6/19/06, Dion Gillard [EMAIL PROTECTED] wrote: Maybe we could ask to run on a Continuum server? Did anything ever happen with vmbuild.apache.org? * http://marc.theaimsgroup.com/?l=jakarta-commons-devm=114947119511295w=2 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Commons Collections 3.2 released
On 5/15/06, Stephen Colebourne [EMAIL PROTECTED] wrote: The Commons Collections team is pleased to announce the release of commons-collections-3.2. I see it in dist/java-repository, but the jar for Collections 3.2 hasn't been added to ibiblio yet: http://www.ibiblio.org/maven2/commons-collections/commons-collections/ Can someone please check on it? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL 1.1 FC available for final checks
On 5/9/06, robert burrell donkin [EMAIL PROTECTED] wrote: so, please check that i have made no errors in cutting the candidate (ideally by dropping the jar in as a replacement for a RC or 1.0.4) and report back promptly if i have made any mistakes whilst cutting the distribution. The Log4jFactory class appears to be missing. I took an app that's working with commons-logging 1.0.4 and Tomcat 5.5.17, and made only this change: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId -version1.0.4/version +version1.1/version /dependency (I installed the jar with 'mvn install:install-file' and had it generate a pom since commons-logging has no required dependencies. (right?)) I get the following error: INFO: Starting Servlet Engine: Apache Tomcat/5.5.17 May 9, 2006 4:08:12 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled java.lang.reflect.InvocationTargetException 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:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jFactory (Caused by java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jFactory) at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:579) I looked in commons-logging-1.1.jar, commons-logging-api-1.1.jar and commons-logging-adapters-1.1.jar, and I don't see the Log4jFactory class. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL 1.1 FC available for final checks
On 5/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Log4jFactory class appears to be missing. Never mind, it's in the release notes. Sorry, I expected 1.1 to be a drop-in replacement and was surprised by the error. I don't recall any deprecation warnings, though. I've had this in commons-logging.properties for as long as I can remember: org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory Off to read the documentation for 1.0.4 to see what I missed. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
On 4/5/06, Martin Cooper [EMAIL PROTECTED] wrote: Right. But is there any reason we couldn't create a Maven 2 parallel to the Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy RCs there. It's already there: http://cvs.apache.org/maven-snapshot-repository You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will generate a pom for it. That should be fine since Logging has no required dependencies. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons Pool 1.3 Released
On 4/2/06, Sandy McArthur [EMAIL PROTECTED] wrote: The Commons Pool team is pleased to announce the release of Pool 1.3. ... Download: http://jakarta.apache.org/commons/pool/downloads.html Sandy, I see it in www.apache.org/dist, but the download page still has links to version 1.2: http://jakarta.apache.org/site/downloads/downloads_commons-pool.cgi Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] testing JCL 1.1 RC6
On 3/16/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Wed, 2006-03-15 at 16:29 -0700, Wendy Smoak wrote: If you haven't already, it might be good to invite the Spring folks. This caught my eye recently on springframework-user: * http://www.nabble.com/Can-Spring-work-without-commons-logging--t1253162.html want to make contact or shall i? Done. http://www.nabble.com/-OT-ANN-Jakarta-Commons-Logging-1.1.0-Release-Candidate-6-Available-t1293587.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] testing JCL 1.1 RC6
On 3/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: we also need to contact downstream users and ask them if they can verify that JCL 1.1 works for them. that includes tomcat and jboss (i believe that they have a forked version served from a hacked classloader). If you haven't already, it might be good to invite the Spring folks. This caught my eye recently on springframework-user: * http://www.nabble.com/Can-Spring-work-without-commons-logging--t1253162.html Can you also deploy it to cvs.apache.org/maven-snapshot-repository ? Or if you don't have a Maven 2 pom for it, at least put it in the m1 snapshot repository at cvs.apache.org/repository/commons-logging/jars/ ? That will make it much easier to test. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Using maven dependency scope and comment properties WAS: Re: [pool] Dependency on Xerces
On 3/5/06, Phil Steitz [EMAIL PROTECTED] wrote: I have a question about the scope property, which I understand will not show up immediately, but I want to code it correctly. According to the docs here http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html the choices are compile, provided, runtime and test. I don't see optional. Optional isn't a scope, it's just optionaltrue/optional. HTH, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[scxml] Stopwatch example (and Maven 2)
I tried the StopWatchDisplay example, and with JDK 1.5.0_06 on WinXP Pro, it looks like this: http://people.apache.org/~wsmoak/commons-scxml/scxml-stopwatch.gif http://people.apache.org/%7Ewsmoak/commons-scxml/scxml-stopwatch.gif I changed it (around line 110) to get it to look right: - setSize(250,125); +setSize(300,125); Neat. :) And, since it wasn't in cvs.apache.org/maven-snapshot-repository, I converted project.xml to a Maven 2 pom. (At least enough to run the tests and install the jar. It probably needs more work.) http://wiki.wsmoak.net/cgi-bin/wiki.pl?StateChartXML Thanks, -- Wendy
Re: [all] Compile-Source-JDK and Compile-Target-JDK
On 2/13/06, Niall Pemberton [EMAIL PROTECTED] wrote:
Also exec and openpgp only have maven2 build files. I downloaded
maven2 and got as far as working out how to add manifest entries - but
I couldn't work out how to refernece the compile plugin configuration
- so I've left the JDK bits commented out in the sandbox's pom.xml:
http://tinyurl.com/737qc
I don't know how to get at the compiler config directly, but this
seems to work. Uncomment your lines in trunks-sandbox/pom.xml, and in
trunks-sandbox/exec/pom.xml:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source${maven.compile.source}/source
target${maven.compile.target}/target
/configuration
/plugin
/plugins
/build
properties
maven.compile.source1.3/maven.compile.source
maven.compile.target1.3/maven.compile.target
/properties
This is not foolproof-- it's still possible to compile the project
without that configuration, but someone should eventually notice the
expressions showing up in the manifest and fix it. Or Brett will
chime in with the right answer. :)
BTW, the tests for exec won't run for me; I used
-Dmaven.test.skip=true to build the jar so I could look at the
manifest.
$ mvn install
...
---
T E S T S
---
java.lang.NoSuchMethodException: org.apache.commons.exec.TestUtil.init()
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] 1.0.0 Release Candidate 1
On 11/27/05, Niall Pemberton [EMAIL PROTECTED] wrote: Release Candidate 1 of Resources 1.0.0 is now available for download at: http://people.apache.org/~niallp/commons-resources/ Can someone please put the release candidate in the internal Maven repo? http://cvs.apache.org/repository/commons-resources/jars/ I'd like to switch the Struts Extras build over to RC1. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: You can get multiple jars by creating a multiproject. When it comes to non-standard contents, again the answer is that if you want it, probably some others do too, so opening tickets and submitting patches is the right thing to do. That's how we got LICENSE.txt included automatically, for example. Phil, this caught my eye because we (Struts with a Maven 1 build, and Sean Schofield working on a Maven 2 build for MyFaces) are _not_ seeing LICENSE.txt get included automatically. Is it a recent addition that's not yet released? I looked around in JIRA but didn't find a relevant ticket. Was there one? Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
On 12/4/05, Phil Steitz [EMAIL PROTECTED] wrote: NOTICE.txt still needs to be added explicity as a jar resource, IIRC. :::sigh::: Never mind. LICENSE.txt is working fine... it's NOTICE.txt that isn't getting included in the .jar file automatically. Thanks for the confirmation. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r349376 - /jakarta/commons/proper/fileupload/trunk/project.xml
On 11/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: martinc Date: Sun Nov 27 21:26:02 2005 New Revision: 349376 URL: http://svn.apache.org/viewcvs?rev=349376view=rev Log: Fix a copy-paste-o and add a comment about the need for the portlet API dependency. In addition to a comment, propertiesscopeprovided/scope/properties would be nice for both portlet and servlet. It helps when m2 poms from the m1 project.xml files, otherwise the transitive dependencies drag all sorts of things you don't want into WEB-INF/lib. Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[chain] dependencies
I'm trying to sort out the dependencies for Chain-- right now the pom in the repository (for Maven 2) is bringing the Servlet and Portlet APIs plus a beta version of MyFaces into any project that depends on it. From the project home page, it looks like all three of these are optional. Can someone please confirm (for a non-portlet developer) that Portlet works the same way as Servlet, that is, the container provides the API at runtime? In addition, the docs say, To maximize the usefulness of the Chain of Responsibility pattern APIs, the fundamental interface contracts are defined in a manner with zero dependencies other than an appropriate JDK. Does that mean that the BeanUtils, Digester and Logging dependencies are also optional? Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[chain] Please change version number in project.xml
The Commons Chain project.xml file still specifies version 1.0. This means that if you build it locally, Maven will overwrite the official commons-chain-1.0.jar file in your local repository with one containing any changes that have been made since the release. Please change the version number in project.xml, maybe 1.1-dev or 1.0.1-dev would be appropriate. Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Commons Validator 1.2.0 beta test release
From: Don Brown [EMAIL PROTECTED] I've prepared a test release for Commons Validator 1.2.0 beta 1 at http://people.apache.org/~mrdon/commons-validator Let me know if there are any problems, otherwise I'll start working on the official beta release. It (1.2.0-beta-.5) is working fine here. (And I've had last Wednesday's snapshot in production since then with no problems, but the most complicated thing I'm doing with it is a few 'requiredif' validations.) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] 1.2.0-dev missing JavaScript?
Working with the Commons Validator snapshot that Struts 1.3.0-dev depends on, it's complaining about about a dozen missing JavaScript files: 17:16:57,893 - DEBUG org.apache.commons.validator.ValidatorAction - Unable to read javascript name org/apache/commons/validator/javascript/validateDouble.js -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] 1.2.0-dev missing JavaScript?
From: Niall Pemberton [EMAIL PROTECTED] The snapshots look messed up - theres no binary zip version and I can't unzip the tar.gz one. You mean the nightlies? There is a snapshot on cvs.apache.org, which is what I'm using (it's the one listed in the dependencies for Struts). It's working fine-- those were just debug messages from the application log. It would be nice to get a new snapshot though, I see there were several changes. Notably r287172 which I ran into earlier today. Thanks. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] 1.2.0-dev missing JavaScript?
From: Niall Pemberton [EMAIL PROTECTED] OK I've loaded a version here: http://people.apache.org/~niallp/validator/ Where is the snapshot then? Not where I thought it was... Don posted it: http://people.apache.org/~mrdon/repository/commons-validator/jars/ Can you duplicate that directory structure and name the file commons-validator-SNAPSHOT.jar ? Then we'll just switch to using yours instead of Don's. Alternately, you could put it in the internal repository... http://cvs.apache.org/repository/ (Same directory structure: commons-validator/jars/commons-validator-SNAPSHOT.jar ) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] 1.2.0-dev missing JavaScript?
From: Niall Pemberton [EMAIL PROTECTED] OK, its there: http://people.apache.org/~niallp/repository/commons-validator/jars/ Thank you! Sorry if I was not properly appreciative earlier. You probably think the .zip is sufficient and then you get the Maven users complaining that it's not named correctly or in the right place. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] 1.2.0-dev missing JavaScript?
From: Don Brown [EMAIL PROTECTED] I published the commons-validator snapshot to the apache cvs maven repository today and modified the build. Is it a problem with that jar? Long day at work... I think I looked under 'validator' and not 'commons-validator' on http://cvs.apache.org/repository. I see it now. But I was looking for one with Niall's fix for arg0 being ignored (r287172), and it looks like yours (Don's) was done earlier. I have what I need, anyway. :) Niall, you can delete your snapshot, the Struts build will pick up the one from cvs.apache.org. Thanks! -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester][patch] Make NodeCreateRule available through xmlrules
From: robert burrell donkin [EMAIL PROTECTED] How would we get a new SNAPSHOT up to the ibiblio repository? not sure :-/ (i'm unsure about the current ASF policy. i'll try to find out but it may take a while...) A recent post on infra@ suggests that anything placed here http://www.apache.org/dist/java-repository/ gets mirrored on ibiblio. Comparing http://www.apache.org/dist/java-repository/commons-digester/jars/ to http://www.ibiblio.org/maven/commons-digester/jars/ seems to confirm. And there's even an old SNAPSHOT on ibiblio, so putting a new one in java-repository should overwrite it. I'm less sure about all the other files involved... I've been posting just .jar files to the internal Apache repository with good results. (I think some of the extra files might be for Maven2.) As for policy, I haven't found anything beyond the existing policy on releases. Anything labeled SNAPSHOT or seems to be okay to post unofficially-- at least, so far no one has said anything about mine. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Sending serialized object from httpclient to servlet.
From: Sanjeev Tripathi [EMAIL PROTECTED] Can any one tell me how send serialized object to servlet from httpclient. Colin already gave you one option, (base 64 encoding the binary data): http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg57055.html For general information on base 64 encoding: http://www.google.com/search?q=java+base64+encoding Here's Jakarta Commons Codec, which includes a base 64 encoder: http://jakarta.apache.org/commons/codec/ http://jakarta.apache.org/commons/codec/apidocs/org/apache/commons/codec/binary/Base64.html Without actually trying it, it looks like all you need to do is: byte[] encodedData = Base64.encodeBase64( binaryData ); Then turn the byte[] into a String and POST it to the server as the value of a request parameter. If it's not too big, it should work the same way as sending a big string from a text area. The 'commons-dev' list is usually reserved for questions about the development of the libraries themselves, so I'm replying to commons-user (and copying dev). -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
Not sure if it's been discussed already, but I'm very much in favor of this (from the Wiki): - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
(oops, wrong button) Not sure if it's been discussed already, but I'm very much in favor of this (from the Wiki): ' It would be nice for SetProperties and SetNestedProperties rules to automatically map xml attributes and element names like foo-bar to bean properties of form fooBar. ' It's actually listed as a possible enhancement for 1.7, but wherever it ends up, it will be appreciated. (Assuming it isn't there already and I missed it...) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
From: Simon Kitching [EMAIL PROTECTED] ' It would be nice for SetProperties and SetNestedProperties rules to automatically map xml attributes and element names like foo-bar to bean properties of form fooBar. ' If you feel like having a go at this yourself, I would be very happy to see a patch. Much as I'd love to play with Digester instead, homework wins out (for the moment at least.) Let's see how long it takes me to write a small recursive-descent parser that reads in arithmetic expressions, parses each one into an abstract syntax tree, and evaluates it. :) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] initial code for Digester2.0
From: Simon Kitching [EMAIL PROTECTED] Ok, we'll see what the general consensus is. I happen to personally like prefixes rather than suffixes, but will go with the majority opinion. Another vote for suffix - I prefer CallMethodAction to ActionCallMethod. Will ActionFactory have all of the available Action constructor signatures? Thanks, Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Having trouble with svn checkout
From: Henri Yandell [EMAIL PROTECTED] wrote: The SVN migration is finished. For an individual component, using lang as an example: svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk/commons-lang; I'm having trouble checking out a single Commons project: $ svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk/commons-lang svn: URL 'http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk/commons-lang' doesn't exist I was able to get the entire commons/proper using the command Craig posted yesterday (good thing disk space is cheap!): $ svn checkout http://svn.apache.org/repos/asf/jakarta/commons/proper/current What am I doing wrong? -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] Problem with indexed properties
Someone on struts-user got tripped up by what I thought was a bean that
didn't conform to the spec, but then I learned that for an indexed property,
you can have four accessors, such as:
String[] getProp()
String getProp( int )
void setProp( String[] )
void setProp( int, String )
The struts user threads are:
http://marc.theaimsgroup.com/?t=11064425001r=1w=2
http://marc.theaimsgroup.com/?t=11066637976r=1w=2
I can reproduce the 'argument type mismatch' error under both Windows and
HP-UX, with JDK 1.4.2 or 1.5.0, with this code:
BeanUtilsBean beanUtilsBean = new BeanUtilsBean(
new ConvertUtilsBean(),
new PropertyUtilsBean());
IndexedBean bean = new IndexedBean();
String[] newValue = new String[] { dog, cat, bird };
beanUtilsBean.setProperty(bean, prop, newValue );
(IndexedBean just has the four methods shown above.)
test.bean:
[echo] Running BeanUtils tests ...
[java] [ERROR] PropertyUtils - Method invocation failed.
java.lang.IllegalArgumentException: argument type
mismatchjava.lang.IllegalArgumentException: argument type mismatch
The additional test and bean are attached to bug 28358.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28358
It was originally reported as a JVM problem, but even if the code would work
under 1.3.1, that isn't going to help those of us who have long since moved
up to 1.4 and 1.5.
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[digester] Problem building javadoc w/ Ant on Windows
I'm getting an error when building the Digester Javadoc locally with Java 1.5 on XP Pro (SP2): javadoc: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] javadoc: error - Illegal package name: IS BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions andlimitations under the License. -- It seems to be related to the single/double quotes around the javadoc bottom= ... attribute. Simon Kitching said he cannot reproduce it on JDK1.5/Linux (http://issues.apache.org/bugzilla/show_bug.cgi?id=33129#c3) so it appears to be a Windows-only thing. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Problem building javadoc w/ Ant on Windows
From: simon [EMAIL PROTECTED] It does seem weird that this doesn't work on Windows, as the xml spec is *very* clear about the fact that xml attributes can be quoted using '...' or ..., so having a simple testcase that shows the problem would reassure me that the problem really is what we think it is.. We're talking about this section of build.xml: bottom='Copyright (c) 2001-2004 - Apache Software Foundation lt;!-- Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --gt;' First, without the quotes around AS IS, the generated HTML source has only one line for me when viewed with FireFox and IE, so all the white space and formatting doesn't seem useful. The quotes around the word License do not cause a problem, *but* they do not make it into the generated HTML either. Can someone build the docs with Linux and confirm that the formatting and the quotes around License and AS IS actually make it into the generated HTML? Because if not, the quotes can be removed from build.xml without affecting the output. Given that this build.xml isn't actually used to build the documentation that goes on the website, and that the HTML comment that's causing the problem doesn't even appear in the current Javadoc (such as http://jakarta.apache.org/commons/digester/apidocs/org/apache/commons/digester/Digester.html ) how important are those quotes? Attempting to fix the problem, once I get rid of the quotes around AS IS then I start getting these warnings: [javadoc] Constructing Javadoc information... [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester.parser [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester.plugins [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester.plugins.strategies [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester.substitution [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons.digester.xmlrules [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache.commons [javadoc] javadoc: warning - Multiple sources of package comments found for package org.apache [javadoc] javadoc: warning - Multiple sources of package comments found for package org [javadoc] Standard Doclet version 1.5.0_01 I have no idea what it's talking about. Ok, so can this be fixed by escaping the quotes in the problem text, eg using quot;? Using quot;AS ISquot; doesn't work, I get the same error as with the original AS IS. Chalk this one up to annoying but easily fixable. Other than deleting the quotes around AS IS (which might annoy the lawyer types) I don't see what else to do with it. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] download page for VFS has bad link
From: B. K. Oxley (binkley) [EMAIL PROTECTED] http://jakarta.apache.org/commons/sandbox/vfs/download.html The link for Commons Collections points to the logging library instead. Would a patch be at all useful here, or is it far easier for a committer to type in the change rather than review and apply a patch? (If a patch would be useful, can little things like this be pasted into an email message, or do you always want them attached to bugs?) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
