Commons-Attributes 2.2 Corrupted Manifest
Hi all, the Commons-Attributes 2.2 jars have corrupted manifest.mf files. This is apparently causing a bit of problems for users. The issue is in the extension properties: ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5. jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1 .5.jar As you can see, there are spaces and cr/lfs in the URLs. This causes maven 2 etc. to fail. Frankly, I have no desire nor time to get a new release out. What I wonder, however, is if we can treat this as a corrupted file issue and I can just fix the jars in the distribution directory by replacing or deleting the manifest.mf file in them. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons Attributes 2.2 released
Thanks, Henri. /LS On 8/4/06, Henri Yandell [EMAIL PROTECTED] wrote: Commons Attributes 2.2 is now available. For details of what's new in Attributes 2.2 please see the change-log[1]. Attributes is considered to have been made obsolete by the Java 5.0 release, so 2.3 and beyond are not expected to be created. Attributes is available in either binary or source form from the Attributes download page[2]. - Henri Yandell [1] http://jakarta.apache.org/commons/attributes/changelog.html [2] http://jakarta.apache.org/site/downloads/downloads_commons-attributes.cgi - 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 Attributes 2.2
+1 Let's get it out the door. Thank you for doing the release, Henri. /LS On 7/24/06, Henri Yandell [EMAIL PROTECTED] wrote: This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] attributes 2.2-RC1
Sure. On 7/21/06, Henri Yandell [EMAIL PROTECTED] wrote: Still on commons-dev and able to say that? :) I need some noise to make the others notice the email. Hen On 7/21/06, Leo Sutic [EMAIL PROTECTED] wrote: Looks fine to me. I say ship it. /LS On 7/21/06, Henri Yandell [EMAIL PROTECTED] wrote: Sorry it took me a while to put it together. Do you have time to take a look at the RC and see if I screwed anything up? -- Forwarded message -- From: Henri Yandell [EMAIL PROTECTED] Date: Jul 20, 2006 12:07 AM Subject: [attributes] attributes 2.2-RC1 To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Opinions appreciated on the readiness of 2.2-RC1 of Attributes: http://people.apache.org/~bayard/commons-attributes/ -- One negative off the bat: * No poms for the Maven repository. Looks like they haven't been deployed before and as they use inheritence I'll have to look into how to best put them together. If anyone has a clue, I'm all ears. I suspect it'll be to make them manually. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Leaving project
On 7/9/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote: Bugfixes and a move to qdox instead of xjavadoc to parse source files. Why the qdox move? (just in case I have to write the release notes :) ). I ran into some parsing errors with xjavadoc. In particular this one did it for me: xjavadoc has a nasty habit of introducing '=' characters in the parse result. So if you feed it '@@Name ( xyz )' it tells you that it has read '@@Name (=xyz )'. So, 2.2 and then move it to dormant, or? Pretty much, though not the same dormant as the dead sandbox stuff. Do you plan to hang around in Commons, or is Attributes the only one you really had much interest in? Well, it boils down to a matter of time. As it is, I cant even keep up with my own project (attributes), so heling out with any other project is just out of the question. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
On 7/10/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote: Getting 2.2 out would be a nice endcap, and if you could just get the thing out in accordance with specs, that would be absolutely fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do the release manager stuff. Which build system is the most used with attributes, Ant or Maven? Are we releasing the Plugin as well as the two jars? Currently the build is maven install-snapshot maven install-plugin because the plugin depends on the snapshot 2.2 versions. Should the plugin update to 2.2 dependencies? Yes. I have done the change in SVN. The ant dist creates the 3 zips. Do you then zip that up as the release, and zip up a source tree as the source release? No, just do a svn update and use maven dist to get the distributions. You should end up with src/bin tgz/zip and all three jars (api, compiler, plugin). Thanks for doing this. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Leaving project
On 7/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/7/06, Leo Sutic [EMAIL PROTECTED] wrote: Hi All, I'm abandoning the Commons Attributes project. I simply do not have the time to keep it going any more. Understandable. Given that Attributes sounds like it i replaced by JDK 1.5, and end of life was always on the cards. Agreed. (I have actually made this explicit in the FAQ since day one.) Yep. Which one is the 39 step one? Preparation + release checklists. So actually, 39 steps in two lists. Therefore: The current snapshots (which you can download from the project home page as 2.2 RC) will be the last I produce. For all intents and purposes, consider them the final 2.2 release. What's the story with 2.2? Lots of bugfixes, or a reworking of the code or ...? Bugfixes and a move to qdox instead of xjavadoc to parse source files. Getting 2.2 out would be a nice endcap, and if you could just get the thing out in accordance with specs, that would be absolutely fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do the release manager stuff. So, 2.2 and then move it to dormant, or? /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Attributes] Leaving project
Hi All, I'm abandoning the Commons Attributes project. I simply do not have the time to keep it going any more. I have now intended to get a 2.2 release out for *nine months* but haven't found the time to actually do it in all that time. That, if anything, is a clue that it is time to just admit defeat. What finally made me realize this was when I looked at the Jakarta Commons release guidelines. When I see a 39 step checklist for releases I don't see release early, release often. I see myself losing my will to live. There is something wrong when the release process is twice as long as the time it takes to get all bugfixes and new features in for the release. Therefore: The current snapshots (which you can download from the project home page as 2.2 RC) will be the last I produce. For all intents and purposes, consider them the final 2.2 release. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][Release][Attributes] Release Commons-Attributes 2.2
The nightly snapshots would be the RC. (As I understand it, they have been used in production systems for quite some time by various people.) What do you need to see in terms of an RC? /LS On 5/30/06, Henri Yandell [EMAIL PROTECTED] wrote: I'm in favour of a release, but can we see an RC so we have something to vote on? Hen On 5/29/06, Leo Sutic [EMAIL PROTECTED] wrote: Hi all, well, as usual I'm about one year late getting a release out, but I'd like to release Commons Attributes 2.2. The big changes are: 1. Some bugfixes 2. Support for attribute packages when using maven. +1 from me. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
[all] Where do Nightly Builds Come From?
Hi, how are the nightly builds created? I've tried to make a change to the nightly build of Commons-Attributes, by editing the Ant build.xml file for the project, but the nightly build process keeps churning out the same old artifacts. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote][Release][Attributes] Release Commons-Attributes 2.2
Hi all, well, as usual I'm about one year late getting a release out, but I'd like to release Commons Attributes 2.2. The big changes are: 1. Some bugfixes 2. Support for attribute packages when using maven. +1 from me. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] please add support for attributepackages in maven plugin
I'll see if I can add it to the nightly build. BTW - I know that the project is embarrasingly overdue for a release - something that was driven home by this article: http://programming.newsforge.com/article.pl?sid=06/05/09/2011212from=rss /LS On 5/17/06, Nicolas De Loof [EMAIL PROTECTED] wrote: Where can I find a nightly build of the maven commons-attribute plugin ? The commons-attributes nightly-build only contains compiler + api Nicolas De Loof a écrit : Sorry, I've just discovered this feature is in CVS... http://jakarta.apache.org/commons/attributes/changelog.html Nicolas De Loof a écrit : attributepackages property is used on ant task to allow short attributes in code. There is no support for it in the maven plugin. A simple property may do the job. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] please add support for attributepackages in maven plugin
Ok, I've tried to get the nightly build to produce a plugin jar as well... Let's see how it works. /LS On 5/20/06, Leo Sutic [EMAIL PROTECTED] wrote: I'll see if I can add it to the nightly build. BTW - I know that the project is embarrasingly overdue for a release - something that was driven home by this article: http://programming.newsforge.com/article.pl?sid=06/05/09/2011212from=rss /LS On 5/17/06, Nicolas De Loof [EMAIL PROTECTED] wrote: Where can I find a nightly build of the maven commons-attribute plugin ? The commons-attributes nightly-build only contains compiler + api Nicolas De Loof a écrit : Sorry, I've just discovered this feature is in CVS... http://jakarta.apache.org/commons/attributes/changelog.html Nicolas De Loof a écrit : attributepackages property is used on ant task to allow short attributes in code. There is no support for it in the maven plugin. A simple property may do the job. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] building with maven
Hi Matt, I'm currently away from any kind of build environment, so I can't replicate your problems (it built fine for me last time I tried, though). Could you post the full Maven output, and could you run maven with the -v (verbose) switch? I'll attack the problem from this end, as much and fast as I can. Sorry that C.A is causing you problems. I definitely intended for it to be a dirt-simple check-out-and-build-and-use. /LS On 3/31/06, Matt Benson [EMAIL PROTECTED] wrote: I am attempting to build C.A. What I have figured out by trial and error so far: - install maven 1.0.2 - co commons-attributes and commons-build side-by-side - in /commons-attributes, run 'maven install'. It goes through retrieving dependencies and placing these all in a maven repo. This includes the javadoc jar ($HOME/.maven/repository/javadoc/jars/javadoc-1.4.jar). The C.A. api builds fine, but when the compiler tries to build, the classes and even the packages in the javadoc jar are not found and the build fails. Does anyone have any advice to get further? Thanks, Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: [POLL] System.currentTimeMillis()
Do you run ntpd or some other clock-syncing program?
/LS
On 12/14/05, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi folks,
I have written a generator for commons-id, that is based in the end on the
system clock. Unfortunately I have sporadic failures in Gump that I cannot
explain. I developed this on a Windows box, but had now a chance for a test
with Linux. Suddenly I have also sporadic failing tests. First I thought my
algorithm is flawed, but then I wrote this little unit test:
public void testSystemTimeIsIncreasing() {
long last = System.currentTimeMillis();
for (int i = 0; i 5; i++) {
long now = System.currentTimeMillis();
assertTrue(Iteration + i, now = last);
last = now;
}
}
Believe it or not, this test will quite always fail within the first 1
iterations on my Linux box. So how does this test behave on your boxes?
Please also note OS and JDK ...
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating the website
Hi Robert, where is the mavenized build of the site? Neither jakarta-site nor jakarta-site2 has any mavenization. /LS On Sun, 15 Aug 2004 20:18:45 +0100, robert burrell donkin [EMAIL PROTECTED] wrote: hi leo i think that those instructions are now out of date. commons now used a mavenized build for the main site and only the source is stored in CVS. it looks to me as if attibutes is mavenized as well so you need to do a maven site:deploy (rather than a CVS update). - robert On 15 Aug 2004, at 16:55, Leo Sutic wrote: Hi, as part of the release process of Commons-Attributes, I am trying to update the Jakarta website. I'm following the instructions at: http://jakarta.apache.org/commons/releases/release.html Step 15: cd /www/jakarta.apache.org/commons cvs -q up cvs update: No CVSROOT specified! Please use the `-d' option cvs [update aborted]: or set the CVSROOT environment variable. What now? I have modified the source xdocs, build the site, committed the changed pages. All I want to do is refresh the files on the site from CVS. /LS - 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]
Requesting Karma for Jakarta-Site2
Hi, how do I get karma for jakarta-site2? I'm trying to update the sourceindex and binindex files to include Commons-Attributes as part of the release process. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] Ant build file broken
Will fix. Thanks for pointing out. (Seems like the build.xml got clobbered somewhere - it generates the wrong jars as well.) /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] ArrayUtils monster file
On Wed, 28 Jul 2004 12:45:45 +0100 (BST), Stephen Colebourne
[EMAIL PROTECTED] wrote:
1) This change should only be supported if it moves
methods not yet released.
2) The new utils class must have a clear scope, which
will give it a clear name.
3) Size is not the first factor, API is.
In this case, the intent of the
add/addAll/remove/indexOf methods is to make an array
look and behave like a list, hence ArrayAsListUtils.
How about making it an adapter class?
public class ArrayListAdapter implements List {
private static class IntArrayAdapter {}
...
public ArrayListAdapter (Object[] array) {}
public ArrayListAdapter (int[] array) {}
public ArrayListAdapter (double[] array) {}
public ArrayListAdapter (boolean[] array) {}
public Object[] getArray () { ... }
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][RESULT] Release Attributes 2.1
Result of vote: +1 Leo Sutic (leosutic), robert burrell donkin (rdonkin), Davanum Srinivas (davanum) No -1 votes were cast. Summary: Attributes 2.1 good to go for a release. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] /avail/ change needed Was: [VOTE] Leo Sutic Commit Status
OK, confirmed. Apologies to all for being pushy about this, but it is my experience that if a subject drops off the mailing list, it tends to be forgotten. /LS On Sat, 12 Jun 2004 13:49:15 -0400, Noel J. Bergman [EMAIL PROTECTED] wrote: Leo's in. Could someone with avail access add him into Commons? Done. Leo, please verify. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Leo Sutic Commit Status
So far I count: +1 from: Noel J. Bergman, Henri Yandell, Alex Karasulu, Phil Steitz, Dion Gillard, Dirk Verbeeck No -1s or 0s. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Sandbox/Attributes] Promotion and Release (some help needed)
Dirk, I touched on the issue your bring up here: http://article.gmane.org/gmane.comp.jakarta.commons.devel/46146 and the short version of it is: It appears that attributes does pretty much everything people want it to do, and so there is little reason for anyone to dive in. /LS On Tue, 08 Jun 2004 08:16:49 +0200, Dirk Verbeeck [EMAIL PROTECTED] wrote: But do you think there is enough community support for it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Sandbox/Attributes] Promotion and Release (some help needed)
On Mon, 7 Jun 2004 21:24:35 -0400, Noel J. Bergman [EMAIL PROTECTED] wrote: Leo, Let's get you on-board. Also, have you had a chance to work with JAM on the merger? No. I never heard from the JAM developer. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] active components?
From: Henri Yandell [mailto:[EMAIL PROTECTED] I'm interested in finding out which parts of sandbox are not active and which would be worth putting time into getting a release done. Currently on the Commons site we list these as the active components, which are actually active and where are they release wise? attributes Attributes is active. Release-wise its in a bit of a bind - I know that it is used by people - for example in the Spring Framework (www.springframework.org). If each downloader of Spring can be considered a user, then attributes has over 10,000 users. Of course this statistic is 50-75% made up, but I'd be surprised if it has less than ten users. However, this has not resulted in a community of *developers*, making attributes one of those projects that don't quite live up to the Apache standards. There's me, but that's all. In defense of this state, it appears that attributes does pretty much everything people want it to do, and so there is little reason for anyone to dive in. Relase-wise I'm now focusing on writing documentation, not putting new features in. A release would be great, especially for the spring people, but I don't know if it is possible due to the lack of developers. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] active components?
From: Henri Yandell [mailto:[EMAIL PROTECTED] This definitely sounds like a worry. Our site has informally released the snapshot versions as (effectively) an alpha release. Is Spring dependent on these versions too? As far as I know, Spring is using the snapshot version from just before they released 1.0 of Spring framework. Documentation looks good. Do you have a roadmap for finishing that? No. I can get one done, though, and get back to you. What future does Attributes have with the 1.5 Annotations? Do they replace it, or is it still viable then? [I suspect that is FAQ-worthy]. Definitely FAQ-worthy, that one. Will include it. Short answer is that Attributes is a stop-gap measure until 1.5 is commonly used. Given that it is only about now that people even are starting to debate requiring 1.4 for their projects means that the gap may be there for some time. In short: I expect 1.5 Annotations to become the standard when 1.5 becomes the standard. Do you need any help anywhere? If you could read the docs and send me a list of all the questions and/or any critique that popped up in your head. I frequently find that my idea of what a user is looking for in the docs and what they actually are looking for are at odds. (See question of Attributes vs. 1.5 Annotations.) /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: moving JAM to org.apache.jam
VERY QUICK REPLY: Looks interesting. Some more issues to keep in mind: + There are users of C-A out there: Spring Framework (www.springframework.org) is one of them. This means that we can't just replace C-A with JAM. Even though it is in sandbox, going from one API to another isn't the proper way to ever get out of sandbox. + There are users of JAM out there: XMLBeans, for one. This means that we can't just replace JAM with C-A. Even though it is in incubator, going from one API to another isn't theproper way to ever get out of incubator. + The two APIs are quite different in their approach. But let's try a merge anyway. I'm up for it. /LS From: Leo Simons [mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Missing Classes
I noticed that the 1.1-dev and all the 1.0.x releases of commons-logging do not have the org.apache.commons.logging.impl.AvalonLogger class. Will this class be included in the next release, or has the class been dropped? /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang][proposal] enum keyword in Java 1.5 (WAS: [all])
-Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: den 19 februari 2004 20:56 To: 'Jakarta Commons Developers List' Subject: [lang][proposal] enum keyword in Java 1.5 (WAS: [all]) Let's rename the org.apache.commons.lang.enum package to... (0) org.apache.commons.lang.enum, do nothing, not acceptable. (2) org.apache.commons.lang.enu, shorter is better? (3) org.apache.commons.lang.enumeration, verbose isn't great. (4) org.apache.commons.lang.e9n, like i18n, pretty cryptic. (5) org.apache.commons.lang.pre15.enum, if you're writing for 1.5, use 1.5. others? (6) Just remove the subpackage. Put all three classes in org.apache.commons.lang. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [attributes][patch] problem with AttributeUtil
OK, patched (I hope). Please check that the new code works as advertised/expected. /LS From: news [mailto:[EMAIL PROTECTED] On Behalf Of Dan Diephouse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [attributes][patch] problem with AttributeUtil
On closer inspection:
/**
* Filters a collection objects. The returned collection
* only contains those objects that have an attribute of the
specified type.
*/
public static Collection getObjectsWithAttributeType (Collection
objects, Class attributeClass) {
ArrayList result = new ArrayList ();
Iterator iter = objects.iterator ();
while (iter.hasNext ()) {
Object object = iter.next ();
Class clazz = object.getClass ();
if (Attributes.hasAttributeType (clazz, attributeClass)) {
result.add (object);
}
}
return result;
}
is correct.
Because we want, for each object, to know if its class has a certain
attribute. If it does, then we return it.
/LS
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Dan Diephouse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process for Sandbox Projects
Robert Burrell Donkin wrote: the usual rule is that sandbox components cannot be released. this has worked very well in the past and i'd be very reluctant to see exceptions without compelling reasons. I don't think this will be an exception. commons-attributes has a nightly build which are often used as SNAPSHOTs. there are a couple of simple things that have worked for components in the past. the first is sorting out the documentation and the web site. the attributes web sites hasn't been updated for almost a year and doesn't contain a lot of information. the second is putting something into the apache newsletter. Those are things that are to be sorted soon. The website is redone, but I don't have access to jakarta.apache.org so I can't upload it. I have talked to [EMAIL PROTECTED] about access, and we came to the conclusion that I should just wait until jakarta.apache.org was moved to the same server as cvs.apache.org (which should happen soon). The nightly build is something I'm working on right now. So expect the commons-attributes project to look a bit more alive soon. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release Process for Sandbox Projects
From: Stephen Colebourne [mailto:[EMAIL PROTECTED] As a warning, my concerns would be the speed of passage through the sandbox. You need to think if you have a community to maintain this in commons proper, and whether people have had enough time to review it. My understanding was that I needed to go to commons proper before even sending out an alpha release. This put me in a bit of a catch-22: I need some kind of release in order to hope to build a community, but I need a community before I can do a release. Since Henri set me straight on that one - only the non-alpha, this-is-the-big-one release requires that the project is viable in terms of community support and so on. So I figure this: Unless I have a community, there's no point in making a non-alpha, non-beta release. So I'll go for an alpha release and see if I get some kind of community around it. If I do, then the move to commons proper shouldn't be a problem. If not, then it's a codebase with no users and should be killed off to make space. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons-sandbox/attributes/site/xdocs index.xml
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Why are you keeping two project.xml files?? The Attributes project has two parts to it: + The runtime API. + The compiler. In order to separate those, I must have one project.xml for each, since Maven equates one jar == one project == one project.xml. So since I want the API and the compiler in two jars, that means two projects which means two project.xml. Then I split off the site into a separate one because I thought it looked good. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release Process for Sandbox Projects
I have moved Avalon Attributes into the Commons Sandbox now, and would like to get a release out the door. Just so I understand how this is done: If I understand what I've heard/read correctly, Sandbox projects aren't released. They have to be accepted into Commons proper first. Question: How is this done, what's the process? Second, I'd like to do the following pretty much immediately: 1. Get the project website up. I'm quite new to Maven, and as far as I understand, typing: maven site:deploy will do this for me. I'm just a bit too afraid to try this out without getting some confirmation of this first, though... I have already done everything to properly generate the site locally - if I look into target/docs then I have a site that is exactly as I want it. 2. Get an alpha release out. I have some people over at Avalon who would like a first cut of code to look at. Can this be done inofficially, without acceptance into Commons proper? /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - commons-attributes
From: Sam Ruby [mailto:[EMAIL PROTECTED] This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-08-21/commons-attributes.html Buildfile: build.xml does not exist! Build failed It's a Maven project. How do I solve this? I note that some other sandbox projects have build.xmls that duplicate the Maven functionality. Is this the only way or is there a better one? /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release Process for Sandbox Projects
OK, then I should be set to go... Thanks! /LS From: Henri Yandell [mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - commons-attributes
Thanks! /LS From: Henri Yandell [mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - commons-attributes
Nice seeing a familiar face - thanks for the help. /LS From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons at the moment, its the only way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Leo,
I figure that you should go for it.
I'd like to hear more about your plans. JSR 175 is the
normative statement of what attributes must be in Java. How
do your plans compare and contrast with JSR 175, nanning,
Aspect4J, etc?
The major differences (that I'm aware of) are:
+ I store attributes in generated classes. The classes are
generated at compile-time by the attribute compiler as
source files.
+ Attributes are object instances of any class (not just
serializable). Last I checked, nanning attributes only
allowed string valued attributes. Attrib4J used .class
file manipulation, but was moving away from that.
+ I'm sure I'm missing out on something here...
I wish I had a copy of JSR175 - are you aware of any place
I can get it? I've been searching for it in order to make
my implementation sort-of conformant.
An explanation of how my impl works is at:
http://marc.theaimsgroup.com/?l=avalon-devm=105974933614920w=2:
(...)
With the risk that this turns into a Leo's Picks column I am also
beginning to like the way attributes are handled in .Net, with value
objects. You'd have:
import org.apache.avalon.framework.attributes.ThreadSafe;
import org.apache.avalon.framework.attributes.Dependency;
/**
*
* @attribute new ThreadSafe()
* @attribute new Dependency( MyDependency.class, my-dep )
*/
public class MyComponent {
}
This could be compiled into a .java file and then into a .class
file:
public interface AttributeClass {
public Set getClassAttributes ();
}
import org.apache.avalon.framework.attributes.ThreadSafe;
import org.apache.avalon.framework.attributes.Dependency;
public class MyComponent$Attributes implements AttributeClass {
public static final Set classAttributes = new HashSet ();
static {
classAttributes.add ( new ThreadSafe () );
classAttributes.add ( Dependency( MyDependency.class,
my-dep ) );
}
public Set getClassAttributes () {
return classAttributes;
}
}
A standard API would be able to access this via:
Class c = MyComponent.class;
Class attributeClass = c.getClassLoader ().loadClass ( c.getName +
$Attributes );
AttributeClass instance = (AttributeClass)
attributeClass.newInstance ();
Set classAttributes = instance.getClassAttributes ();
and so on...
/LS
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Attributes] Inherit and Develop
Hi, I'm a comitter at the Avalon project (avalon.apache.org), and I have developed tools and API to enable C#/.Net like attributes in Java. Originally I developed it as a proof-of-concept, and we held a vote on what to do with the project once the proof was done. The result was basically nice code, make it a real project - but do it elsewhere. The Commons Attributes project seemed to be the most natural place to go to. As far as I can see, Commons Attributes is *dead* in terms of development. Therefore I ask the following: + Commit access to jakarta-commons-sandbox/attributes + Some indication that the attributes project is indeed dead and that I can inherit it. This is just to pre-empt any conflicts arising from committing code to a repository that used to be used by someone else. For an explanation of what I have done, you can read the Javadoc Overview (along with some QA) at: http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/attributes/a pi/src/java/overview.html?rev=HEADcontent-type=text/html /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Leo Sutic [mailto:[EMAIL PROTECTED] + Commit access to jakarta-commons-sandbox/attributes My apache user id is [EMAIL PROTECTED] (Might be good to include in a request for commit access.) /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Ryan Hoegg [mailto:[EMAIL PROTECTED] Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Thanks. I've checked it out. However, I think that the approach taken in the Avalon version still deserves to be explored more before a merge can be discussed. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: Eric Pugh [mailto:[EMAIL PROTECTED] I believe that as an Apache committer, you already have Karma for the sandbox. You're right! (At least I am part of the jakarta group.) I thought that my *Jakarta* privs were lost when Avalon became a top-level project (and moved out of Jakarta). Guess they weren't. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
From: James Strachan [mailto:[EMAIL PROTECTED] So you're most welcome to the commons-attributes project. Thanks! /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in StaticBucketMap
I've found a bug in the StaticBucketMap class, the remove(Object)
method:
/**
* Implements {@link Map#remove(Object)}.
*/
public Object remove( Object key )
{
int hash = getHash( key );
synchronized( m_locks[ hash ] )
{
Node n = m_buckets[ hash ];
Node prev = null;
while( n != null )
{
HERE if( n.key == null || ( n.key != null n.key.equals(
key ) ) )
{
// Remove this node from the linked list of nodes.
if( null == prev )
{
// This node was the head, set the next node to
be the new head.
m_buckets[ hash ] = n.next;
}
else
{
// Set the next node of the previous node to be
the node after this one.
prev.next = n.next;
}
m_locks[hash].size--;
return n.value;
}
prev = n;
n = n.next;
}
}
return null;
}
The test is:
if( n.key == null || ( n.key != null n.key.equals(
key ) ) )
should be:
if( n.key == key || ( n.key != null n.key.equals( key
) ) )
which is how it works in get(Object), containsKey(Object) etc. and which
is correct. We have a match if the keys match using == OR if they are
equal according to equals().
/LS
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
