[jira] Updated: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Pugh updated SANDBOX-183: -- Attachment: myzip2.zip Fixed most of Mario's style concerns. Did not address the memory issue yet. Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Attachments: myzip.zip, myzip2.zip Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Pugh updated SANDBOX-183: -- I fixed the style concerns, but did not fix the allocation size issue yet. Should not be hard to do, and it should be done. I'm not sure how you plan to modify a zip file, whether you do it the temp file way or the change in place way, where a process crash would not create a corrupted version of the file. Traditionally, you would do this by creating a temporary zip file, and doing a mv on it, so the name changed to the new name, but no data needed to be moved. I'm not sure you can do this in Java, unless you had planned on shelling out the OS (and detecting different OSes to do this). There were two main reasons I wanted to do this in memory: 1) So you would not need any type of temp directory 2) The performance differences can be VAST in some cases. Imagine dealing with large XML or text files, or anything where the compression is significant. If you do the temp file approach, you need to uncompress everything, and write it to a file. Then, re-open all those files and re-compress them. This is not only a lot more CPU time in compressing and uncompressing, but also a lot more data-movement using the disk drive. Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Attachments: myzip.zip, myzip2.zip Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SANDBOX-183) Compress should allow for writing to Zip Files
Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-183) Compress should allow for writing to Zip Files
[ https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Pugh updated SANDBOX-183: -- Attachment: myzip.zip Compress should allow for writing to Zip Files -- Key: SANDBOX-183 URL: https://issues.apache.org/jira/browse/SANDBOX-183 Project: Commons Sandbox Issue Type: New Feature Components: Compress Affects Versions: Nightly Builds Reporter: Will Pugh Fix For: Nightly Builds Attachments: myzip.zip Compress should be able to modify existing ZipFiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Why does needs the method declaring a class to be public
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
JIRA reports are good - we've a big backlog in BeanUtils but it's
starting to go down.
There are a couple of other similar issues (BEANUTILS-157 +
BEANUTILS-87).
I don't know why the API is designed to only work with public methods;
whether that's an aspect of adherence to the spec, by design or
legacy. Seems that if we're going to use setAccessible, that we could
just open it to package and private too.
Anyone know why MethodUtils intentionally limits itself?
Hen
On 11/22/06, Tom Schindl [EMAIL PROTECTED] wrote:
Hi,
Nobody any comments should I file a bug report against JIRA?
Tom
Tom Schindl schrieb:
Hi,
I have an issue the current implementation of
MethodUtils#getAccessibleMethod(Method) where it reads:
8
if( Modifier.isPublic(clazz.getModifiers()) ) {
}
// Check the implemented interfaces and subinterfaces
8
With this check setting attributes on a class Hierarchy like the one
below doesn't work:
8
class HiddenBean {
private String a;
protected HiddenBean() {
}
public void setA(String a) {
this.a = a;
}
public String getA() {
return this.a;
}
}
public class PublicBean extends HiddenBean {
}
8
The problem is that big framework like e.g. Eclipse often use
package-visible classes to not expose too much API to the user and you
can't use BeanUtils currently to set values.
I came across this problem when trying to provide an enhanced
version of
XSWT which is not working in Eclipse 3.2 but not in 3.3 any more
because
of this.
What would be the problem to change the check to the following:
MethodUtils#getAccessibleMethod(Method):
8
if( ! Modifier.isPrivate(clazz.getModifiers()) !
Modifier.isPackage(clazz.getModifiers()) ) {
}
8
PropertyUtilsBean#invokeMethod(...):
8
method.setAccessible(true);
return method.invoke(bean,values);
8
I first wanted to discuss this here and not creating an bug
immediately.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Torsten Curdt wrote: On 10/25/06, James Carman [EMAIL PROTECTED] wrote: For someone who uses Commons Collections a lot in their applications, this is going to be quite a pain if I want to upgrade. Yes, I realize that there's such a thing as find and replace, but the fact that I have to do that if I want to upgrade is just a bother. That's my $0.02. Well, easy ...then you don't upgrade ;) Sorry, but the fact that an upgrade is not always is as easy as replacing a jar is not an argument (IMO) As long as there is an upgrade path it's up to the user to walk that path or not. The important thing though is to have such a path. This seems like a strange argument, since the Don't Upgrade path is valid for people who are running into conflicts from API changes as well (and there are probably a lot more people that won't run into these problems if the removals are mostly focused on deprecated components.) I understand that sometimes conflicts can be a bit round about, they upgrade to (or add) a new component of Y and it causes their commons-collections to get upgraded. They still have the choice of not making this upgrade, or using that other component. Or they have the choice of using JarJar or some other tool force package changes. Or helping to fix the dependency if they are using some open source project. I think we want to make the common case as easy as possible, and changing the package names makes the common case a pain in the butt. I would suggest this means staying as close to backwards compatible as possible, with the removal of only things that have been deprecated. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
majority of people more difficult for the advantage of a pretty small
few. What specific BackCompat issues are you expecting? When I hear
Generifying Collections, I keep thinking you will keep the APIs the
same, but you will simply add generic support to them. Am I off?
Example:
If you generi-size
public class TestClass {
public Object Get(Object t) {
return t;
}
}
to be
public class TestClassT {
public T Get(T t) {
return t;
}
}
It is still valid to either use the generics or not, e.g. both of these
still work.
TestClassTester test1 = new TestClassTester();
TestClass test2 = new TestClass();
tester = test1.Get(tester);
tester = (Tester) test2.Get(tester);
Therefore, simply upgrading the library should not cause you backwards
compat problems, unless there is something I'm missing. However, you
will make it much harder for people to simply upgrade to the new release.
Thanks,
--Will
Stephen Colebourne wrote:
Stephen Colebourne wrote:
Because commons isn't like other OSS projects. We can't go around
changing our APIs freely, even between major versions. Its a simple case
of us being at the bottom of the stack of jars. If we do change an API,
any API then jar hell ensues because higher OSS projects will clash on
their required versions of [collections].
Henri wrote:
I'm not convinced by that. What you're saying is that if we want to
have a major API change in a component, that we need to change the
package name so two pieces of code can sit side by side. If that's
true, then we should do it for all major versions (as major API change
is the defining factor of major version changing) and stay within the
same component.
Having a bit of deja vu - think we had this discussion 6 months ago
Actually it was over [net], and recently. And yes, its not nice, but a
different package name is all that we get given by Java at present. However,
there are cases where a major version change can be done without breaking
backwards compatability - typically, where the only change is to remove
deprecations ([lang] 3?).
We could just say that its the responsibility of everyone using commons to
repackage our code into their package structure, but IMHO thats just not
practical, and quite wasteful.
Basically - we need to start putting the major version in our package
names. I hate that, but I can see the need.
Yep, it sucks. Yep, its essential.
So this would be a branch of collections, with a package name
change to org.apache.commons.collections4.*.
Well, the number is dependent on the strategy we are trying to achieve:
a) using '4' would indicate that every major version will have a new package
name, but then you can't use a major version to just remove deprections (a
compatible major version change)
b) using '5' would indicate the technology reason for the version. The package
would be commons-collections5-1.0.
c) using '5' as the commons name - commons5-collections-1.0
I favour (b) as I view this as a fork of [collections] for a new technology. I
believe the language changes in JDK5 are significant enough to warrant a fork.
Would be sweet to have a build system that could deal with moving
source from org/apache/commons/collections/ to the correct directory
and package name prior to compiing/source-packaging. Might be worth
playing with some Ant scripts for that.
Not sure how that helps. The new JDK5 code will probably be a proper fork, with
some significant method name/class changes.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
Stephen Colebourne wrote:
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards compatability, Sun had to go to extreme lengths
to ensure that the erased type of each generics element corresponds to the
previous type of the method. Consider the max method on Collections:
public static T extends Object Comparable? super T T max(Collection?
extends T coll)
Where because Object comes before Comparable in the list of bound types, its
Object that the method signature gets erased to. Now thats pretty nasty.
Are fixes like this really grosser than a full package rename? Seems
like the amount of code changed by fixing this in collections is much
less than the amount of code changed if all the new users of collections
need to change package names. Thus, the average upgrade experience
would be better.
For [collections], there are cases worse than this, such as MultiMap, where the
sf projects have demonstrated that it is not possible to generify the class
without breaking backwards compatability, typically because our interface isn't
a true implementation of the original interface.
If there are specific classes where you cannot fix them, it might make
more sense to make parrallel classes rather than a whole package
change. It seems like there will be more collections where creating
generics is straightforward, than ones where it is impossible.
Beyond this, there are some classes (like TypedList that we don't even want to
port as they'd be pointless), plus my desire to create a smaller jar file (time
depending), there is ample reason to not worry excessively about backwards
compatability. We shoud target about 90% backwards compatible, with the rest
being fixing API flaws and issues we have now.
A simple port may appeal conceptually, but its not really viable at all.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generifying Collections
We could also mash together collections and generics to get commons-collagen I'm sure there are some great puns we could pull out of that. . . --Will Mario Ivankovits wrote: Hi! collections5 ? (don't like collgenerics) I think we should try not to put the technology into the name, nor the target jvm version number. Think about something like collections5 4.0 somehow strange, no? - like java2 1.3.0 ;-) Personally I'd simply create a new branch, maybe call it 5.0 and continue developing there, but I know that this is not possible due to the version conflicts where one library requires the non generified and and another the new one. Hopefully java will solve this some day. What if we simply take the singluar of collections: collection ? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-268) StringUtils.join should allow you to pass a range for it (so it only joins a part of the array)
StringUtils.join should allow you to pass a range for it (so it only joins a part of the array) --- Key: LANG-268 URL: http://issues.apache.org/jira/browse/LANG-268 Project: Commons Lang Type: Improvement Reporter: Will Pugh Attachments: addRangeToJoin.patch Currently join, takes an array of objects, adn joins them using a character or string as a separator. The problem is that there are many instances where I have an array, but I only want to join part of it. There are various split, etc. I can use to get this to work, but the problem is that they are all inefficient and more work than I think I should have to do. I've attached a patch that introduces two new methods to do what I am requesting (one for the string case, one for the character case), as well as additions to the unit tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-268) StringUtils.join should allow you to pass a range for it (so it only joins a part of the array)
[ http://issues.apache.org/jira/browse/LANG-268?page=all ] Will Pugh updated LANG-268: --- Attachment: addRangeToJoin.patch A patch with the new methods as well as new unit tests StringUtils.join should allow you to pass a range for it (so it only joins a part of the array) --- Key: LANG-268 URL: http://issues.apache.org/jira/browse/LANG-268 Project: Commons Lang Type: Improvement Reporter: Will Pugh Attachments: addRangeToJoin.patch Currently join, takes an array of objects, adn joins them using a character or string as a separator. The problem is that there are many instances where I have an array, but I only want to join part of it. There are various split, etc. I can use to get this to work, but the problem is that they are all inefficient and more work than I think I should have to do. I've attached a patch that introduces two new methods to do what I am requesting (one for the string case, one for the character case), as well as additions to the unit tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 6
Hmm. Factories have always seemed most useful to me when they are encapsulating the creation of some configurable resource. In practice, it seems like configurable most often means pulling a string from some attribute or properties file, and using that to choose implementation. If the type of Archiver I am using is static and would never change, I would simply the Archiver's constructor. If it's not static and will change, you are almost always going to have to deal with a string at some point. Passing that string into a factory is easier than getting this ZIP member via reflection (and cleaner than special casing every Archiver type) --Will Sandy McArthur wrote: On 5/12/06, Torsten Curdt [EMAIL PROTECTED] wrote: here is a new draft: http://www.grobmeier.de/commons-compress-draft-6.zip I have changed a lot of things discussed with draft 5. The API is easier now. Everything what seems to be unnecessary has been deleted. Compress is working with Files and InputStreams only, no more String-params are allowed. New is also ArchiveEntry, which represents the entry of an archive ;-). For example, a zip file can be created like this: Archiver archiver = ArchiverFactory.ZIP.getInstance(); Why not use a proper factory? Did you consider my suggestions? http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg79370.html At Draft 3 or 4 I suggested he use a type safe enum for an ArchiveType which fully implemented would have implicitly had the factory feature built in and can remain extendable. eg: ArchiveType someType = ArchiveType.valueOf(zip) Archive someArchive = someType.newInstance(); the small problem with that or any factory is the use of a String to request a behavior means the compiler cannot know for sure if that code will work. The enum solves this if the programmer wants by having the constants. If the compiler allows the following you know it work: Archive zip = ArchiveType.ZIP.newInstance(); That said, it's better to commit to one idiom. Chris, as long as you have the ball on this you gotta pick the suggestions that work well together from all the feedback. On the surface the ArchiveFactory Factory/Enum hybrid seems to be less good than just using either a factory pattern or an enum pattern alone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Draft 6
Yeah. I agree valueOf would work just fine, but unless I'm missing something, the current implementation doesn't have this. The purpose of my comments was to say that I thought it should have something along those lines. I'm unsure of the value of having the static Factories, e.g. ArchiverFactory.ZIP --Will Sandy McArthur wrote: On 5/12/06, will pugh [EMAIL PROTECTED] wrote: Hmm. Factories have always seemed most useful to me when they are encapsulating the creation of some configurable resource. In practice, it seems like configurable most often means pulling a string from some attribute or properties file, and using that to choose implementation. If the type of Archiver I am using is static and would never change, I would simply the Archiver's constructor. If it's not static and will change, you are almost always going to have to deal with a string at some point. Passing that string into a factory is easier than getting this ZIP member via reflection (and cleaner than special casing every Archiver type) FWIW: Reflection isn't needed for the valueOf method. the method just looks in an internal Map or Set for the requested type. Sandy McArthur wrote: On 5/12/06, Torsten Curdt [EMAIL PROTECTED] wrote: here is a new draft: http://www.grobmeier.de/commons-compress-draft-6.zip I have changed a lot of things discussed with draft 5. The API is easier now. Everything what seems to be unnecessary has been deleted. Compress is working with Files and InputStreams only, no more String-params are allowed. New is also ArchiveEntry, which represents the entry of an archive ;-). For example, a zip file can be created like this: Archiver archiver = ArchiverFactory.ZIP.getInstance(); Why not use a proper factory? Did you consider my suggestions? http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg79370.html At Draft 3 or 4 I suggested he use a type safe enum for an ArchiveType which fully implemented would have implicitly had the factory feature built in and can remain extendable. eg: ArchiveType someType = ArchiveType.valueOf(zip) Archive someArchive = someType.newInstance(); the small problem with that or any factory is the use of a String to request a behavior means the compiler cannot know for sure if that code will work. The enum solves this if the programmer wants by having the constants. If the compiler allows the following you know it work: Archive zip = ArchiveType.ZIP.newInstance(); That said, it's better to commit to one idiom. Chris, as long as you have the ball on this you gotta pick the suggestions that work well together from all the feedback. On the surface the ArchiveFactory Factory/Enum hybrid seems to be less good than just using either a factory pattern or an enum pattern alone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
Sandy McArthur wrote: On 4/30/06, will pugh [EMAIL PROTECTED] wrote: 1) You often change method names based on the parameter types, e.g. Archiver.addFile + Archiver.addFileName, setUnpackDestinationName + setUnpackDestinationFile, etc. It seems more conventional and less chaotic to give all the methods the same name, and have them only differ based on parameter. Examples of this style are constructors for java.utils.zip.ZipFile, java.io.FileInputStream, java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy, org.apache.commons.io.FileUtils.isFileNewer, etc This is intentional, in a previous version the method names were the same. The problem with using the same name but different param types breaks the JavaBean property getter/setter rules and the classes will not be as usable in at least some scripting environments. Hmm. What scripting envirionments don't allow you to call this kind of Java method? I looked at the documentation for Jythong, JRuby and Groovy and they all seemed to be O.K. with dealing with methods that differ by parameter types. Also, it doesn't seem like the current interface adheres to the Java Bean specification anyways (unless I'm missing somethign). If you wanted to adhere to the Java Beans Spec, I would suggest having only one getter and one setter for each property, i.e. not having a setUnpackDestinationFile and setUnpackDestinationFileName, but only having setUnpackDestination(File f). As I see it, here is the list of areas I think the archiver interface offers odd behaviour relative to the JavaBean spec: 1) The sourceFile property is recieved by getSourceFile(), but is set by loadFile and loadFilebyPath. Following the JavaBeans rules, this means there is a readonly property called sourceFile, rather than this being a property that is gettable and settable. In addition to load* are bad names because they don't actually load anything. 2) The unpackDestination property has a getter, but no setter. The unpackDestinationFile property has a setter but no getter. The unpackDestinationName property has a setter but no getter 4) None of your interfaces deal with the case of what to do if the destination file is already there. Choices are either defining it in the interface, or adding a property defining what to do. I would suggest the latter, and would suggest that for Archiver this method should take a FileFilter (since the unpack behaviour can be non-trivial) and should default to FalseFileFilter.INSTANCE. For the Compresser interface a simple boolean is probably sufficient. e.g. Archiver.setOverwriteFilter(TrueFileFilter.INSTANCE) Compresser.setOverwrite(true); I'll disagree that this should be configurable. IMO it should just do whatever FileOutputStream or whatever is used does. It's the calling code's responsibility to handle any name collisions. How can the calling code handle name collisions? It takes significantly more work for it to walk through all the entries in the archive and then walking through all the files in the file ssytem. Are you suggesting a caller should only unpack into an empty directory? I'm not really sure I understand what your saying about FileOutputStream. The apis for the Archiver don't allow you to set an OutputStream, and it's not really applicable to upack (which is writing many files). FileOutputStream allows you to set a boolean for whether the stream should overwrite or append. This is made more difficult in the unpack scenario where there are more than one file. From personal experience, I liked the solution used in FileUtils.iterateFiles and FileUtils.listFiles for doing yeah/nay on a recursive operation like this. Cheers, --Will -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
I may be missing some requirements here, but it seems like in light of the JavaBean bits we were talking about, that it makes sense to restrict the properties on the actual interface, and have them correspond directly to JavaBean properties. In addition, I would propose getting rid of some properties and moving them onto the method calls. Is there a reason not to? For an interface that basically does two things, it is suprising that it has 16 methods on it. Of those, 9 appear to be getter/setters on properties. Those 9 getters/setters refer to 3 properties in AbstractArchiver. Of those 3 properties, only 1 is used by more than one method (that is not a getter/setter). Why do we have destinationFile and unpackDestination properties on the object, if they are only used in one place? Why not just make these parameters? If you did this, you would have an interface that offers the exact same functionality, but has only 6 methods. Seems like there is a bit of extra entropy. In addition, I sorta like the way java.io.File, java.util.zip.ZipFile, etc let you set the source file in the constructor. It makes the code using the objects less verbose, with no loss of readability. I would suggest that we add this to the archivers, by adding constructors that can take a string or a file for the source file. In addition, we can bubble those changes up to the ArchiverType class. What is the purpose of the ArchiverType class? I'm assuming the idea is that this helps folks build factories, but that it is perfectly acceptable and encouraged to create any of the archivers via 'new'. Is that correct? Thanks, --Will Sandy McArthur wrote: On 5/1/06, will pugh [EMAIL PROTECTED] wrote: Sandy McArthur wrote: On 4/30/06, will pugh [EMAIL PROTECTED] wrote: 1) You often change method names based on the parameter types, e.g. Archiver.addFile + Archiver.addFileName, setUnpackDestinationName + setUnpackDestinationFile, etc. It seems more conventional and less chaotic to give all the methods the same name, and have them only differ based on parameter. Examples of this style are constructors for java.utils.zip.ZipFile, java.io.FileInputStream, java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy, org.apache.commons.io.FileUtils.isFileNewer, etc This is intentional, in a previous version the method names were the same. The problem with using the same name but different param types breaks the JavaBean property getter/setter rules and the classes will not be as usable in at least some scripting environments. Hmm. What scripting envirionments don't allow you to call this kind of Java method? I looked at the documentation for Jythong, JRuby and Groovy and they all seemed to be O.K. with dealing with methods that differ by parameter types. Also, it doesn't seem like the current interface adheres to the Java Bean specification anyways (unless I'm missing somethign). If you wanted to adhere to the Java Beans Spec, I would suggest having only one getter and one setter for each property, i.e. not having a setUnpackDestinationFile and setUnpackDestinationFileName, but only having setUnpackDestination(File f). I'll agree it's not strict adherence to the JavaBean spec but following JavaBean conventions even partially can be useful. A few years ago I was treating some JavaMail objects like beans and between Java 1.3 and 1.4 the rules on how Java determined what was a legal javabean property got more strict. This caused problems when I did something similar to message.bodyPart.subject in a JSP el expression. and there was one getBodyPart() and two setBodyPart(Type1) and a setBodyPart(Type2). As I see it, here is the list of areas I think the archiver interface offers odd behaviour relative to the JavaBean spec: 1) The sourceFile property is recieved by getSourceFile(), but is set by loadFile and loadFilebyPath. Following the JavaBeans rules, this means there is a readonly property called sourceFile, rather than this being a property that is gettable and settable. In addition to load* are bad names because they don't actually load anything. 2) The unpackDestination property has a getter, but no setter. The unpackDestinationFile property has a setter but no getter. The unpackDestinationName property has a setter but no getter Okay, I'll agree that unpackDestinationFile getter should be renamed to unpackDestination but the unpackDestinationName property should still keep a separate name and it's okay if it's a dynamic property that really sets the unpackDestination property. 4) None of your interfaces deal with the case of what to do if the destination file is already there. Choices are either defining it in the interface, or adding a property defining what to do. I would suggest the latter, and would suggest that for Archiver this method should take a FileFilter (since the unpack behaviour can be non
Re: [compress] New draft 5
I'm not sure if there is some requirement I'm missing, but 1) It still seems strange to me that we have an interface that does two things: pack an archive + unpack an archive, yet it has 16 methods on it. Of these, 9 seem to be some variation of property getters/setters. As far as I can tell, none of these properties are used by both the pack and unpack process. Methods that set/get properties only used 1) Why do we need getters and setters that take both a File and a String as parameters? Why can't we standardize on just having a File type for sourceFile and unpackDestination. 2) I'm still not sure why unpackDestination is a property and not just a parameter on unpack? It seems that it is a property that is used in one and only one place. It seems like logically its not a property of the Archiver as much as a property of the actual packing process. 3) Why don't we have a constructor for each of the archivers that can take a String or a File as the SourceFile (similar to how java.io.File, java.util.zip.ZipFile, etc deal with this). If you didn't want to enforce this as a convention for Archivers, it could easily be added into the ArchiverType.getInstance() method. We could have ArchiverType provide two getInstance methods, one could take a string and one could take a file. This way the interface can be minimal, and we can hoist type conversions off to helpers rather than the interface 4) What is the purpose of the ArchiverType? I'm assuming this is meant to help people build their own factories? but the common case for creating an Archiver is still to create using 'new'. Is this right? --Will Sandy McArthur wrote: On 5/1/06, will pugh [EMAIL PROTECTED] wrote: Sandy McArthur wrote: On 4/30/06, will pugh [EMAIL PROTECTED] wrote: 1) You often change method names based on the parameter types, e.g. Archiver.addFile + Archiver.addFileName, setUnpackDestinationName + setUnpackDestinationFile, etc. It seems more conventional and less chaotic to give all the methods the same name, and have them only differ based on parameter. Examples of this style are constructors for java.utils.zip.ZipFile, java.io.FileInputStream, java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy, org.apache.commons.io.FileUtils.isFileNewer, etc This is intentional, in a previous version the method names were the same. The problem with using the same name but different param types breaks the JavaBean property getter/setter rules and the classes will not be as usable in at least some scripting environments. Hmm. What scripting envirionments don't allow you to call this kind of Java method? I looked at the documentation for Jythong, JRuby and Groovy and they all seemed to be O.K. with dealing with methods that differ by parameter types. Also, it doesn't seem like the current interface adheres to the Java Bean specification anyways (unless I'm missing somethign). If you wanted to adhere to the Java Beans Spec, I would suggest having only one getter and one setter for each property, i.e. not having a setUnpackDestinationFile and setUnpackDestinationFileName, but only having setUnpackDestination(File f). I'll agree it's not strict adherence to the JavaBean spec but following JavaBean conventions even partially can be useful. A few years ago I was treating some JavaMail objects like beans and between Java 1.3 and 1.4 the rules on how Java determined what was a legal javabean property got more strict. This caused problems when I did something similar to message.bodyPart.subject in a JSP el expression. and there was one getBodyPart() and two setBodyPart(Type1) and a setBodyPart(Type2). As I see it, here is the list of areas I think the archiver interface offers odd behaviour relative to the JavaBean spec: 1) The sourceFile property is recieved by getSourceFile(), but is set by loadFile and loadFilebyPath. Following the JavaBeans rules, this means there is a readonly property called sourceFile, rather than this being a property that is gettable and settable. In addition to load* are bad names because they don't actually load anything. 2) The unpackDestination property has a getter, but no setter. The unpackDestinationFile property has a setter but no getter. The unpackDestinationName property has a setter but no getter Okay, I'll agree that unpackDestinationFile getter should be renamed to unpackDestination but the unpackDestinationName property should still keep a separate name and it's okay if it's a dynamic property that really sets the unpackDestination property. 4) None of your interfaces deal with the case of what to do if the destination file is already there. Choices are either defining it in the interface, or adding a property defining what to do. I would suggest the latter, and would suggest that for Archiver this method should take a FileFilter (since the unpack behaviour can be non
Re: [compress] New draft 5
Overall, I like the interfaces, but I've got a few issues: 0) Update is mentioned in the Javadoc at the beginning of Archiver, but is not implemented. 1) You often change method names based on the parameter types, e.g. Archiver.addFile + Archiver.addFileName, setUnpackDestinationName + setUnpackDestinationFile, etc. It seems more conventional and less chaotic to give all the methods the same name, and have them only differ based on parameter. Examples of this style are constructors for java.utils.zip.ZipFile, java.io.FileInputStream, java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy, org.apache.commons.io.FileUtils.isFileNewer, etc 2) You can only add files to an archive, this makes it more difficult to add generated entries into an archive. You need to actually write them to disk before including them in an archive 3) UnpackDestination + Destination should be the same property (on the both the interface as well as underlying implementation), or you should split packing and unpacking into two different interfaces (or force folks to pass a path to pack + unpack, instead of setting properties on the object). 4) None of your interfaces deal with the case of what to do if the destination file is already there. Choices are either defining it in the interface, or adding a property defining what to do. I would suggest the latter, and would suggest that for Archiver this method should take a FileFilter (since the unpack behaviour can be non-trivial) and should default to FalseFileFilter.INSTANCE. For the Compresser interface a simple boolean is probably sufficient. e.g. Archiver.setOverwriteFilter(TrueFileFilter.INSTANCE) Compresser.setOverwrite(true); 5) In AbstractCompressor, I don't understand why you have a copy method and don't just use IOUtils.copy() 6) In AbstractCompressor, I don't understand why you try to create your own temp name, rather than just letting File.createTempFile do it's thing. --Will C. Grobmeier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, here is a new draft for the compress interface: * http://grobmeier.de/commons-compress-draft-5.zip I have improved a lot of things, based on the comments of Sandy (thanks for that). This draft is not perfect, as you can see in the todo list. But imho we have a quite good base for future work, everything compiles and works and is documented. So i would like to propose that someone is comitting this, except you have reasons not to do this. If you agree with me, i will open a bugzilla issue and add the link to the code. - - Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEVKMikv8rKBUE/T4RAlxxAKCMYzova2roWDA/skRyoDvFcErE2gCfTjFw bT2VrGdR8Byt+VjsRo7Cyhw= =1GRF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] New draft 5
It occured to me later on, that I think this interface would be better
if it were focused on describing an Archive, rather than trying to
describe two processes (ie describing the noun rather than all the
verbs). The fall out from this, is that you don't have a member for an
unpack directory, since that is only relevent to the unpacking process.
and I think it makes the interface I went to mock this up and came up
with a couple other issues with the interface.
1) Adding an entry or a file to an archive, you need to be able to
set the entry name, otherwise you can run into problems with getting
just the right relative path in the archive for the files.
2) It is pretty common to want to recursively add directories, we
should provide this in the archive API
I've attached my mock-up so folks can see if they think these thoughts
make sense. I tried to borrow design and parameter conventions from
some of the commons-io methods I use alot.
--Will
will pugh wrote:
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver,
but is not implemented.
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
setUnpackDestinationFile, etc. It seems more conventional and less
chaotic to give all the methods the same name, and have them only
differ based on parameter. Examples of this style are constructors
for java.utils.zip.ZipFile, java.io.FileInputStream,
java.io.FileOutputStream, org.apache.commons.io.IOUtils.IOUtils.copy,
org.apache.commons.io.FileUtils.isFileNewer, etc
2) You can only add files to an archive, this makes it more difficult
to add generated entries into an archive. You need to actually write
them to disk before including them in an archive
3) UnpackDestination + Destination should be the same property (on
the both the interface as well as underlying implementation), or you
should split packing and unpacking into two different interfaces (or
force folks to pass a path to pack + unpack, instead of setting
properties on the object).
4) None of your interfaces deal with the case of what to do if the
destination file is already there. Choices are either defining it in
the interface, or adding a property defining what to do. I would
suggest the latter, and would suggest that for Archiver this method
should take a FileFilter (since the unpack behaviour can be
non-trivial) and should default to FalseFileFilter.INSTANCE. For the
Compresser interface a simple boolean is probably sufficient. e.g.
Archiver.setOverwriteFilter(TrueFileFilter.INSTANCE)
Compresser.setOverwrite(true);
5) In AbstractCompressor, I don't understand why you have a copy
method and don't just use IOUtils.copy()
6) In AbstractCompressor, I don't understand why you try to create
your own temp name, rather than just letting File.createTempFile do
it's thing.
--Will
C. Grobmeier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
here is a new draft for the compress interface:
* http://grobmeier.de/commons-compress-draft-5.zip
I have improved a lot of things, based on the comments of Sandy (thanks
for that).
This draft is not perfect, as you can see in the todo list. But imho we
have a quite good base for future work, everything compiles and works
and is documented. So i would like to propose that someone is comitting
this, except you have reasons not to do this.
If you agree with me, i will open a bugzilla issue and add the link to
the code.
- - Chris.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEVKMikv8rKBUE/T4RAlxxAKCMYzova2roWDA/skRyoDvFcErE2gCfTjFw
bT2VrGdR8Byt+VjsRo7Cyhw=
=1GRF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
package org.apache.commons.compress;
import java.io.*;
import java.util.Iterator;
/**
* Archiver is an interface that defines a generic achive file. This interface
* allows a caller to inspect the entries in an archive, create new ones, add
entries to existing ones
* or to expand an archive.
*
*
* @author christian.grobmeier
*/
public interface MyArchiver {
/**
* If pack is called with this as the ioverwrite/i parameter, the method
* will fail if the ArchiveFile exists.
*/
public static final int FAIL_ON_EXISTANCE = 0;
/**
* If pack is called with this as the ioverwrite/i parameter, the method
* will overwrite ArchiveFile. The new archive will only contain the
entries
* added via iaddEntry/i.
*/
public
Re: Contributing Code
Yeah. Probably should have documented a little more to start off with. I sent it off early because I wanted to see if folks were interested in the functionality first. I wrote up a bunch of JavaDoc for some of the bigger classes. It's not perfect, but hopefully it will make it much easier to figure out what's going on. JavaDoc: http://sandbox.sourcelabs.com/willpugh/myzip-1/docs/apidocs/ Src Drop (old one + new Javadoc comments): http://sandbox.sourcelabs.com/willpugh/myzip-1/myzip-1-src.zip To answer your more specific questions: If you create a com.sourcelabs.zipper.zip.ModifiableZipFile, there are a number of new entries. AddEntry -- Adds a new entry (fails if one by the same name is already there) ModifyEntry -- Modifies an existing entry (fails if one is not there) AddOrModifyEntry -- Adds entry if one is not there, and modifies if one is there RemoveEntry -- Removes an entry You can use these to build up a list of the changes to make. Then you call ApplyChanges to actually apply the changes to the zip file. We do modify the file in place. The method we currently use is to: 1) First get rid of the removed and modified entries and compact the unchanged ones. 2) Go through all the modified and added entries and write them to the file 3) Write out the index. Initial glance makes it seem easy to apply the Archiver interface to my classes. I'll see if I can get an implementation over the next few days. --Will C. Grobmeier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd love to see your code, although I don't think we should merge until we get the code contributed. It looks like contributing code gets a bit harder when there are more than one person involved in writing it. It's easily possible to merge if you would implement the Archiver-Interface. You could just head off the older zip implementation and drop yours in. Please use: http://www.grobmeier.de/commons-compress-draft-4.zip But please notice, i have to do a lot of changes suggested by Sandy McArthur. Its under heavy construction. My factory is being updated next days. Further it was very difficult to easily browse your code, cause it's not documented. Can you tell me how you delete a file from the zip? Do you manipulate the bytes directly? cheers chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETLZmkv8rKBUE/T4RAq7qAJ4gKdfdsqRPxUwSN4BOdx8q/Yjl+gCffoe0 tTBfkfbqMd1wMpltMZrCUdg= =l/d6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
I think the appropriate processes for getting contributed code are the ones outlined: http://incubator.apache.org/ip-clearance/index.html Using some of the forms linked to from: http://www.apache.org/licenses/#grants This process is predicated on there being a community for the code to go to. For the ip-clearance section, I need to get a member to manage the contribution. I thought this contribution made sense to go into commons. Do folks agree? If so, I'll be more than happy to go through the ip-clearance process, but I need a member to volunteer for managing the donation, and a place for it to go. I thought it made sense to go into compress, but I think that depends on how close compress is to releasing. As I mentioned before, this code has a number of things to finish before it's ready for primetime. I would estimate that I could get this ready in about a month. If this is too risky for compress, I would offer that we could start a new branch for the next version. Does this make sense? --Will James Carman wrote: Be careful when putting code from an outside source into the ASF code base. You might want to check with the incubator folks (I cc'ed them on this message) about this. I would think that any code that is donated would need to have the appropriate accompanying forms filled out, even if it is just donated to an existing project. -Original Message- From: C. Grobmeier [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 8:16 AM To: Jakarta Commons Developers List Subject: Re: Contributing Code -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am interested in contributing code to commons. I wrote a ModifiableZip class, that basically implements all the methods on ZipFile, but provides new methods for adding, removing and modifying entries in an existing zip file. The basics work, but it is still a bit rough around the edges. I need to do a bit more work on 1) Getting the proper apis 2) Changing package names + general refactoring 3) Making sure there is less duplication between what I have and what is implemented in compress (there are common elements in org.apache.commons.compress.ZipOutputStream that I feel we could share) 4) Filling in some of the smaller bits like file attributes, etc. 5) There are some other known bugs I thought it made sense to contribute this now, and apply patches, since I figured this could be useful to the VFS folks, and thought it might be able to go into Compress, in which case being able to get feedback and requirements from the communities earlier (rather than later) will be useful. this is great. I am doing work on compress at the moment, if you like i send you the current code via email (i am not a comitter too). I will check out your code and will try to put it into my current implementation. It would be great if we could do this stuff together. The zip file is http://sandbox.sourcelabs.com/willpugh/myzip_contribution.zip I'm not an Apache committer. Should this be going through the incubator first? IMHO not- it's just a enhancement to a allready incubatet codebase. But i am not an expert on this stuff, so somebody please correct me if i am writing bullshit. Cheers, Chris. Thanks, --Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESMznkv8rKBUE/T4RAtmsAJ4kmHTv/9CjPT9/TtN9RwPHEmjSwwCeKxkE heEsaUZ6fSqVTr5su6yUsDk= =JBUM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributing Code
Cool. I'd love to see your code, although I don't think we should merge until we get the code contributed. It looks like contributing code gets a bit harder when there are more than one person involved in writing it. --Will C. Grobmeier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am interested in contributing code to commons. I wrote a ModifiableZip class, that basically implements all the methods on ZipFile, but provides new methods for adding, removing and modifying entries in an existing zip file. The basics work, but it is still a bit rough around the edges. I need to do a bit more work on 1) Getting the proper apis 2) Changing package names + general refactoring 3) Making sure there is less duplication between what I have and what is implemented in compress (there are common elements in org.apache.commons.compress.ZipOutputStream that I feel we could share) 4) Filling in some of the smaller bits like file attributes, etc. 5) There are some other known bugs I thought it made sense to contribute this now, and apply patches, since I figured this could be useful to the VFS folks, and thought it might be able to go into Compress, in which case being able to get feedback and requirements from the communities earlier (rather than later) will be useful. this is great. I am doing work on compress at the moment, if you like i send you the current code via email (i am not a comitter too). I will check out your code and will try to put it into my current implementation. It would be great if we could do this stuff together. The zip file is http://sandbox.sourcelabs.com/willpugh/myzip_contribution.zip I'm not an Apache committer. Should this be going through the incubator first? IMHO not- it's just a enhancement to a allready incubatet codebase. But i am not an expert on this stuff, so somebody please correct me if i am writing bullshit. Cheers, Chris. Thanks, --Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Christian Grobmeier Possessed Management Hurlacher Str. 5 - 86853 Langerringen - Germany E-Mail: [EMAIL PROTECTED] Mobil: +(49)(0)175 57 66830 Fax: +(49) (0)8232 959119 Web: http://www.possessed.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESMznkv8rKBUE/T4RAtmsAJ4kmHTv/9CjPT9/TtN9RwPHEmjSwwCeKxkE heEsaUZ6fSqVTr5su6yUsDk= =JBUM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Contributing Code
Hi All, I am interested in contributing code to commons. I wrote a ModifiableZip class, that basically implements all the methods on ZipFile, but provides new methods for adding, removing and modifying entries in an existing zip file. The basics work, but it is still a bit rough around the edges. I need to do a bit more work on 1) Getting the proper apis 2) Changing package names + general refactoring 3) Making sure there is less duplication between what I have and what is implemented in compress (there are common elements in org.apache.commons.compress.ZipOutputStream that I feel we could share) 4) Filling in some of the smaller bits like file attributes, etc. 5) There are some other known bugs I thought it made sense to contribute this now, and apply patches, since I figured this could be useful to the VFS folks, and thought it might be able to go into Compress, in which case being able to get feedback and requirements from the communities earlier (rather than later) will be useful. The zip file is http://sandbox.sourcelabs.com/willpugh/myzip_contribution.zip I'm not an Apache committer. Should this be going through the incubator first? Thanks, --Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Build fails under Maven 1.1-beta2
Hi all, Under maven 1-1.-beta2 there seems to be an issue with the maven- tasks-plugin. I upgraded to 1.2.0 from 1.1.0 to see if that resolved it, but no joy. I actually think the issue is in the project.xml of the tasks plugin. At any rate, if I comment it out, everything is fine. Also, since we are at RC stage, can I bump the versions of the maven- tasks-plugin and maven-findbugs-plugin (should be 1.0!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] findbugs and JDK1.3
One more thing... I noticed that findbugs is commented out: !-- Commented out, does not run on JDK 1.3 reportmaven-findbugs-plugin/report -- According to the homepage for Findbugs, while yes, it does require JDK1.4 to run, it should analyze 1.3 code. When we compile for 1.3, does that mean you are using a 1.3 JDK as well? RC is looking good, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37363] - [email] Address char-set can not be individuallyset
James, We should keep this discussion on the commons-dev email list, I'll cc it there. I would love to take a patch file for you, and if you haven't worked with Open Source before and Apache specifically I can help you. In terms of getting the changes in, well we are ALL apache developers! In order to submit a patch, all you have to do is check out the source, make the change, write a unit test, and then create a patch file. I find Eclipse and Maven make this very very easy. I suggest you read http://www.apache.org/foundation/how-it-works.html for more about Apache Foundation and how you can become involved. Eric On Nov 30, 2005, at 10:44 PM, James Huang wrote: Well, my use case is simpler but I know for sure it is happening in real word: the encoding of email addresses is different from that of the whole message. This happens to some Japanese mail systems, as I was told. To cope with my use case, the fix is extremely easy: in the org.apache.commons.mail.Email class, just add a few more methods to take javax.mail.internet.InternetAddress as parameter. Afterall, I believe InternetAddress is used internally anyway. I don't want to go through the hassle of creating accounts, etc., in order to submit patches, and just hoping some apache mail developer will make this easy fix. Your scenario is interesting but different; I'd imaging you'll have to change the encoding for the message body itself in order to send to different recipients (expecting specific encoding)? Cheers, -James From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 37363] -[email] Address char-set can not be individually set Date: Tue, 29 Nov 2005 15:36:57 +0100 (CET) DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37363. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37363 --- Additional Comments From [EMAIL PROTECTED] 2005-11-29 15:36 --- Would you like to submit a patch and a unit test? Basically, what this allows you to do is send a single email to multiple recipients, and each recipient gets their own charset for their email? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi? tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Schaible
A very enthusiastic +1, it is about time! On Sep 25, 2005, at 4:40 PM, Phil Steitz wrote: I would like to nominate Jörg Schaible as an Apache Jakarta Commons Committer. Jörg has provided patches to [configuration], [id] and [i18n] and has contributed to discussion on commons-dev for over a year now. He is interested in contributing to [lang] and [io], as well as helping to get [id] graduated from the sandbox and released. I think he would make a valuable addition to the commons committers. Votes please, closing Wednesday 28 September, Miidnight GMT. Phil -- -- [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][restarted] Release Commons Email 1.0
Get my +1 in the email record. [X ] +1 Release Email 1.0 based on RC8 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive (We want to see RC9, RC10, and R11 first!) [ ] -1 Do not release Email 1.0 based on RC8 Cheers, Eric Pugh On Sep 1, 2005, at 8:05 AM, Eric Pugh wrote: -- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][RESULT] Release Commons Email 1.0
It looks like Commons Email 1.0 based on Henning's RC8 is go for launch! The following people voted +1 for the release: Dion Gillard +1 Stephen Colebourne +1 Henning Schmiedehausen +1 Eric Pugh +1 The following people voted +0 for the release: robert burrel donkin +0 phil steitz +0 There were no -1. Henning has generously volunteered to be the release manager, and has dealt with some of the comments raised by the +0 committers. Eric Pugh On Sep 19, 2005, at 2:13 AM, Henning P. Schmiedehausen wrote: Phil Steitz [EMAIL PROTECTED] writes: Agree with Robert's comments and am also +0, with three additional comments= : * The ant build depends javamail 1.3.2, while the maven POM references 1.3.= 3.=20 The ant build should be updated to match the POM Ok, will do. * It would be good to provide some instructions in the README, release note= s=20 or web site on what users have to do to get javamail and activation manuall= y=20 deployed locally so the maven and ant builds work. There is some information on how to get javamail and activation in RELEASE-NOTES.txt. If more information is wanted, patches are always welcome. * Before cutting the final release, you should update the index.xml page to= =20 eliminate the reference to RCs Yes. The release will be based on RC8, not RC8 as 1.0. I will have to change the references from RC8 to 1.0 anyway. Currently, I'm waiting for Eric to call the vote to close and post a result. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][restarted] Release Commons Email 1.0
I would like to restart the vote for Commons Email 1.0 based on RC8. The various packaging/dependency issues have been resolved, and Commons Email is working great on WebLogic. While this voting process has dragged on, it has also led to a lot of polish being added, and reducing the chance of a 1.0.1 coming out in a week! [ ] +1 Release Email 1.0 based on RC8 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive (We want to see RC9, RC10, and R11 first!) [ ] -1 Do not release Email 1.0 based on RC8 Cheers, Eric Pugh On Sep 1, 2005, at 8:05 AM, Eric Pugh wrote: -- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
-- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][email] commons-email release candidate 6 available
Mac OS X 10.4 and I assume US locale. However, I have to downgrade
my dumbster to 1.5, so I could imagine weirdness. I am okay with
things as long as it works for you.
I'll call the vote now.
Eric Pugh
On Aug 31, 2005, at 4:46 AM, Henning P. Schmiedehausen wrote:
Eric Pugh [EMAIL PROTECTED] writes:
So now there are no outstanding bugs left. However, after I applied
the patchs, I reran my tests using a maven clean first, and now am
having some unit test failures.
It seems like attaching a bad url doesn't actually cause any
failures Can someone else confirm this issue?
The unit tests work fine for me with both en_US and en_US.UTF-8
locale. What platform, what locale did you try?
Regards
Henning
Eric
On Aug 30, 2005, at 8:22 AM, Henning P. Schmiedehausen wrote:
BodyPart primary = getPrimaryBodyPart();
if ((primary instanceof MimePart) StringUtils.isNotEmpty
(charset)) {
((MimePart) primary).setText(msg, charset);
} else {
primary.setText(msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero
for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Email 1.0
Since commons-email RC 1 there have been quite a few new release candidates. At this point ALL the bugs in Bugzilla have been dealt with. The code has been tagged as EMAIL_1_0_RC7 and differs from RC6 in some doc/code cleanup and minor refactoring. The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] September archive of components
commons-xo was used in Turbine 3 and 2. For Turbine 2, we have implemented something else, and Turbine 3 is dormant, so I think from Turbine land I can give a +1. Eric On Aug 28, 2005, at 7:50 PM, Henri Yandell wrote: Here's the list to archive in September, on September 3rd (next Saturday): cache clazz codec-multipart convert events filters functor graph2 http jex jjar jpath jux mapper messenger periodicity reflect rupert scaffold services simplestore tbm test threading threadpool workflow xmlio xmlunit xo Any -1's to the above? Special cases etc? There are some at 5 months inactivity. I'll hit them in a month or so. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][email] commons-email release candidate 6 available
Henning (and others), Do you think we are at a good enough point to call for 1.0? I am working on fixing the Gump metadata descriptor, which is currently broken due to findbugs, but that shouldn't affect our 1.0. Eric On Aug 25, 2005, at 4:19 AM, Henning P. Schmiedehausen wrote: Eric Pugh [EMAIL PROTECTED] writes: the sixth release candidate for commons email is now available for download from http://people.apache.org/~epugh/commons-email/. I tagged rc6 to tags/EMAIL_1_0_RC6 and moved the trunk to rc7-dev. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][email] commons-email release candidate 6 available
I looked through, and the fix you suggested was quite
straightforward.. Don't know why I didn't think of it myself! Doh!
So now there are no outstanding bugs left. However, after I applied
the patchs, I reran my tests using a maven clean first, and now am
having some unit test failures.
It seems like attaching a bad url doesn't actually cause any
failures Can someone else confirm this issue?
Eric
On Aug 30, 2005, at 8:22 AM, Henning P. Schmiedehausen wrote:
BodyPart primary = getPrimaryBodyPart();
if ((primary instanceof MimePart) StringUtils.isNotEmpty
(charset)) {
((MimePart) primary).setText(msg, charset);
} else {
primary.setText(msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] another method signature change in 1.0-rc6
Yes, think we expected to do a couple fixes to Turbine once we hit 1.0... Eric On Aug 25, 2005, at 6:41 AM, Henning P. Schmiedehausen wrote: .../target/src/org/apache/turbine/util/velocity/ VelocityHtmlEmail.java:191: send() in org.apache.turbine.util.velocity.VelocityHtmlEmail cannot override send() in org.apache.commons.mail.Email; attempting to use incompatible return type found : void required: java.lang.String public void send() throws EmailException ^ .../target/src/org/apache/turbine/util/velocity/VelocityEmail.java: 242: send() in org.apache.turbine.util.velocity.VelocityEmail cannot override send() in org.apache.commons.mail.Email; attempting to use incompatible return type found : void required: java.lang.String public void send() throws EmailException ^ Note: Some input files use or override a deprecated API. Note: Recompile with -deprecation for details. 2 errors Those methods have returned void up to 1.0-rc5. Yet another Turbine breakage... ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Findbugs
Digging into it, I don't really get the setSendDate() being public
either. I lean towards it being private as well. Also, why can't
we return null? The logic in getSendDate() seems odd.. If you
haven't sent the email, then it should be null:
public Date getSentDate(){
return sentDate;
}
I am not sure about the toLowerCase().. The line you referenced
doesn't seem to deal with headers, but, if you want to make the
change, go ahead. and I'll be happy to post (and tag!) an RC7.
Cheers,
Eric
On Aug 25, 2005, at 6:38 AM, Henning P. Schmiedehausen wrote:
Hi,
I've added a findbugs task to the email build and it has a few things
to report. We might discuss a little bit whether it is worth to work
on this:
Email.java 911, 926: externally mutable object
This is correct. The date object could be changed after it was put
into the Email object. Personally I consider this a minor
issue. Change would be
public void setSentDate(Date date) {
this.sentDate = (date == null) ? new Date() : new Date
(date.getTime());
}
public Date getSentDate() {
if (this.sentDate == null) {
return new Date();
else
return new Date(this.sentDate.getTime());
}
(IMHO, sentDate should be private, not protected. Then you could omit
the test in the getSentDate method)
Email.java 286: dubious String.toLowerCase()
Correct, too. As Mail headers are defined as US-ASCII (according to
RFC 2822, 2.1 General Description), we could use explicit US-ASCII
coding.
Email.java: Field not initialized in constructor:
org.apache.commons.mail.Email.session
Hm. We have lots of these. Why does Findbugs nag about that one?
Email.java 426
MultiPartEmail 295
HtmlEmail 195 catches Exception, but Exception is not thrown in
the
try block and RuntimeException is not explicitly
caught
False positives IMHO. There are a few Exceptions inside these blocks
that derive from Exception.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero
for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general][exec] Exec needs a BugZilla component!
While the [email] component is perfectly happy to host [exec] bugs in CVS as we are just a couple letters off, it may be confusing to people! http://issues.apache.org/bugzilla/show_bug.cgi?id=36314 Who has the karma to create component? If someone wants to grant it to me, I'll be happy to make the change.. I wasn't sure the bugzilla-admin address was for these types of items... Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general][exec] Exec needs a BugZilla component!
Thanks.. I have updated the component. On Aug 24, 2005, at 5:23 PM, Rahul Akolkar wrote: On 8/24/05, Eric Pugh [EMAIL PROTECTED] wrote: While the [email] component is perfectly happy to host [exec] bugs in CVS as we are just a couple letters off, it may be confusing to people! http://issues.apache.org/bugzilla/show_bug.cgi?id=36314 Who has the karma to create component? If someone wants to grant it to me, I'll be happy to make the change.. I wasn't sure the bugzilla-admin address was for these types of items... AFAICT, [exec] is fairly new, and in sandbox. There is a [Sandbox] entry in BZ for Commons, which is the one to use for [exec]. Though that doesn't help your problem of mistaken filings under [email], I'm not sure if anything can be done (just yet). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT][email] commons-email release candidate 6 available
the sixth release candidate for commons email is now available for download from http://people.apache.org/~epugh/commons-email/. The only change was a backwards compatible change to expose MimeMessage from Email class (http://issues.apache.org/bugzilla/ show_bug.cgi?id=35881). The only odd thing is that in the docs, the links to the project reports didn't show up.. If no one finds a show stopper, then Henning has graciously volunteered to be the release manager and perform the magic signing of the jars with his Apache key. - eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] status?
I've applied the one patch (35881) that was simple from Siegfried, and the other one I don't feel comfortable b/c it involves changing a signature (34056). I am going to tackle the RC now. Eric Pugh On Aug 22, 2005, at 4:53 PM, robert burrell donkin wrote: On Mon, 2005-08-22 at 19:40 +1000, Dion Gillard wrote: Unfortunately for me, my Dad's still in ICU in hospital, and I'm on limited email and 'spare' time. Sorry for the hassle. no hassle intended :) - robert On 8/22/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: robert burrell donkin [EMAIL PROTECTED] writes: where are we now on the 1.0 roadmap? what work's remaining before we can roll another candidate? I think that Dion wanted to look into the different exceptions thrown issue that hit Turbine. IMHO this is just a minor nit, though. There is also the issue of the two open bugzilla issues that some people want to roll in before 1.0 Personally, I'm +1 for a new RC, there was no activity in the last week or so, so the interest seems to have died down and I'd really like to see either an RC or a 1.0 relase soon. We can still tie up loose ends in 1.0.1 or 1.1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] status?
I will call for one as soon as RC6 has been out for a couple days.. Dying for a vote and a release.. This horse has been beaten for long enough! On Aug 24, 2005, at 5:59 PM, Dion Gillard wrote: Do you want to do an official vote? On 8/25/05, Eric Pugh [EMAIL PROTECTED] wrote: I've applied the one patch (35881) that was simple from Siegfried, and the other one I don't feel comfortable b/c it involves changing a signature (34056). I am going to tackle the RC now. Eric Pugh On Aug 22, 2005, at 4:53 PM, robert burrell donkin wrote: On Mon, 2005-08-22 at 19:40 +1000, Dion Gillard wrote: Unfortunately for me, my Dad's still in ICU in hospital, and I'm on limited email and 'spare' time. Sorry for the hassle. no hassle intended :) - robert On 8/22/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: robert burrell donkin [EMAIL PROTECTED] writes: where are we now on the 1.0 roadmap? what work's remaining before we can roll another candidate? I think that Dion wanted to look into the different exceptions thrown issue that hit Turbine. IMHO this is just a minor nit, though. There is also the issue of the two open bugzilla issues that some people want to roll in before 1.0 Personally, I'm +1 for a new RC, there was no activity in the last week or so, so the interest seems to have died down and I'd really like to see either an RC or a 1.0 relase soon. We can still tie up loose ends in 1.0.1 or 1.1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http:// www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: commons-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Update on bug list
Hi all, I checked out 34056 (http://issues.apache.org/bugzilla/show_bug.cgi? id=34056) and it doesn't seem bad. The one thing Henning highlighted: -getPrimaryBodyPart().setText(msg, charset); +//BROKEN! +//getPrimaryBodyPart().setText(msg, charset); +getPrimaryBodyPart().setText(msg); I don't see why this is broken... Seems to me like we add getPrimaryBodyPart().setText(msg,charset) as well... I also looked at 35881 (http://issues.apache.org/bugzilla/ show_bug.cgi?id=35881), and despite not being able to apply, the change doesn't seem bad either. I would like to see the 1.0 release be one we can rely on for a while, and the changes to faciliate subclassing/extension in 34056 and 35881, and then cutting RC6 seem like an okay path forward. Any opinions? I think at least 35881 can be applied, and if we get back the info on 34056 on the // BROKEN bit, then it could go in as well. Commons-email has taken this long, whats another week or two... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Jerome Lacoste wrote a proposal a couple months ago to the CruiseControl mailing list talking about the same basic idea. His proposal is here: http://www.coffeebreaks.org/blogs/?p=8. I will forward this thread to him as he might be very interested in contributing. At any rate, something like this in Jakarta Commons would be great, I know I am using at least three different implementations of the same basic functionality! Eric Pugh On Aug 1, 2005, at 7:04 PM, Kev Jackson wrote: This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox access
Most projects are very happy to have more interest! That is part of the reason they are in sandbox, is to build up a group of interested developers...! On May 17, 2005, at 8:01 PM, Craig McClanahan wrote: The convention in the sandbox (and in Commons Proper for that matter) are to coordinate with the developers (if any) working on the component you want to modify, and add yourself to the STATUS.html file that is there as well. Craig On 5/17/05, Torsten Curdt [EMAIL PROTECTED] wrote: Guys, I got access to the sandbox mainly for javaflow and jci. ...but would it be ok to commit code/fixes to other sandbox projects as well? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] was: Re: RESEND: RE: Load message resources from DB???
As a big user of Configuration, I've thought that it would be quite useful in many places. The flexibility it adds is really useful. Configuration isn't specifically locale aware, however, we have discussed adding a ConfigurationLocaleAware decorator that would handle that. The Scarab project has it's own logic that takes a Configuration and makes it locale aware for i18n purposes for example. Eric On Apr 7, 2005, at 12:10 PM, James Mitchell wrote: Like many of the Jakarta Commons projects, Commons Resources was based, in part, from the initial work done in Struts and later copied over to commons with the intent to one day use that library. This is what was done for Beanutils, Digester, Validator, and more I'm sure. (Craig, correct me if I am wrong here) MessageResources (the one in Struts) was created because ResourceBundle (java api) did not provide the required functionality (at the time it was needed). I have only had a cursory look at Configuration. From what I know of it, it is a reusable library for getting configuration data into your application (typically during startup). Commons Resources is a reusable library for retrieving properties pairs (locale aware) for your application. I do not know if Configuration is locale aware, but I suppose Commons Resources could be extended (or changed) to use Configuration. The database extensions I did for Resources are specific to Resources, but that can be changed if enough people think we should do that. I can see how Resources, I18N, and Configuration could play nice together in providing i18n'd messages and configuration data. Would there be any interest in such an animal? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Benedict, Paul C [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Thursday, April 07, 2005 9:59 AM Subject: RE: RESEND: RE: Load message resources from DB??? James, How much different is Common Resources from Common Configuration? In essence, a property file is really just a list of configuration pairs. Thanks, Paul -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 4:22 PM To: Struts Users Mailing List Subject: Re: RESEND: RE: Load message resources from DB??? - Original Message - From: Fogleson, Allen [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org; [EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 2:40 PM Subject: RE: RESEND: RE: Load message resources from DB??? Yes there is the OJBMessageResource class and I believe the same author wrote a HibernateMessageResource class. The class I wrote is mostly a JNDIJDBCMessageResource which has a timeout cache attached to it. The config is comprised of three elements (comma separated) 1) The JNDI Name of the datasource to use that maps to a table. 2) The sql to use basically this sql relies on the fact that variable 1 is the locale, and variable 2 is the key . 3) The time that the cached value previously retrieved from the DB is valid. If this is 0 timeout is never. The ones mentioned in Bill's book are very good implementations but I feel that it is sometimes nicer to have an implementation that does not add extra class libraries (i.e. OJB or Hibernate). If you are already using one of those in your app I would say then use those Message Resource extensions, but if you want something relatively simple that just uses standard J2EE and the struts libs then use mine. (I really should get it up on a site somewhere :) Hi, I wrote OJBMessageResources a while back and it has not been updated since it was last published. Struts will soon be changing (1.3.something) the internal mechanism from MessageResources/PropertyMessageResources (and factory) to commons-resources. That's why I wrote 3 implementations for commons-resources: HibernateResources IBatisResources JDBCResources (not in CVS yet) http://cvs.sourceforge.net/viewcvs.py/struts/commons-resources- optional/ These are not released (because commons-resources has not been released, but it is out of the sandbox, which is a good thing), but I will publish and announce the extensions when it get's the 1.0 stamp of approval. Al Thanks. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive,
RE: Moving benchmark out of sandbox?
I took a spin around benchmark, and it looked good however.. I think you need some sort of tutorial and demo. Unlike other tools like email,lang, which are very obvious how you use them (Answer: you write code with them!), benchmark is more of a tool. There were references to other tools that I didn't quite get, and maybe some sort of sample report would be good. Maybe run benchmark against the tomcat codebase or something. On a certain level, if my understanding is right that benchmark is a tool, not a library, I somewhat wonder if this shouldn't be out from under commons and part of some sort of jakarta project instead? Building community is tough from the sandbox. However, I have done it with Configuration, (which is really thriving), and to a certain extent with Email, although I need to get some of the contributors voted in as committers. When people express interest, grab 'em! Ask for feedback, take their concerns seriously, and pretty soon you'll be getting patches! Eric -Original Message- From: Kevin A. Burton [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 4:50 AM To: Jakarta Commons Developers List Subject: Re: Moving benchmark out of sandbox? Dion Gillard wrote: Using nightly builds? Thats a step in the right direction I guess ;) I'll setup nightly builds and then blog about the benchmark package and what you can do with it... then build really nice javadoc. I guess I'm getting ahead of myself because I want to integrate it within FeedParser :) Thanks! Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [email] promote RC4 to 1.0 status
Ugh. Cygwin. Fast way to frustration on windows.. Actually, I just got my new powerbook, so theoretically I can run MacPGP from http://macgpg.sf.net and do it. However, when I generate a new keypair, that means that I'll either have two keypairs, or I just don't use the first one anymore? I haven't signed anything else with it, and haven't cross signed it at all, so theorectically moving to a new keypair is fine, correct? Eric -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, March 14, 2005 6:51 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status The gpg docs are here http://www.gnupg.org/gph/en/manual.html and yes, you need to generate a keypair first before trying to sign something. I don't know if it is ok to gen and store keys on apache boxes, though. Anyone know? If you can get Cygwin or something equivalent that lets you run gpg and shell scripts locally, you can use the scripts that I added to /committers/releases to create and verify the sigs once you have created the keypair using gpg --gen-key hth, Phil On Mon, 14 Mar 2005 09:56:17 -, Eric Pugh [EMAIL PROTECTED] wrote: I was taking a swing at ascii armour'ing the signatures, and have a couple questions. Following the directions in http://wiki.apache.org/jakarta-commons/SigningReleases, there is a section about using gpg. I logged onto my Apache account, and tried to do the command: gpg --armor --export 'your name' However, nothing gets produced. What I am wondering is if I need to somehow install my key? I followed the PGPMail directions, so my private key is on my windows laptop. Do I need to create using gpg my main key instead? There are some tantalizing mentions in PGPMail's documentation about ascii armouring, but no details on how to do it, just that it exists. Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:01 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status hi eric could you ascii armour the signatures? (it's not essential but it makes them a lot nicer to read and download) - robert On Fri, 2005-03-11 at 20:30, Eric Pugh wrote: Hi all, A couple of packaging issues were discovered in Email 1.0 RC3. I was encouraged to fix them and then call for a fresh vote, so I appreciate the understanding of the community that the (now) 4 release candidates it's taken to get email to 1.0. My first time signing a project. The release candidate is available at http://www.apache.org/~epugh/email/distributions/ and is just RC3 with some packaging tweaks, not Java code changes. The documentation is available at http://www.apache.org/~epugh/email/docs This is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on Tuesday 15th of March. here's my +1 - Eric -8- [ ] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]Site update of howtos
Over in Turbine land we have the advantage of a separate turbine-site project. We have generic site doucmentation, and then the maven generated docs seperated by version: / generic site docs /2.3 /2.3.1 /2.4-M1 And so on. What we could do is have /commons/configuration/ - current site docs symlinked to /commons/configuration/1.0 /commons/configuration/1.1/ -- new site docs /commons/configuration/1.0/ -- old site docs And provide a link to the 1.1 and 1.0 from both projects Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 8:28 PM To: Jakarta Commons Developer List Subject: [configuration]Site update of howtos Our current site seems to be very confusing for our users as can be seen in multiple postings on the user list. The main reason is probably the user guide (the howtos), which describes the latest version in SVN rather than the 1.0 release, which is used by most users. I have now applied a quick and dirty fix for this situation: I manually uploaded the 1.0 howtos on the server. Then I created two index pages for the old and new howtos and linked to them in the main navigation bar, analogous as for the API docs. In the index page for the SVN howtos there is an explicit warning that this may not be compatible with the latest released version. This is of course only a temporary solution because it requires manual processing on the server. I don't know how we should deal with this problem. Would it make sense to store both the old and new howtos in the xdocs and let maven generate it all? I guess that would be the easiest way. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [email] promote RC4 to 1.0 status
I was taking a swing at ascii armour'ing the signatures, and have a couple questions. Following the directions in http://wiki.apache.org/jakarta-commons/SigningReleases, there is a section about using gpg. I logged onto my Apache account, and tried to do the command: gpg --armor --export 'your name' However, nothing gets produced. What I am wondering is if I need to somehow install my key? I followed the PGPMail directions, so my private key is on my windows laptop. Do I need to create using gpg my main key instead? There are some tantalizing mentions in PGPMail's documentation about ascii armouring, but no details on how to do it, just that it exists. Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:01 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status hi eric could you ascii armour the signatures? (it's not essential but it makes them a lot nicer to read and download) - robert On Fri, 2005-03-11 at 20:30, Eric Pugh wrote: Hi all, A couple of packaging issues were discovered in Email 1.0 RC3. I was encouraged to fix them and then call for a fresh vote, so I appreciate the understanding of the community that the (now) 4 release candidates it's taken to get email to 1.0. My first time signing a project. The release candidate is available at http://www.apache.org/~epugh/email/distributions/ and is just RC3 with some packaging tweaks, not Java code changes. The documentation is available at http://www.apache.org/~epugh/email/docs This is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on Tuesday 15th of March. here's my +1 - Eric -8- [ ] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN][configuration]Release candidate 1.1RC2
Thanks for the tip.. This also solved my last issues with packaging
email. (I hope :-) ).
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 8:00 PM
To: Jakarta Commons Developers List
Subject: Re: [ANN][configuration]Release candidate 1.1RC2
Oliver Heger wrote:
NOTICE.txt is missing from source and binary distros and jar.
Not sure about this. I used maven dist to build the distros. Do I have
to tweak the maven.xml so that this file gets included?
To get it into the jar, add it as a build resource in project.xml:
resources
resource
directory${basedir}/directory
includes
includeNOTICE.txt/include
/includes
targetPathMETA-INF/targetPath
/resource
/resources
To get it into the top-level directories, you need to tweak maven.xml.
Here is one way to do it:
preGoal name=dist:build-bin
copy todir=${maven.dist.bin.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
preGoal name=dist:build-src
copy todir=${maven.dist.src.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
hth,
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] [email] promote RC4 to 1.0 status
Hi all, A couple of packaging issues were discovered in Email 1.0 RC3. I was encouraged to fix them and then call for a fresh vote, so I appreciate the understanding of the community that the (now) 4 release candidates it's taken to get email to 1.0. My first time signing a project. The release candidate is available at http://www.apache.org/~epugh/email/distributions/ and is just RC3 with some packaging tweaks, not Java code changes. The documentation is available at http://www.apache.org/~epugh/email/docs This is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on Tuesday 15th of March. here's my +1 - Eric -8- [ ] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay...
I have fixed the NOTICE.txt in the jar at the top level not being in the
META-INF. However, I can't seem to get the NOTICE.txt in the top level
of either the src or binary distributions. The postGoal in commons
build here doesn't seem to run. No xdocs, no jars, no NOTICE.txt...:
postGoal name=dist:prepare-src-filesystem
j:set var=maven.dist.src.assembly.dir
value=${pom.getPluginContext('maven-dist-plugin').getVariable('maven.di
st.src.assembly.dir')} /
!-- Copy Files --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=.
ant:include name=NOTICE.txt/
/ant:fileset
/ant:copy
!-- Copy Jars --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=${maven.build.dir}
ant:include name=*.jar/
/ant:fileset
/ant:copy
!-- Copy XDocs --
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs /
/ant:copy
/postGoal
To what extent is the NOTICE.txt a mandatory requriement? TO me, it
looks just like the LICENSE.txt...
And, in the interests of finally getting a release out, especially since
we have the required +1 votes, can I just add the file by hand? Icky, I
know, but...
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
I am using 1.8.1. However, I just found out that the darn jars aren't
supposed to be on ibiblio. I checked on the maven mailing list and
found out it was a problem. Silly me for bringing it up.. So now I
need to rollback to the older version.
Does the 1.9-SNAPSHOT help this situation of non redistributable jars?
Eric
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:42 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
The only open bug/enhancement is 32900: http://issues.apache.org/bugzilla/show_bug.cgi?id=32900. It is quite clearly an enhancement that is post 1.0, and there is some discussion on the bug list of whether it fits into the commons-email charter. Eric Pugh -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 3:24 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release commons email 1.0 Are there any open bugs/enhancements? On Tue, 1 Mar 2005 09:01:03 -0800, Eric Pugh [EMAIL PROTECTED] wrote: My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Addition for DataUtils
I need the same logic.. Is it something you can share/ post to the
bugzilla?
Eric
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 11:43 AM
To: Commons Developer
Subject: [lang] Addition for DataUtils
Hello... I just had to whip up a function that might be useful...
The situation was that I needed to determine if the current time fell
within a given range. The complication is that the range could span a
day, i.e., the range might be 2000-0800 (24 hr. times).
So I threw together
static boolean isTimeInRange(int rangeStart, int rangeEnd, int
timeToCheck);
...the idea being that someone would do something like:
int now = 100 * new GregorianCalendar().get(Calendar.HOUR_OF_DAY);
if (isTimeInRange(800, 2000, now)) {
// in range
}
I'm wondering if that sounds like a good edition to DateUtils?
If so, I'll create some overloaded versions (to accept actual Calendars
and probably Strings in addition to ints, and mixtures of all three,
perhaps 12-hour times too), solidify and clean up the code, throw
together a unit test and post it to Bugzilla.
Any thoughts? Part of me expects to hear this already exists somewhere,
but I didn't find it in DateUtils, which strikes me as the logical
place. Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][configuration]Release 1.1
I'll take a loo at the latest as well, I need to update some dependencies anyway for Turbine! -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 12:09 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Strange! Okay, I would like to have a look at bug 33723 and maybe add a unit test that checks for absolute path names (to be sure). 33691 is open, too, but I think this has been more or less solved in the meantime. Here we could only modify the constructor of SubsetConfiguration that does not take a delimiter as argument to set the default delimiter. And we could prevent trailing dots in the prefix. I hope I come to these things tomorrow. Then it's time for the second RC! Oliver Emmanuel Bourg wrote: Emmanuel Bourg wrote: I haven't had a chance to test it yet, I should have some time this week. Ok I checked again my application with the latest nightly build and it worked fine. I don't know what happened the last time I updated my commons configuration jar... I'm +1 for a 1.1-rc2 release followed by a final 1.1 Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons email 1.0
Hi all, The commons-email RC3 release has been available for a couple days, and has isn't fundamentally changed from the RC2 release that has been out for a couple months. I'd like to move to releasing the code here: http://www.apache.org/~epugh/email/distributions/ as commons-email-1.0. Documentation is available at http://www.apache.org/~epugh/email/docs/. Assuming this vote passes, my plan is to rename the jars, and then deploy them, as well as tag the 1.0 based on the RC3 tag in SVN. [ ] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][configuration]Release 1.1
You didn't break fulcrum.. Fulcrum Configuration is built by Gump against the CVS head, so the API change between 1.0 and 1.1 of commons-configuration cause compile errors. The sooner we can get a release out, the better.. I'll try next week to see if I can help! Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 1:53 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Welcome back, Eric! We were trying to get a 1.1 release out, but this is halted now because of problems in the reloading area. In which way did we break Fulcrum? Oliver Eric Pugh wrote: Folks, I have been really tied up in real life since before Christmas, but life has started calming down. I'll be looking at getting reinvolved again in the commons projects that are near and dear to my heart! For what it's worth, I am very excited about getting another rev of configuration out. (that and gump has been complaining about Fulcrum Configuration and the new API!). Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 2:16 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 FWIW i've never regretted holding a release and i think the right decision's been made. - robert On Thu, 2005-02-10 at 19:43, Oliver Heger wrote: Of course, I don't want to force a release out which is not mature. Let's hold it. But I feel a bit disappointed that it seems to be so hard to get the required three +1s. I think we must be careful that we do not lose our momentum :-( Oliver Emmanuel Bourg wrote: I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inform. Oliver Heger Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren Klinikum der Philipps-Universität Marburg Baldingerstraße, D-35037 Marburg Tel: +49 6421 28-66923 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Release Candidate 3 posted!
Hi all, I have posted posted Release Candidate 3 of commons-email. The only code change from Release Candidate 2 was the change of some ArrayList to List in method signatures and some javadoc cleanup. It is tagged as EMAIL_1_0_RC3. I have attempted to go through the signing process, however, this is my first time, so please help me validate this! I'd like to get a consensus from the community on how long to leave RC3 up, and then call for a 1.0 vote based on the RC3 code. You can download and try out the distributions (and the signing stuff) here: http://www.apache.org/~epugh/email/distributions/ The documentation is available here: http://www.apache.org/~epugh/email/docs/ I'd like to get this to 1.0, as I've been sitting on the RC2 version for over two months (no good excuse why :-( ). Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
I have to jump into this as well. I hope I am not just repeating what wiser minds have already said :-). The idea of changing package names just seems like a solution that looks simple, but will rapidly become a nightmare. As far as I know, no other set of libraries follow this pattern, including the Java libraries, and I think this suggests that doing this isn't wise. And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Additionally, people will soon start writing tools similar to commons-logging that attempt to put a facade over all the versions so you don't have to know which version you are working with. I understand why it is a problem, but it seems like a better solution is to pressure app vendors to upgrade faster (by using tools like Gump that demonstrate the newer versions are solid against many packages) as well as implement classloader isolation. Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 19, 2004 5:28 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Do what I said already ... create subordinate class loaders *within* your application, and load the offending subordinate modules into their own class loaders, with their own dependencies. Oliver Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Cut timestamped version of configuration?
Hi all, I noticed that there is a directory (can't quite remember now) on the cvs.apache.org where timestamp/non official releases are put. This directory is NOT synced to ibiblio. I'd like to cut a timestamped version and put it there because I would like to add to Fulcrum configuration a dependency on it. Right now Fulcrum Configuration (a tool to load up a Configuration as an Avalon component) fails due to API differences in Gump: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-con figuration-impl/index.html The way to fix it is to either cut a release or publish a timestamped version that Fulcrum Configuration can depend on... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][EMAIL] Release Commons-Email 1.0
I checked a couple other of the mavenized projects, and they didn't seem to put NOTICE.txt in the distribution. Primarily because the primary distribution method seems to by just putting out a jar file and syncing that to ibiblio. Dion, I did try to get NOTICE.TXT in the dist, instead of putting it in the jar file in the distribution, but no luck. Is there something obvious I am missing? Eric -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 5:47 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][EMAIL] Release Commons-Email 1.0 Shouldn't NOTICE.TXT be in the distribution? On Fri, 3 Dec 2004 18:08:50 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][EMAIL] Release Commons-Email 1.0
I apologise for the delay, I had an unexpected trip to take. At this point I have updated the jar file in the distributions to have the NOTICE.txt, and renamed them commons-email-rc2. If Stephen changes his -1 to a +1 then I count 5 +1's and 2 +0's, and would like to move to an immediate release in 24 hours. Eric -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, December 04, 2004 4:51 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][EMAIL] Release Commons-Email 1.0 -1 Please add NOTICE.txt to all zip files and the jar file. Then you can have a +1 ;-) Stephen - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: Commons-Dev [EMAIL PROTECTED] Sent: Friday, December 03, 2004 5:08 PM Subject: [VOTE][EMAIL] Release Commons-Email 1.0 Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] getProperty vs getPropertyDirect
Per my other email, can we use a better name? maybe something like interpolateProperty? It doesn't have to be a JavaBean style getter since we don't expect it to be called by external tools.. -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 10:16 AM To: Jakarta Commons Developers List Subject: Re: [configuration] getProperty vs getPropertyDirect Sorry Olivier I should have waited a bit more before comiting the change :/ I have no problem reintroducing getPropertyDirect at a later time if you find an interesting use case. Emmanuel Bourg Oliver Heger wrote: After seeing the commit mails I may be a bit late. I had some ideas about extending the interpolation mechanism to support other data types than string, too. For this use case the separation of getProperty() and getPropertyDirect() would be nice, as getProperty() being a generic hook that allows for manipulation of properties (like interpolation) before they are delivered to the caller. But this was nothing concrete yet. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][EMAIL] Release Commons-Email 1.0
Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Matthew Inger as Commons Committer Re: [Lang] Commit Karma
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] getProperty vs getPropertyDirect
At one time we had all sorts of abstraction somewhere in there.. I think for example JNDIConfiguration supported removing properites by holding them in a temporary list of properties that had been removed. If getProperty() found that the list had a property with that name, then it returned null, otherwise it called getPropertyDirect which ACTUALLY returned the property. Icky, I know, and getting rid of it has my earnest +1! Just the similiarity of the names always seemed like a code smell to me. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Thursday, December 02, 2004 6:51 PM To: Jakarta Commons Developers List Subject: [configuration] getProperty vs getPropertyDirect Dumb question of the day : what's the usefulness of getPropertyDirect ? I cleaned a bit the code by removing the redundant getProperty implementation in CompositeConfiguration and JNDIConfiguration, now the only implementation left is in AbstractConfiguration and it delegates directly to getPropertyDirect. So at this point it seems getPropertyDirect is no longer necessary, I suggest merging it into getProperty. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] InvokerClosure
Is the final result:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
String.class, key));
Compared to the original really that much cleaner?:
for (Iterator i = configList.iterator(); i.hasNext();)
{
Configuration config = (Configuration) i.next();
config.clearProperty(key);
}
Things like this are cool.. But.. within the context of java, they just
seem more difficult to read.. Requiring the user to know what an
InvokerClosure is and does. It's neat.. I just haven't seen the use case
that requires it...
Eric
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 02, 2004 6:17 PM
To: Jakarta Commons Developers List
Subject: [collections] InvokerClosure
Hi all, I decided to play a bit with closures today and tried replacing
a trivial loop in [configuration] :
for (Iterator i = configList.iterator(); i.hasNext();)
{
Configuration config = (Configuration) i.next();
config.clearProperty(key);
}
I thought a closure would help reducing the code, but actually I ended
with something much longer :
CollectionUtils.forAllDo(configList, new TransformerClosure(new
InvokerTransformer(clearProperty, new Class[] { String.class }, new
Object[] { key })));
Then I found the invokerClosure method in ClosureUtils, the code turned
into :
CollectionUtils.forAllDo(configList,
ClosureUtils.invokerClosure(clearProperty, new Class[] { String.class
}, new Object[] { key }));
Slightly better but still quite long. Why is there no InvokerClosure
class ? This is the only closure in ClosureUtils that has no
corresponding class, this could make the code a bit shorter:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
new Class[] { String.class }, new Object[] { key }));
Also the Class[] and Object[] are quite cumbersome, that would be nice
to add methods/constructors to invoke simple methods with only one or
two parameters. Thus my example could look like this:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
String.class, key));
which is much more readable.
What do you think ?
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
ByteArrayDataSource needs a test or two.. Aside from that, maybe check over
the docs and the javadocs. I am thinking we do an RC on thursday, give it a
week, and roll next week?
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 30, 2004 1:38 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
What needs to be done for 1.0 then? Give me a list and i'll put some
time aside to pitch in.
On Tue, 30 Nov 2004 20:35:48 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
Definately something we should add to our discussion list once 1.0 is
out of the way.
-Corey
On Tue, 30 Nov 2004 10:32:28 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I'll put the exception tests in with the the others, when its all in.
I left most the tests untouched anyhow just testing for EmailException
rather than MessagingException. Once EmailException is in the head
version I'll start thinking about AddressException.
Has the issue of bulk mailing comeup before? I'm thinking of a class
that extends thread and then sends a email report to a specified email
address reporting which have been sent and those that haven't. Does
this fall within the scope of commons email? Email could even extend
thread and then just use the run method when needing to mail to lots
of folk.. This would be handy for webapps where the time it takes to
send mail exceeds the time for the request-reponse cycle.
HtmlEmail email = ..
..
email.batchMail();
public void batchMail() {
this.run();
}
public void run() {
try {
send();
} catch (SomeExceptionn e) {
}
}
Or would something else be a better idea? Perhaps a separate class
EmailSender or something?
Mark
On Tue, 30 Nov 2004 11:38:30 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
Sounds good to me, I have a stack of things waiting for the
next version.
Also I think most of the bugs have been cleared off by your recent
commits so there shouldnt be any reason to stop us from a RC1
-Corey
On Mon, 29 Nov 2004 19:01:00 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
I've applied a stack of changes, including Mark's
EmailException, to the
codebase. I don't really care much about how the unit
tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and
my gut feeling is
that we should look to final testing, cut a Release
Candidate and then roll
1.0. We should also start thinking about what the next
version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch
with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected
exceptions should
just get thrown and that exceptions should be tested
independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one
happens then
surely just throw it, the fact that its unexpected will
be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so
elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh
HtmlEmailTest class
or is this becomes too big and you want to separate
the exceptions,
then there should be two classes HtmlEmailTest (for
normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw
Exception.
It reduces
the length of each test, especially when all you
are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an
exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething
RE: cvs commit: jakarta-commons/chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java ServletApplicationScopeMap.java ServletHeaderValuesMap.java ServletRequestScopeMap.java ServletSessionScopeMap.java
I'd guess that the JSF jar's are not distributable on IBiblio, just like the JavaMail ones? ERic -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:00 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-commons/chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java ServletApplicationScopeMap.java ServletHeaderValuesMap.java ServletRequestScopeMap.java ServletSessionScopeMap.java On Tue, 30 Nov 2004 00:06:52 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: -1 Besides the fact that this change bundle breaks the ant clean dist command that is necessary for the current ngihtly build scripts to work I don't believe that's why the build broke. The problem is that, for some reason, the JSF jar files have disappeared from ibiblio. I don't know how to fix that. , it alters the semantics with changes like this: How does it change the semantics? All of 'public', 'static' and 'final' are redundant here, because this is an interface. -- Martin Cooper Index: Catalog.java === RCS file: /home/cvs/jakarta-commons/chain/src/java/org/apache/commons/chain/ Catalog.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Catalog.java 25 Feb 2004 00:01:07 - 1.6 +++ Catalog.java 30 Nov 2004 05:52:22 - 1.7 @@ -37,7 +37,7 @@ * pA default context attribute for storing a default [EMAIL PROTECTED] Catalog}, * provided as a convenience only./p */ -public static final String CATALOG_KEY = org.apache.commons.chain.CATALOG; +String CATALOG_KEY = org.apache.commons.chain.CATALOG; /** Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cleanup questions from importing email
Craig, Joe Germuska (details below) was a sandbox committer for email: developer nameJoe Germuska/name idgermuska/id email[EMAIL PROTECTED]/email /developer Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction][resources] Gump Build Fixed
Hi guys, I move the gump project file from jakarta-commons-sandbox.xml to jakarta-commons.xml. You should be notified of a success/failure later today. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
Humm... I typically make all my unit tests throw Exception. It reduces
the length of each test, especially when all you are doing is logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are testing, because
when someone adds a new method to the class, it will encourage them to add
the corresponding test case for any exeption. Or, put the exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the
InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for
a package that
simplifies the JavaMail api. And one of the big
simplifing aspects is that
the Exceptions that they have to catch are minimized.
Most users will
probably not care *what* the exception was, only that
there *was* an
exception, and just pass it up the chain. For folks who
actually have code
to deal with the specific exception, then they are either
going to use the
JavaMail api directly without the extra layer of [email],
or we should
provide a way for them to retrieve the specific Exception.
Hence that is why I propose that we have two types of exceptions:
EmailException and RuntimeEmailException. For common
exceptions, we throw
an EmailException which is an extension of
NestableException and wraps
whatever the underlying JavaMail exception was. This
provides a nice facade
for people who don't care what the exception was, but
allows folks who do to
get the underlying exception.
The other RuntimeEmailException will extend
NestableRuntimeException and can
be used for any runtime exceptions in the same manner as
EmailException.
For the case of the UEE, that would be another exception
in the API to
throw, which goes against the charter that:
contains a set of Java classes providing a thin
convenience layer over
JavaMail. So, in that case, throw the approapriate
EmailException and
that will wrap the UEE.
Mark, is it possible to use the 1.4 io stuff
conditionally? I guess not,
but we could think about
RE: [email] site cleanup
Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
I've applied a stack of changes, including Mark's EmailException, to the
codebase. I don't really care much about how the unit tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and my gut feeling is
that we should look to final testing, cut a Release Candidate and then roll
1.0. We should also start thinking about what the next version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected exceptions should
just get thrown and that exceptions should be tested independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one happens then
surely just throw it, the fact that its unexpected will be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception.
It reduces
the length of each test, especially when all you are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually
asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the
only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class,
especially for
the larger files. I know most of the tests I wrote, but
I think that
if anything the files are too long and would be much more
usable if
they were shorter and more focused. Does anyone have any
objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a
ExceptionTestCase
what's the likelyhood of this being patched? This isn't
a question of
style its a question of maintainabilty and now, I'm
faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to
use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk
RE: [email] site cleanup
Okay, done.. I tried ls -l email and couldn't get it, I got every directory, but I think I did it correctly. Thanks for the handholding. -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 8:24 PM To: Jakarta Commons Developers List Subject: Re: [email] site cleanup You'll need to change the `email` directory as well drwxr-xr-x 8 epughjakarta 1024 Nov 25 04:21 email thnx again, Mark Eric Pugh wrote: Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] rm -r lib/*.jar
I did some fixes to the Maven Ant plugin to deal better with overrides. I'll take what you sort out in build.xml and then see if I can support it in the Maven Ant plugin. As long as Email is built primarily by Maven, we will always have problems keeping the Ant script up to date without automation (or lots of attention to detail!). Thanks for the assist.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 8:05 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [email] rm -r lib/*.jar We appreciate all the help we can get :-) -Corey On Fri, 26 Nov 2004 11:35:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. If the Ant script had properties to define the source URLs for these two JARs, I could point them at my local copies. The license on the JARs in question allows them to be distributed as *part* of a larger package, so my building my own copy into the nightlies is fine ... the license also says you cannot make them available *separately*, which is why having them in CVS doesn't work. Would you guys mind if I hand patched the build.xml file to see if I can get that to work? Eric Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] rm -r lib/*.jar
It's fine. Can you also do the same trick in jakarta-commons-sandbox/email/libs as well? As I sent in my email to the PMC, I thought the reason those jars are not on ibiblio is that you can't redistribute them via a website. But having them in CVS would be akin to having them in a war file, correct? You can crack open a war file and download the jar the same way you can can go into CVS and checkout just that jar. But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. Eric -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:47 PM To: Jakarta Commons Developers List Subject: [email] rm -r lib/*.jar Apologies for treading on people's toes here, but I wanted to get the problem solved quickly, even if it causes a bad build etc. Making sure we're good licence-wise is crucial. Craig raised the issue on the PMC list that the email component had the activation.jar and the javamail.jar in the cvs repository. We're allowed to ship them in distributions, but not to offer them separately (correct me if that's wrong somebody?). Having them in CVS is effectively offering them separately. I've rm-r'd them on the cvs server and modified the build.xml to do the same thing the project.xml does; attempt to grab them from ibiblio and fail. I used rm -r as opposed to cvs remove as they'd still be available with cvs remove. Sorry for not just waiting for the main email committers to read Craig's email from this morning. Given the time of year I'd hate for it to turn out that the 2 or 3 people most likely to fix it are in the US and out late at thanksgiving dinners. Feel free to flame :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Updating the Commons common web site
This looks better, more consistent! -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 5:16 PM To: Jakarta Commons Developers List Subject: Re: [general] Updating the Commons common web site I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Chain 1.0
While I didn't use the approach that Mailreader-chain used, I found it very *key* to selling me on Chain. So make sure the docs all point to the example in struts-sandbox. Eric -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:59 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0 Does the head include the apps subdirectory? I just checked-in the Mailreader-Chain application to the Struts sandbox, since we'll be using Chain there soon. We could delete MailReader before the 1.0.0 release, but I don't want to do anything to spoil the vote. The other application, Agility, is just a stub at this point. The end-game here would be to show using Chain from a plain-vanilla servlet application. -Ted. On Sun, 21 Nov 2004 15:01:02 -0800 (PST), Martin Cooper wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons - -- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email][gump] Currently email is failing in gump
Okay, the change was made. Can you possible remove the older dumbster.jar file as an installed package? Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:23 AM To: [EMAIL PROTECTED] Subject: Re: [email][gump] Currently email is failing in gump On Wed, 24 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I'll take a look at trying to get dumbster to build in gump from source. When Stefano installed dumbster on brutus he did so because the source was not available from a public repository. I think he already had the dependencies and Ant invocations correct (just no source tree), just look through older revisions of the dumbster.xml file. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.java N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cleanup questions from importing email
Hi all, A couple questions about updating the site... 1) Is updating the main commons site automated or not? 2) in jakarta-commons/BUILD_DOCS.txt are some instructions, but they appear to be just to build the main page, correct? I think, but am not sure, that they are out of date, and have been replaced with just running maven site from commons-build? 3) The ASF logo on the top left of the commons site seems to have gone missing, this is an error right? 4) Once I generate the site into /jakarta-commons/commons-build/target/docs then I need to copy the content to jakarta-commons/docs and commit it. What about though the extra files generated by maven that aren't in jakarta-commons/docs. Should they just come over as well. 5) Should the maven site goal copy the new content for you into jakarta-commons/docs? 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. I'll update the wiki based on the feedback I get. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
Possibly.. I just followed the directions in the wiki. I also didn't manage to import properly the /src/test tree and the /xdocs/ tree as well. Not sure why. The cvs-log should still be in the jakarta-commons-sandbox project, correct? Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:22 PM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-commons/email - Imported sources cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.jav a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug report normalization
Adding more documentation would be nice for how to submit bugs. There are lots of unenforced rules in commons, like putting the component name in emails. While there are other ways that Emmanuel could have solved the problem, at least now it is resolved. And as we can see by the number of who manages bugzilla that the ideas for changing templates etc will probably remain just that, ideas. While I was surprised by the 300 plus emails, I appreciate Emmanuel going in and trying to clean up/ organize the bug tracker. For me, it really highlighted how MANY bugs we have. It seems like while we are supposed to take a collective ownership role over the various components, it seems like we don't. It looks, just judging by the number of open bugs, that quite a few components have lost their champions. Would this be a good time, now that quite a few components have been promoted etc, to try and do some cleaning of house and fix the bugs? Maybe have each committer take a couple of issues and try and get them to a closed status. Either via won't fix or fixing them? Maybe make next week Bug Week and someone (maybe me) could send out daily stats on how we are doing? Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 6:03 PM To: Jakarta Commons Developers List Subject: Re: Bug report normalization Martin Cooper wrote: I'm sure this has done wonders for the utility of the mailing list archives... I'm not trying to justify myself but the mail archives are already spammed by the CVS commits and the GUMP reports... Reading the archive is definitely not the best way to follow the discussions on the list for an external user. If you really had to do this, it would have been a much better idea to request that the mailer for Bugzilla changes was turned off while you did it. Good idea but this would have affected the other Apache projects using Bugzilla. Maybe deleting the assign to field for the jakarta commons bugs only before the changes and restoring it after would have worked. Who knows how many poor individuals have been spammed with off-list notifications just because they were kind enough to submit bug reports? Worse is the fact that these changes do nothing to solve the problem going forward. Most people will still submit bug reports without the component in the subject. The real solution would be to modify the template used for sending out the messages in the first place, so that the component name is included. Of course, if we do this now, the component name would be included in the subject twice... Good point, maybe we could update the jakarta bug page (http://jakarta.apache.org/site/bugs.html) or put a similar page at the jakarta-commons level explaining the prefered form for bug reports (component name in brackets, test case appreciated, etc...) Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email][gump] Currently email is failing in gump
This is precisely why the gump folks hate installing a packaged jar instead of building from CVS each jar. Gump has installed dumbster version 1.3, and we are now using 1.5, which has some API changes. (Typo's were fixed). We are NOT using the build-gump.xml, I'll remove it now prior to leaving sandbox. I'll take a look at trying to get dumbster to build in gump from source. If you get motivated, email me what you think the gump script should be.. lots of other SF.net hosted projects are built this way.. I won't get to it till tomarrow however.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 8:19 PM To: Jakarta Commons Developers List Subject: [email][gump] Currently email is failing in gump [email] is currently failing in gump, it complains about some dumbster methods. Now I took a look at it (read I havent a clue re: gump) and noticed that the build-gump.xml file is 2 years old. Does this mean its not in use? I run the maven gump goal and get a completely different output from this file. Conclusion, I am extremely confused and if anyone could point me in the right direction in regard to how to diagnose and fix the problem, I would greatly appreciate it. Also, I am not sure it is relevant or not, but the email gump build report says dumbster 1.5 and the gump report (common) says 1.3. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Chain 1.0
We had a similar discussion over in [configuration] prior to 1.0 over having the Configuration interface extend Map. It was great because you could do all sorts of cool tricks with passing configurations into things expecting Maps and still have the code work. Or, an existing application that dealt with a Map of configuration parameters would work seamlessly with the Map derived configuration. However, at the end of it, we felt like it ended up polluting Configuration, adding extra methods that didn't always map to the underlying implementation. So we ended up keeping Configuration the way it was and adding a MapConfiguration that did extend Map. Could a similar approach work for Context? Provide a standard Context and then a MapContext sub interface that exposes the Map interface? In my use of Chain I haven't had a situation where I needed the extra Map provided methods like keySet or entrySet. But, if I did, I could just cast to MapContext and then get them.. The other reason I wouldn't mind having Context NOT extend Map is that when I implement my own Context, I don't want user's directly putting and getting stuff into the context via the Map put and get methods. I want them to use my accessors ONLY. At any rate, I've been using Chain for a couple days now in my project, and am very happy to be replacing my own code with Chain! Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, November 22, 2004 10:14 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0 On Tue, 23 Nov 2004 09:37:27 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi Martin, On Mon, 2004-11-22 at 20:39, Martin Cooper wrote: This sounds like an enhancement request to me. Are you really suggesting that Chain should not be released until your specific enhancement is endorsed and incorporated into the component? I'm afraid I, for one, can't sign up for that. I think Matt's comment was entirely reasonable. The whole point of a 1.0 release is to freeze the API. If the API isn't right, then people certainly should speak up *before* the API freeze. You're right, of course. Of course it is better to speak up well before then if possible, but a release proposal is bound to prompt people to get around to voicing that concern they have had kicking around in the back of their mind for a while. Anyone raising the prospect of a release should be expecting this sort of thing. I was (over)reacting to exactly that. Chain was promoted out of the sandbox almost 6 months ago, so seeing such a fundamental change being proposed at this point was a bit like a bolt from the blue. Matt, I apologise for jumping down your throat. It looks to me, as an outsider, like the concensus is that the existing interface *is* ok, but as a commons committer I hope that everyone will give it serious consideration, and not ignore it as too late. It is perfectly valid to change APIs before 1.0 (keeping compatibility is *desirable* but not mandatory). It's certainly better than being stuck with the wrong API post-1.0. Agreed. I have first hand experience of dealing with a poor API being exposed in a release... -- Martin Cooper Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] nightly builds
Where are you looking.. I see them here: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-email/?C=M;O=D (linked from the commons homepage) Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: [Email] nightly builds Hi all, I just saw, that the nightly build of [email] is empty. Did I miss something? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] nightly builds
I have just committed the update build.xml file. It works great on my local machine. Craig, you may be interested in this: http://jira.codehaus.org/browse/MPANT-7. I added a fix to the Maven Ant plugin so that included jar's aren't downloaded when the build.xml is generated by Maven. This allows us to use a completely Maven generated Ant file for Email. Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 6:13 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [Email] nightly builds It looks like the binary distribution builds are failing -- which would likely happen if you've added a dependency that my script doesn't know about. Alas, I'm on the road (and therefore can't reach my desktop system at home that is running these builds behind a firewall) until I get back tonight. But I'll look at it then. Craig On Tue, 23 Nov 2004 17:12:56 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Where are you looking.. I see them here: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-email /?C=M;O=D (linked from the commons homepage) Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: [Email] nightly builds Hi all, I just saw, that the nightly build of [email] is empty. Did I miss something? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Promote Email to Commons Proper
With the following votes the Commons community has decided to promote Commons Email from the sandbox: Commons Committers +1 robert burrell donkin [EMAIL PROTECTED] +1 Henri Yandell [EMAIL PROTECTED] +1 Shapira, Yoav [EMAIL PROTECTED] +1 Matthias Wessendorf [EMAIL PROTECTED] +1 Eric Pugh [EMAIL PROTECTED] Commons Sandbox Committers +1 Joe Germuska [EMAIL PROTECTED] The voting thread can be found here: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] pache.orgby=threadfrom=938115 If I missed anyone's +/- votes, please speak up. I'll also need someone with the right bugzilla magic to add the [email] component to the drop down of components. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Is there a split method based on case?
It seems like it might also help flesh out WordUtils.. Would just a method that splits be enough, or is there any reason to get fance and insert spaces etc...? -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 4:40 AM To: Jakarta Commons Developers List Subject: Re: [lang] Is there a split method based on case? I also had to recently do this, for the same reasons :-) -Corey On Thu, 18 Nov 2004 00:26:16 + (GMT), Stephen Colebourne [EMAIL PROTECTED] wrote: FYI, I recently had to write this same method to take resource keys and make more human readable sentences. So, maybe there is space for it in lang. Stephen --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, This sounds like a job for regular expression substitution: replace all uppercase chars with a space followed by that upper case char. See the ORO project: http://jakarta.apache.org/oro/index.html Gary -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 17, 2004 3:11 AM To: Commons-Dev Subject: [lang] Is there a split method based on case? Hi all, I am converting some classnames to user friendly names. So I have a class call my.companies.own.SpecialStep and I can use the substringAfterLast(my.companies.own.SpecialStep,.) to return SpecialStep. I want to convert this to Special Step. Any ideas on how to do this using commons-lang? If I had AnotherSpecialStep, I'd want to split it up so I got Another Special Step. Would this be a good idea for commons-lang's WordUtils? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Alright.. This thread has somewhat gotton away from me. Since Dumbster is now licensed as ASL (despite the website being out of date), can we move to a conclusion on this thread? If we consider that [email] hasn't materially changed, and therefore a new vote isn't required, then I currently tally: +1 Eric Pugh +1 Matthias Wessendorf +1 Yoav Shapira Robert, you raised the original lgpl issue which I hope is now sorted out. While you didn't specifically put a -1 down, I think it was implied. Would you be willing to change that to something else? Eric -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 3:05 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper It'd be pretty easy to have James use the Null mailet as the first (and only step) in its processing logic. This would cause James to spool the incoming messages to disk, and then always discard them. That would be a much heavier weight solution though. We use something slightly like this, at least informally. There's a tool called Postal (http://www.coker.com.au/postal/) that does SMTP and POP benchmarking, and that has an SMTP sink. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Corey Scott wrote: Serge, [Extract from the website http://quintanasoft.com/dumbster/] The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The Dumbster slots itself very easily into your testing strategy. As long as your application talks to an email server using SMTP then the Dumbster can be used to test the application with no code changes. [End extract] We have been using it to allow us to test send mails and do some rudimentary verification of the sent mails in our jUnit tests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Is there a split method based on case?
Hi all, I am converting some classnames to user friendly names. So I have a class call my.companies.own.SpecialStep and I can use the substringAfterLast(my.companies.own.SpecialStep,.) to return SpecialStep. I want to convert this to Special Step. Any ideas on how to do this using commons-lang? If I had AnotherSpecialStep, I'd want to split it up so I got Another Special Step. Would this be a good idea for commons-lang's WordUtils? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Website has been updated
Right now, anything that gets deployed into the Apache dist directory gets rsynced over to ibiblio. However, for things like -SNAPSHOT releases, they really shouldn't be going to Ibiblio b/c they aren't really released. I think the commons-email SNAPSHOT was moved when Maven project and IBiblio were first being set up. We should point people to the nightlies that are generated instead. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:49 AM To: Jakarta Commons Developers List Subject: Re: [email] Website has been updated Eric, Do you know why the commons-email SNAPSHOT.jar is very old on the maven repo? Do we have to do something to keep this up to date? Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address))
Joe, Can you add your change to /xdocs/changes.xml? Also, you may want to add yourself to project.xml as well :-) Eric -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Sunday, November 14, 2004 9:18 PM To: Jakarta Commons Developers List Subject: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address)) I updated Email.java and added some notes at the bottom of xdocs/examples.xml. I couldn't figure out any way to have Dumbster simulate a bounce, but I did write a trivial Java app that sent a message with and without setting the bounce address value and confirmed that it did what I intended it to do. I haven't yet got karma for any Commons-proper projects, but I'd be happy to be on STATUS and continue to try to help keep email going after it graduates from the sandbox. Joe I am happy to have you apply this fix, I think I understand better. The one thing I would ask is that you put a bit of documentation into either the javadocs, or even better, into /xdocs describing this behavior. I agree that is shouldn't be a system property. System properties often have a habit of causing nasty head scratching bugs as you wonder why the bounce isn't working properly! Since we are moving to promote from commons-sandbox, are you also a commons committer? Can I list you on the STATUS document? -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
