Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi all guys, I just received the confirmation from Craig (secretary@a.o) that received the confirmation of my SoftwareGrant for Meiyo. I'll start a new VORE soon! Have a nice weekend, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Jun 11, 2011 at 8:49 AM, Phil Steitz wrote: > On 6/10/11 12:30 AM, Stephen Colebourne wrote: >> I've used scannotation before, which is reasonably well known I >> believe, but could probably be improved on. I think with multiple >> versions at Apache, it is a perfect concept for commons. I would check >> out [discovery] first to see if that has a similar goal. >> >> I'd set it up separately to [lang] first, to see how big it is. It >> feels a little frameworky, but may be suitable for inclusion. > +1 - start separately in the sandbox and see where it goes. >> I also think that we should look to include ideas from the old [id] >> project into [lang], as [id] is never going to be released. > > +1 here as well. I think it is a shame that [id] has never made it > to a release. The GUID stuff that prevented it from becoming > releasable is now obsolete. I would be +1 to either promoting it > with aim to release minus the GUID stuff or pulling the useful stuff > (some of it "back") into [lang]. I have had my eyes on some of the > Tomcat code that generates session ids to adapt / incorporate into > [id]. In any case, my +1 here means I will help with the code > and/or promotion. > > Phil >> Stephen >> >> >> On 10 June 2011 06:19, Ralph Goers wrote: >>> On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: >>> Hi all guys, before start working on Digester3 I experimented on GitHub, taking inspiration from Google Guice APIs, embedded EDSLs in configuration classess to solve 2 different kind of problems: * ClassPath scanning[1]: declare with fluent APIs a class path scanner, filering classes users are interested in via fluent logic language, and declaring actions have to be performed, once interested classes have found. We already discussed about that idea time ago, but it has been improved; * Class scanning[2]: Java users often create framework/libraries based on Java5 MetaData Annotations interpreted at runtime, the pattern they usually have to apply is: given a class, visiting all the class inheritance hierarchy, and getting fields/constructors/methods for each class; once found an (AnnotatedElement, Annotation) pair, they have to perform an action. So, the implemented classes aim to reduce the boilerplate and redundant code simply by declaring actions that have to be performed once the pairs (AnnotatedElement, Annotation) are found. >>> I accomplished this in the work I've been doing on Log4J 2.0 by borrowing >>> on some code I found somewhere else at Apache. You can see it at >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. >>> It is used by >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. >>> >>> Of course, I have no idea if these bear any relationship to what you have >>> done. >>> >>> Ralph >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
On 6/10/11 12:30 AM, Stephen Colebourne wrote: > I've used scannotation before, which is reasonably well known I > believe, but could probably be improved on. I think with multiple > versions at Apache, it is a perfect concept for commons. I would check > out [discovery] first to see if that has a similar goal. > > I'd set it up separately to [lang] first, to see how big it is. It > feels a little frameworky, but may be suitable for inclusion. +1 - start separately in the sandbox and see where it goes. > I also think that we should look to include ideas from the old [id] > project into [lang], as [id] is never going to be released. +1 here as well. I think it is a shame that [id] has never made it to a release. The GUID stuff that prevented it from becoming releasable is now obsolete. I would be +1 to either promoting it with aim to release minus the GUID stuff or pulling the useful stuff (some of it "back") into [lang]. I have had my eyes on some of the Tomcat code that generates session ids to adapt / incorporate into [id]. In any case, my +1 here means I will help with the code and/or promotion. Phil > Stephen > > > On 10 June 2011 06:19, Ralph Goers wrote: >> On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: >> >>> Hi all guys, >>> before start working on Digester3 I experimented on GitHub, taking >>> inspiration from Google Guice APIs, embedded EDSLs in configuration >>> classess to solve 2 different kind of problems: >>> >>> * ClassPath scanning[1]: declare with fluent APIs a class path >>> scanner, filering classes users are interested in via fluent logic >>> language, and declaring actions have to be performed, once interested >>> classes have found. We already discussed about that idea time ago, but >>> it has been improved; >>> >>> * Class scanning[2]: Java users often create framework/libraries >>> based on Java5 MetaData Annotations interpreted at runtime, the >>> pattern they usually have to apply is: given a class, visiting all the >>> class inheritance hierarchy, and getting fields/constructors/methods >>> for each class; once found an (AnnotatedElement, Annotation) pair, >>> they have to perform an action. >>> So, the implemented classes aim to reduce the boilerplate and >>> redundant code simply by declaring actions that have to be performed >>> once the pairs (AnnotatedElement, Annotation) are found. >>> >> I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on >> some code I found somewhere else at Apache. You can see it at >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. >> It is used by >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. >> >> Of course, I have no idea if these bear any relationship to what you have >> done. >> >> Ralph >> >> > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] equal instances
On 10/06/2011 22:33, Gary Gregory wrote: > On Jun 10, 2011, at 13:47, Mark Thomas wrote: > >> On 09/06/2011 17:47, Phil Steitz wrote: >>> I guess I "want it both ways" here. We already have a use case for >>> tracking instances - abandoned connection tracking in DBCP and >>> *lots* of requests and practical uses for holding references to >>> instances in circulation (mostly from dbcp, but I recall some from >>> people managing socket pools or message queue pools). >>> >>> I know I flip/flopped on this - initially thinking it was a >>> reasonable expectation for factories to produce equals-discernible >>> instances. But I am afraid it will be the source of hard to find >>> bugs and I can see the argument on the other side - i.e., a pool >>> should be perfectly happy managing indiscernible objects. I never >>> agreed with Leibniz [1] - he he. >>> >>> As you pointed out, Mark, 1.x gets around this problem by wrapping / >>> unwrapping but that strategy makes identity-checking awkward. I >>> will think about this some more, but a hybrid strategy where >>> _allObjects becomes a HashBag (steal from [collections]) used for >>> quick checking and we add _allInstances to hold wrapped instances. >>> Could be nonsense, but something along these lines might work. >> >> I've done some testing and under heavy load (10 threads concurrently >> creating 100 objects each) on a 8 core machine I saw zero >> duplicates. With this in mind I think I can do the following for pool 2: >> - have calls to PoolableObjectFactory#makeObject() check >> System#idenityHashcode() and if a duplicate is detected discard that >> object and ask the factory for a new one; > > With a retry limit to avoid infinite loops. Indeed. > Is this a feature that should be in a subclass or a toggle? Or do we > want it baked it? I think it is going to have to be baked in. We have requirements that mean we need to track all the objects and we need a scalable solution for doing that. However we slice it, that is going to come down to hashes and we need to prevent collisions. Mark > Gary > >> - use some simple wrapper based on identityHashcode around objects in >> the idle object pool and the all objects map >> - when an object is returned, use identityHashcode to map it back to the >> right object in the all object pool >> >> The requirement this places on PoolableObjectFactories is that they must >> produce objects with identityHashcodes that only rarely have collisions. >> Since this is under JVM control and my test case shows this is rare, I'm >> happy with this. >> >>> The important thing at this point is to agree on what invariants we >>> expect [pool] and user factories to maintain. Since I have already >>> changed my mind once on this, and I understand the practical >>> arguments in favor of staying with the setup now in trunk (equal >>> instances not allowed), I would like to hear what others have to say >>> on this. >> >> I think we can have it both ways this time :) >> >> I'll leave this a little while before I do any coding to give folks a >> chance to comment. >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] equal instances
On Jun 10, 2011, at 13:47, Mark Thomas wrote: > On 09/06/2011 17:47, Phil Steitz wrote: >> I guess I "want it both ways" here. We already have a use case for >> tracking instances - abandoned connection tracking in DBCP and >> *lots* of requests and practical uses for holding references to >> instances in circulation (mostly from dbcp, but I recall some from >> people managing socket pools or message queue pools). >> >> I know I flip/flopped on this - initially thinking it was a >> reasonable expectation for factories to produce equals-discernible >> instances. But I am afraid it will be the source of hard to find >> bugs and I can see the argument on the other side - i.e., a pool >> should be perfectly happy managing indiscernible objects. I never >> agreed with Leibniz [1] - he he. >> >> As you pointed out, Mark, 1.x gets around this problem by wrapping / >> unwrapping but that strategy makes identity-checking awkward. I >> will think about this some more, but a hybrid strategy where >> _allObjects becomes a HashBag (steal from [collections]) used for >> quick checking and we add _allInstances to hold wrapped instances. >> Could be nonsense, but something along these lines might work. > > I've done some testing and under heavy load (10 threads concurrently > creating 100 objects each) on a 8 core machine I saw zero > duplicates. With this in mind I think I can do the following for pool 2: > - have calls to PoolableObjectFactory#makeObject() check > System#idenityHashcode() and if a duplicate is detected discard that > object and ask the factory for a new one; With a retry limit to avoid infinite loops. Is this a feature that should be in a subclass or a toggle? Or do we want it baked it? Gary > - use some simple wrapper based on identityHashcode around objects in > the idle object pool and the all objects map > - when an object is returned, use identityHashcode to map it back to the > right object in the all object pool > > The requirement this places on PoolableObjectFactories is that they must > produce objects with identityHashcodes that only rarely have collisions. > Since this is under JVM control and my test case shows this is rare, I'm > happy with this. > >> The important thing at this point is to agree on what invariants we >> expect [pool] and user factories to maintain. Since I have already >> changed my mind once on this, and I understand the practical >> arguments in favor of staying with the setup now in trunk (equal >> instances not allowed), I would like to hear what others have to say >> on this. > > I think we can have it both ways this time :) > > I'll leave this a little while before I do any coding to give folks a > chance to comment. > > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] equal instances
On 6/10/11 10:46 AM, Mark Thomas wrote: > On 09/06/2011 17:47, Phil Steitz wrote: >> I guess I "want it both ways" here. We already have a use case for >> tracking instances - abandoned connection tracking in DBCP and >> *lots* of requests and practical uses for holding references to >> instances in circulation (mostly from dbcp, but I recall some from >> people managing socket pools or message queue pools). >> >> I know I flip/flopped on this - initially thinking it was a >> reasonable expectation for factories to produce equals-discernible >> instances. But I am afraid it will be the source of hard to find >> bugs and I can see the argument on the other side - i.e., a pool >> should be perfectly happy managing indiscernible objects. I never >> agreed with Leibniz [1] - he he. >> >> As you pointed out, Mark, 1.x gets around this problem by wrapping / >> unwrapping but that strategy makes identity-checking awkward. I >> will think about this some more, but a hybrid strategy where >> _allObjects becomes a HashBag (steal from [collections]) used for >> quick checking and we add _allInstances to hold wrapped instances. >> Could be nonsense, but something along these lines might work. > I've done some testing and under heavy load (10 threads concurrently > creating 100 objects each) on a 8 core machine I saw zero > duplicates. With this in mind I think I can do the following for pool 2: > - have calls to PoolableObjectFactory#makeObject() check > System#idenityHashcode() and if a duplicate is detected discard that > object and ask the factory for a new one; > - use some simple wrapper based on identityHashcode around objects in > the idle object pool and the all objects map > - when an object is returned, use identityHashcode to map it back to the > right object in the all object pool > > The requirement this places on PoolableObjectFactories is that they must > produce objects with identityHashcodes that only rarely have collisions. > Since this is under JVM control and my test case shows this is rare, I'm > happy with this. > >> The important thing at this point is to agree on what invariants we >> expect [pool] and user factories to maintain. Since I have already >> changed my mind once on this, and I understand the practical >> arguments in favor of staying with the setup now in trunk (equal >> instances not allowed), I would like to hear what others have to say >> on this. > I think we can have it both ways this time :) Sweet! > I'll leave this a little while before I do any coding to give folks a > chance to comment. I will play with this a little this evening too. Phil > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Sanselan Usage
I'm attempting to use the Sanselan library to add metadata to a TIFF file,
however, I don't know how to accomplish this. I've successfully accomplished
this with a Jpeg, but I don't know what changes need to be done to co-opt
this code for TIFFs. I'll be seperating out the primary sections of code to
a common function, but I've simplified the Jpeg code for posting here. So,
any thoughts on how to accomplish doing the same with a TIFF?
import java.awt.image.BufferedImage;
import java.io.*;
import java.util.HashMap;
import java.util.Map;
import org.apache.sanselan.*;
import org.apache.sanselan.common.*;
import org.apache.sanselan.formats.tiff.TiffImageMetadata;
import org.apache.sanselan.formats.tiff.write.TiffImageWriterLossless;
import org.apache.sanselan.formats.tiff.write.TiffOutputDirectory;
import org.apache.sanselan.formats.tiff.write.TiffOutputField;
import org.apache.sanselan.formats.tiff.write.TiffOutputSet;
public void DoSomething(String tagName, String tagValue){
File inputFile = getInputFile();
IImageMetadata data = null;
OutputStream os = null;
data = Sanselan.getMetadata(inputFile);
TiffOutputSet outputSet = null;
outputSet = getExif(data);
TiffOutputField imageHistoryPre = outputSet.findField(tag);
if (imageHistoryPre != null) {
outputSet.removeField(tag);
}
TiffOutputField imageId = new TiffOutputField(tag, fieldType,
tagValue.length(), tagValue.getBytes());
TiffOutputDirectory exifDirectory = outputSet.getOrCreateExifDirectory();
exifDirectory.add(imageId);
//everything after this is where I get confused.
File temp;
temp = File.createTempFile("FileTaggingProcessingFile", null);
os = new FileOutputStream(temp);
os = new BufferedOutputStream(os);
if (data instanceof JpegImageMetadata) {
new ExifRewriter().updateExifMetadataLossless(inputFile, os, outputSet);
}
if (os != null) {
os.close();
}
getInputFile().delete();
temp.renameTo(getInputFile());
}
Re: [pool] equal instances
On 09/06/2011 17:47, Phil Steitz wrote: > I guess I "want it both ways" here. We already have a use case for > tracking instances - abandoned connection tracking in DBCP and > *lots* of requests and practical uses for holding references to > instances in circulation (mostly from dbcp, but I recall some from > people managing socket pools or message queue pools). > > I know I flip/flopped on this - initially thinking it was a > reasonable expectation for factories to produce equals-discernible > instances. But I am afraid it will be the source of hard to find > bugs and I can see the argument on the other side - i.e., a pool > should be perfectly happy managing indiscernible objects. I never > agreed with Leibniz [1] - he he. > > As you pointed out, Mark, 1.x gets around this problem by wrapping / > unwrapping but that strategy makes identity-checking awkward. I > will think about this some more, but a hybrid strategy where > _allObjects becomes a HashBag (steal from [collections]) used for > quick checking and we add _allInstances to hold wrapped instances. > Could be nonsense, but something along these lines might work. I've done some testing and under heavy load (10 threads concurrently creating 100 objects each) on a 8 core machine I saw zero duplicates. With this in mind I think I can do the following for pool 2: - have calls to PoolableObjectFactory#makeObject() check System#idenityHashcode() and if a duplicate is detected discard that object and ask the factory for a new one; - use some simple wrapper based on identityHashcode around objects in the idle object pool and the all objects map - when an object is returned, use identityHashcode to map it back to the right object in the all object pool The requirement this places on PoolableObjectFactories is that they must produce objects with identityHashcodes that only rarely have collisions. Since this is under JVM control and my test case shows this is rare, I'm happy with this. > The important thing at this point is to agree on what invariants we > expect [pool] and user factories to maintain. Since I have already > changed my mind once on this, and I understand the practical > arguments in favor of staying with the setup now in trunk (equal > instances not allowed), I would like to hear what others have to say > on this. I think we can have it both ways this time :) I'll leave this a little while before I do any coding to give folks a chance to comment. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
On 6/10/11 9:06 AM, James Carman wrote: > On Fri, Jun 10, 2011 at 11:04 AM, Simone Tripodi > wrote: >> (sorry for the delay but today it's my turn for cleaning the house :P) >> Sandbox should be the right place, or I am wrong? > I don't know what the "policy" is, but IMHO if you want to work on > something, it shouldn't be done in the "dormant" branch. I'd say put > it in Sandbox and go to work. That's the least barrier to entry > option you have. Get it figured out there and then we'll make it a > component in the "proper" +1 - we have just voted to make it no longer dormant, so it should move back to the sandbox svn and we should adjust the web site to reflect that. When it is getting near ready for release, we do a promotion vote to promote it to proper. Phil > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
On Fri, Jun 10, 2011 at 11:04 AM, Simone Tripodi wrote: > (sorry for the delay but today it's my turn for cleaning the house :P) > Sandbox should be the right place, or I am wrong? I don't know what the "policy" is, but IMHO if you want to work on something, it shouldn't be done in the "dormant" branch. I'd say put it in Sandbox and go to work. That's the least barrier to entry option you have. Get it figured out there and then we'll make it a component in the "proper" - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old sources
Hi Jochen, AFAIK the GitHub repo is the most up-to-date, at least it's where last releases have been done. Jason, since you mentioned the JIRA instance, can you help us please on fixing OGNL-3[1]? Many thanks in advance, very appreciated!!! Have a nice day, all the best, Simo [1] https://issues.apache.org/jira/browse/OGNL-3 http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 3:53 PM, Jochen Wiedmann wrote: > I'm puzzled. Now, leaving the ASF repository aside, what's to be > considered the most uptodate version? > > On Fri, Jun 10, 2011 at 3:40 PM, Jason Pyeron wrote: >> I have been working with the site admin for the opensymphony.com, we are >> scheduled to backup/migrate a lot of the content this weekend. >> >> But, the svn repo is still up and running at >> http://svn.opensymphony.com/svn/ognl. It is running an older version of svn >> so >> no svnsync support. We will bring online a svn 1.6 export of it so you may >> perform svnsycn in the future. >> >> After this weekend we should be able to perform JIRA exports too. >> >> -Jason >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> - - >> - Jason Pyeron PD Inc. http://www.pdinc.us - >> - Principal Consultant 10 West 24th Street #100 - >> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - >> - - >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> This message is copyright PD Inc, subject to license 20080407P00. >> >> >> >>> -Original Message- >>> From: maurizio.cucchi...@gmail.com >>> [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara >>> Sent: Friday, June 10, 2011 8:41 >>> To: Commons Developers List >>> Subject: Re: [ognl] Old sources >>> >>> IIRC, github conatains the last period of ognl history. >>> Unfortunately I am afraid that the svn repository has got lost. >>> >>> Maurizio Cucchiara >>> >>> Il giorno 10/giu/2011 12.06, "Olivier Lamy" >>> ha scritto: >>> > Hello, >>> > Should be here : https://github.com/jkuhnert/ognl >>> > >>> > Thanks in advance if you can help for this javacc >>> > >>> > 2011/6/10 Jochen Wiedmann : >>> >> Hi, >>> >> >>> >> I notice that the OGNL history hasn't been preserved when >>> importing >>> >> the sources into SVN. Is the old repository still around anywhere? >>> >> I'd like to look for manual changes in the parser. >>> >> >>> >> Jochen >>> >> >>> >> -- >>> >> Capitalism is the astounding belief that the most wickedest of men >>> >> will do the most wickedest of things for the greatest good of >>> >> everyone. >>> >> >>> >> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) >>> >> >>> >> >>> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > Olivier Lamy >>> > http://twitter.com/olamy | http://www.linkedin.com/in/olamy >>> > >>> > >>> - >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> > For additional commands, e-mail: dev-h...@commons.apache.org >>> > >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > Capitalism is the astounding belief that the most wickedest of men > will do the most wickedest of things for the greatest good of > everyone. > > John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
Hi James, (sorry for the delay but today it's my turn for cleaning the house :P) Sandbox should be the right place, or I am wrong? Many thansk in advance! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 3:21 PM, James Carman wrote: > Dormant should be read only. I say move it. > On Jun 10, 2011 8:07 AM, "Konstantin Kolinko" > wrote: >> 2011/6/10 Simone Tripodi : >>> In order to avoid any damage... :) >>> Can someone confirm that the following command >>> >>> `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ >>> https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph >>> resurrected after vote passed >>> http://markmail.org/message/mlvqiqhqm2nqhofr"` >> >> I think it is >> svn move https://svn.apache.org/repos/asf/commons/dormant/graph2 >> https://svn.apache.org/repos/asf/commons/sandbox/graph2 >> >> For reference --- I recently used similar command -- you may see "svn >> copy" in my proposal for BZ 51249 in Tomcat 6.0 STATUS file [1] There >> I create a copy of a new folder that contains test files. I had to >> specify source and target names. >> >> [1]: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/STATUS.txt >> >> By the way >> 1. You may go with "svn copy" and >> delete old folder with "svn del" afterwards as a separate command if >> everything is OK with the copy. >> >> 2. Do you really need to mv it to sandbox? There were some voices to >> continue development in dormant until the component is ready for a >> release. >> >> Best regards, >> Konstantin Kolinko >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old sources
I'm puzzled. Now, leaving the ASF repository aside, what's to be considered the most uptodate version? On Fri, Jun 10, 2011 at 3:40 PM, Jason Pyeron wrote: > I have been working with the site admin for the opensymphony.com, we are > scheduled to backup/migrate a lot of the content this weekend. > > But, the svn repo is still up and running at > http://svn.opensymphony.com/svn/ognl. It is running an older version of svn so > no svnsync support. We will bring online a svn 1.6 export of it so you may > perform svnsycn in the future. > > After this weekend we should be able to perform JIRA exports too. > > -Jason > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Principal Consultant 10 West 24th Street #100 - > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > This message is copyright PD Inc, subject to license 20080407P00. > > > >> -Original Message- >> From: maurizio.cucchi...@gmail.com >> [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara >> Sent: Friday, June 10, 2011 8:41 >> To: Commons Developers List >> Subject: Re: [ognl] Old sources >> >> IIRC, github conatains the last period of ognl history. >> Unfortunately I am afraid that the svn repository has got lost. >> >> Maurizio Cucchiara >> >> Il giorno 10/giu/2011 12.06, "Olivier Lamy" >> ha scritto: >> > Hello, >> > Should be here : https://github.com/jkuhnert/ognl >> > >> > Thanks in advance if you can help for this javacc >> > >> > 2011/6/10 Jochen Wiedmann : >> >> Hi, >> >> >> >> I notice that the OGNL history hasn't been preserved when >> importing >> >> the sources into SVN. Is the old repository still around anywhere? >> >> I'd like to look for manual changes in the parser. >> >> >> >> Jochen >> >> >> >> -- >> >> Capitalism is the astounding belief that the most wickedest of men >> >> will do the most wickedest of things for the greatest good of >> >> everyone. >> >> >> >> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) >> >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> > >> > >> > -- >> > Olivier Lamy >> > http://twitter.com/olamy | http://www.linkedin.com/in/olamy >> > >> > >> - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [ognl] Old sources
I have been working with the site admin for the opensymphony.com, we are scheduled to backup/migrate a lot of the content this weekend. But, the svn repo is still up and running at http://svn.opensymphony.com/svn/ognl. It is running an older version of svn so no svnsync support. We will bring online a svn 1.6 export of it so you may perform svnsycn in the future. After this weekend we should be able to perform JIRA exports too. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. > -Original Message- > From: maurizio.cucchi...@gmail.com > [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara > Sent: Friday, June 10, 2011 8:41 > To: Commons Developers List > Subject: Re: [ognl] Old sources > > IIRC, github conatains the last period of ognl history. > Unfortunately I am afraid that the svn repository has got lost. > > Maurizio Cucchiara > > Il giorno 10/giu/2011 12.06, "Olivier Lamy" > ha scritto: > > Hello, > > Should be here : https://github.com/jkuhnert/ognl > > > > Thanks in advance if you can help for this javacc > > > > 2011/6/10 Jochen Wiedmann : > >> Hi, > >> > >> I notice that the OGNL history hasn't been preserved when > importing > >> the sources into SVN. Is the old repository still around anywhere? > >> I'd like to look for manual changes in the parser. > >> > >> Jochen > >> > >> -- > >> Capitalism is the astounding belief that the most wickedest of men > >> will do the most wickedest of things for the greatest good of > >> everyone. > >> > >> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) > >> > >> > - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > > > -- > > Olivier Lamy > > http://twitter.com/olamy | http://www.linkedin.com/in/olamy > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dormant][commons-graph] or [graph2] What must be the subject line?
Thank you, Rahul. I'm learning the etiquettes of mailing lists :). I was never active on any, before. I may have a few more questions, inquiring about basic things. I hope, my ignorance gets overlooked. Thanks again. Arshad On 10 June 2011 18:53, Rahul Akolkar wrote: > On Fri, Jun 10, 2011 at 9:13 AM, Arshad Ansari > wrote: > > Hello, > > The project commons-graph is being listed under dormant (here > > https://svn.apache.org/repos/asf/commons/dormant/) as graph2. So, when I > > have any questions, the subject line should have [commons-graph] or > > [graph2]. I have a few questions regarding it, but I wanted to have this > one > > cleared first. > > > > > Commons list so "commons-" prefix not needed. If you stick to the > component directory name in SVN, that will always work -- thats > [graph2] -- in this case, [graph] may work too. > > -Rahul > > > > Thanks for the help in advance. > > > > Arshad. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [dormant][commons-graph] or [graph2] What must be the subject line?
On Fri, Jun 10, 2011 at 9:13 AM, Arshad Ansari wrote: > Hello, > The project commons-graph is being listed under dormant (here > https://svn.apache.org/repos/asf/commons/dormant/) as graph2. So, when I > have any questions, the subject line should have [commons-graph] or > [graph2]. I have a few questions regarding it, but I wanted to have this one > cleared first. > Commons list so "commons-" prefix not needed. If you stick to the component directory name in SVN, that will always work -- thats [graph2] -- in this case, [graph] may work too. -Rahul > Thanks for the help in advance. > > Arshad. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
Dormant should be read only. I say move it. On Jun 10, 2011 8:07 AM, "Konstantin Kolinko" wrote: > 2011/6/10 Simone Tripodi : >> In order to avoid any damage... :) >> Can someone confirm that the following command >> >> `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ >> https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph >> resurrected after vote passed >> http://markmail.org/message/mlvqiqhqm2nqhofr"` > > I think it is > svn move https://svn.apache.org/repos/asf/commons/dormant/graph2 > https://svn.apache.org/repos/asf/commons/sandbox/graph2 > > For reference --- I recently used similar command -- you may see "svn > copy" in my proposal for BZ 51249 in Tomcat 6.0 STATUS file [1] There > I create a copy of a new folder that contains test files. I had to > specify source and target names. > > [1]: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/STATUS.txt > > By the way > 1. You may go with "svn copy" and > delete old folder with "svn del" afterwards as a separate command if > everything is OK with the copy. > > 2. Do you really need to mv it to sandbox? There were some voices to > continue development in dormant until the component is ready for a > release. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
[dormant][commons-graph] or [graph2] What must be the subject line?
Hello, The project commons-graph is being listed under dormant (here https://svn.apache.org/repos/asf/commons/dormant/) as graph2. So, when I have any questions, the subject line should have [commons-graph] or [graph2]. I have a few questions regarding it, but I wanted to have this one cleared first. Thanks for the help in advance. Arshad.
Re: [NET] Telnet NTLM Authentication
On 10 June 2011 13:00, abhijeet gaikwad wrote: > Hi Team, > I was able to extend commons-net Telnet API to support NTLM Authentication. > I extended TelnetOptionHandler to create my own AuthTypeHandler for NTLM. > For creating NTLM packets I used JCIFS API. The challenge NTLM message that > I am recieving from the server is more than 256 bytes, but current > commons-net API supports suboption message size upto 256 bytes only. There > is a private integer array in TelnetInputStream named __suboption with size > 256. If I increase the size, my authentication works perfect. > > My question is, is there any specific reason why the array size is 256. Can > it be increased? If I make it 512, my code works. Please suggest me because > if I increase the size, I am able to telnet via a linux machine with NTLM > Authentication by just extending the Telnet client provided in commons-net > API. Otherwise, I will have to reinvent the wheel again ... write a Telnet > client of my own. The size is probably set to 256 because that is large enough for handling existing options. It could be increased, but ideally this would be done in a compatible way. Please register for JIRA and raise an enhancement request. Patches can also be attached to the JIRA. > Thanks, > Abhijeet Gaikwad > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old sources
IIRC, github conatains the last period of ognl history. Unfortunately I am afraid that the svn repository has got lost. Maurizio Cucchiara Il giorno 10/giu/2011 12.06, "Olivier Lamy" ha scritto: > Hello, > Should be here : https://github.com/jkuhnert/ognl > > Thanks in advance if you can help for this javacc > > 2011/6/10 Jochen Wiedmann : >> Hi, >> >> I notice that the OGNL history hasn't been preserved when importing >> the sources into SVN. Is the old repository still around anywhere? I'd >> like to look for manual changes in the parser. >> >> Jochen >> >> -- >> Capitalism is the astounding belief that the most wickedest of men >> will do the most wickedest of things for the greatest good of >> everyone. >> >> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [RESULT] [dormant][vote] resurrect commons-graph
Hi Konstantin, thanks for your kind help! It is fine indeed keeping it in dormant, I'll start working there :P Have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 2:07 PM, Konstantin Kolinko wrote: > 2011/6/10 Simone Tripodi : >> In order to avoid any damage... :) >> Can someone confirm that the following command >> >> `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ >> https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph >> resurrected after vote passed >> http://markmail.org/message/mlvqiqhqm2nqhofr"` > > I think it is > svn move https://svn.apache.org/repos/asf/commons/dormant/graph2 > https://svn.apache.org/repos/asf/commons/sandbox/graph2 > > For reference --- I recently used similar command -- you may see "svn > copy" in my proposal for BZ 51249 in Tomcat 6.0 STATUS file [1] There > I create a copy of a new folder that contains test files. I had to > specify source and target names. > > [1]: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/STATUS.txt > > By the way > 1. You may go with "svn copy" and > delete old folder with "svn del" afterwards as a separate command if > everything is OK with the copy. > > 2. Do you really need to mv it to sandbox? There were some voices to > continue development in dormant until the component is ready for a > release. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old sources
Hi Jochen!!! it would be great!!! Thanks for your help!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 12:05 PM, Olivier Lamy wrote: > Hello, > Should be here : https://github.com/jkuhnert/ognl > > Thanks in advance if you can help for this javacc > > 2011/6/10 Jochen Wiedmann : >> Hi, >> >> I notice that the OGNL history hasn't been preserved when importing >> the sources into SVN. Is the old repository still around anywhere? I'd >> like to look for manual changes in the parser. >> >> Jochen >> >> -- >> Capitalism is the astounding belief that the most wickedest of men >> will do the most wickedest of things for the greatest good of >> everyone. >> >> John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
2011/6/10 Simone Tripodi : > In order to avoid any damage... :) > Can someone confirm that the following command > > `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ > https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph > resurrected after vote passed > http://markmail.org/message/mlvqiqhqm2nqhofr"` I think it is svn move https://svn.apache.org/repos/asf/commons/dormant/graph2 https://svn.apache.org/repos/asf/commons/sandbox/graph2 For reference --- I recently used similar command -- you may see "svn copy" in my proposal for BZ 51249 in Tomcat 6.0 STATUS file [1] There I create a copy of a new folder that contains test files. I had to specify source and target names. [1]: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/STATUS.txt By the way 1. You may go with "svn copy" and delete old folder with "svn del" afterwards as a separate command if everything is OK with the copy. 2. Do you really need to mv it to sandbox? There were some voices to continue development in dormant until the component is ready for a release. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[NET] Telnet NTLM Authentication
Hi Team, I was able to extend commons-net Telnet API to support NTLM Authentication. I extended TelnetOptionHandler to create my own AuthTypeHandler for NTLM. For creating NTLM packets I used JCIFS API. The challenge NTLM message that I am recieving from the server is more than 256 bytes, but current commons-net API supports suboption message size upto 256 bytes only. There is a private integer array in TelnetInputStream named __suboption with size 256. If I increase the size, my authentication works perfect. My question is, is there any specific reason why the array size is 256. Can it be increased? If I make it 512, my code works. Please suggest me because if I increase the size, I am able to telnet via a linux machine with NTLM Authentication by just extending the Telnet client provided in commons-net API. Otherwise, I will have to reinvent the wheel again ... write a Telnet client of my own. Thanks, Abhijeet Gaikwad
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 37 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 13 seconds [INFO] Finished at: Fri Jun 10 11:12:31 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.o
Re: [ognl] Old sources
Hello, Should be here : https://github.com/jkuhnert/ognl Thanks in advance if you can help for this javacc 2011/6/10 Jochen Wiedmann : > Hi, > > I notice that the OGNL history hasn't been preserved when importing > the sources into SVN. Is the old repository still around anywhere? I'd > like to look for manual changes in the parser. > > Jochen > > -- > Capitalism is the astounding belief that the most wickedest of men > will do the most wickedest of things for the greatest good of > everyone. > > John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
Hello Simone, I just had one question. How long would it take for commons-graph to have a git (read-only) mirror? Or will it happen as soon as it is moved from dormant to sandbox? Pardon me, for my ignorance. Being a new comer has its consequences. I'm looking forward to contribute to commons-graph. Thanks and regards, Arshad On 10 June 2011 14:04, Simone Tripodi wrote: > In order to avoid any damage... :) > Can someone confirm that the following command > > `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ > https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph > resurrected after vote passed > http://markmail.org/message/mlvqiqhqm2nqhofr"` > > is the right one I have to use? :) > Many thanks in advance, have a nice day!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jun 10, 2011 at 10:19 AM, Simone Tripodi > wrote: > > Hi all guys, > > the proposal of resurrecting the commons-graph passed, obtaining 8 > > positive votes (5 binding), no +/-0, no -1 > > > > Oliver Heger * > > Phil Steitz * > > Ralph Goers * > > Arshad Ansari > > Ratna Deo Dwivedi > > Luc Maisonobe * > > James Carman * > > Sujit Pal > > > > (* = binding vote) > > > > I'll start moving commons-graph from Dormant to Sandbox ASAP and start > > working on it!!! > > Thanks everybody took part to the vote process! > > All the best, have a nice day!!! > > Simo > > > > http://people.apache.org/~simonetripodi/ > > http://www.99soft.org/ > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[ognl] Old sources
Hi, I notice that the OGNL history hasn't been preserved when importing the sources into SVN. Is the old repository still around anywhere? I'd like to look for manual changes in the parser. Jochen -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
nice tool ! IMHO sounds a nice new component in commons. 2011/6/9 Simone Tripodi : > Hi all guys, > before start working on Digester3 I experimented on GitHub, taking > inspiration from Google Guice APIs, embedded EDSLs in configuration > classess to solve 2 different kind of problems: > > * ClassPath scanning[1]: declare with fluent APIs a class path > scanner, filering classes users are interested in via fluent logic > language, and declaring actions have to be performed, once interested > classes have found. We already discussed about that idea time ago, but > it has been improved; > > * Class scanning[2]: Java users often create framework/libraries > based on Java5 MetaData Annotations interpreted at runtime, the > pattern they usually have to apply is: given a class, visiting all the > class inheritance hierarchy, and getting fields/constructors/methods > for each class; once found an (AnnotatedElement, Annotation) pair, > they have to perform an action. > So, the implemented classes aim to reduce the boilerplate and > redundant code simply by declaring actions that have to be performed > once the pairs (AnnotatedElement, Annotation) are found. > > My proposals are: > > * contributing that codebase, even separately, to existing commons > components, but which ones is not yet clear; > > or > > * donating the code as a separate component directly to Sandbox, > finalizing it then moving eventually to Proper once ready. > > WDYT? Please let me know, have a nice day!!! > Simo > > [1] http://s.apache.org/Ecu > [2] http://s.apache.org/cEf > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Bah ... Sorry. I somehow missed the beginning of the thread and thought this was about bringing Scannotation to Commons. Please, ignore that mail then :) On Fri, Jun 10, 2011 at 10:26, Simone Tripodi wrote: > Hi Torsten!!! > sorry for the silly question, but... which project uses Javassist? > Because the Meiyo codebase is dependencies-less, take a look at the > pom[1]... > Thanks in advance, have a nice day!!! > Simo > > [1] https://github.com/99soft/meiyo/blob/master/pom.xml > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jun 10, 2011 at 10:13 AM, Torsten Curdt wrote: >> Sorry, to rain the party here but AFAICS this project uses javasisst - >> which is LGPL/MPL. So I am not sure using this code is a viable >> option. >> >> It should be quite simple to replace that dependency (see >> https://github.com/tcurdt/jdependency ) though. >> >> cheers, >> Torsten >> >> -- >> http://www.yourdailygeekery.com >> http://www.torstencurdt.com >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.yourdailygeekery.com http://www.torstencurdt.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT] [dormant][vote] resurrect commons-graph
In order to avoid any damage... :) Can someone confirm that the following command `svn move https://svn.apache.org/repos/asf/commons/dormant/graph2/ https://svn.apache.org/repos/asf/commons/sandbox/ -m "commons-graph resurrected after vote passed http://markmail.org/message/mlvqiqhqm2nqhofr"` is the right one I have to use? :) Many thanks in advance, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 10:19 AM, Simone Tripodi wrote: > Hi all guys, > the proposal of resurrecting the commons-graph passed, obtaining 8 > positive votes (5 binding), no +/-0, no -1 > > Oliver Heger * > Phil Steitz * > Ralph Goers * > Arshad Ansari > Ratna Deo Dwivedi > Luc Maisonobe * > James Carman * > Sujit Pal > > (* = binding vote) > > I'll start moving commons-graph from Dormant to Sandbox ASAP and start > working on it!!! > Thanks everybody took part to the vote process! > All the best, have a nice day!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi Torsten!!! sorry for the silly question, but... which project uses Javassist? Because the Meiyo codebase is dependencies-less, take a look at the pom[1]... Thanks in advance, have a nice day!!! Simo [1] https://github.com/99soft/meiyo/blob/master/pom.xml http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 10:13 AM, Torsten Curdt wrote: > Sorry, to rain the party here but AFAICS this project uses javasisst - > which is LGPL/MPL. So I am not sure using this code is a viable > option. > > It should be quite simple to replace that dependency (see > https://github.com/tcurdt/jdependency ) though. > > cheers, > Torsten > > -- > http://www.yourdailygeekery.com > http://www.torstencurdt.com > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT] [dormant][vote] resurrect commons-graph
Hi all guys, the proposal of resurrecting the commons-graph passed, obtaining 8 positive votes (5 binding), no +/-0, no -1 Oliver Heger * Phil Steitz * Ralph Goers * Arshad Ansari Ratna Deo Dwivedi Luc Maisonobe * James Carman * Sujit Pal (* = binding vote) I'll start moving commons-graph from Dormant to Sandbox ASAP and start working on it!!! Thanks everybody took part to the vote process! All the best, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Sorry, to rain the party here but AFAICS this project uses javasisst - which is LGPL/MPL. So I am not sure using this code is a viable option. It should be quite simple to replace that dependency (see https://github.com/tcurdt/jdependency ) though. cheers, Torsten -- http://www.yourdailygeekery.com http://www.torstencurdt.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
On Fri, Jun 10, 2011 at 2:43 AM, Simone Tripodi wrote: > Hi all guys, > thanks for your interest!!! I think that joining our efforts we could > deliver yet another interesting apache-commons feature :) > > @Ralph: I had a look at your stuff and, indeed, yours and mine have a > lot in common!!! Times should be now mature enough to generalize that > concepts and provide a unique, apache-commons solution. > > @Stephen: I recently maintained Discovery but as far as I can > remember, there's no ClassPath scanning resolution. Anyway, sounds > that Discovery would be a good place where contributing the ClassPath > scanner... or not? > > OTOH, the class/annotation scanner could be contributed in Lang... thoughts? > > By the way, if you think it has to be a separate component, I could > start importing in Sanbox, for me it's fine as well!! > > Just a question: do I have to send the Software Grant, before we start > working on it? And we should open a vote, right? AFAIK, yes to both, because the code already exists out in the wild. By contrast, if you had simply started the code in the sandbox and written it there, no grant would be needed. :) Matt > Many thanks in advance, have a nice day!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jun 10, 2011 at 9:30 AM, Stephen Colebourne > wrote: >> I've used scannotation before, which is reasonably well known I >> believe, but could probably be improved on. I think with multiple >> versions at Apache, it is a perfect concept for commons. I would check >> out [discovery] first to see if that has a similar goal. >> >> I'd set it up separately to [lang] first, to see how big it is. It >> feels a little frameworky, but may be suitable for inclusion. >> >> I also think that we should look to include ideas from the old [id] >> project into [lang], as [id] is never going to be released. >> >> Stephen >> >> >> On 10 June 2011 06:19, Ralph Goers wrote: >>> >>> On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: >>> Hi all guys, before start working on Digester3 I experimented on GitHub, taking inspiration from Google Guice APIs, embedded EDSLs in configuration classess to solve 2 different kind of problems: * ClassPath scanning[1]: declare with fluent APIs a class path scanner, filering classes users are interested in via fluent logic language, and declaring actions have to be performed, once interested classes have found. We already discussed about that idea time ago, but it has been improved; * Class scanning[2]: Java users often create framework/libraries based on Java5 MetaData Annotations interpreted at runtime, the pattern they usually have to apply is: given a class, visiting all the class inheritance hierarchy, and getting fields/constructors/methods for each class; once found an (AnnotatedElement, Annotation) pair, they have to perform an action. So, the implemented classes aim to reduce the boilerplate and redundant code simply by declaring actions that have to be performed once the pairs (AnnotatedElement, Annotation) are found. >>> >>> I accomplished this in the work I've been doing on Log4J 2.0 by borrowing >>> on some code I found somewhere else at Apache. You can see it at >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. >>> It is used by >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. >>> >>> Of course, I have no idea if these bear any relationship to what you have >>> done. >>> >>> Ralph >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi Stephen, Stephen Colebourne wrote: > I've used scannotation before, which is reasonably well known I > believe, but could probably be improved on. I think with multiple > versions at Apache, it is a perfect concept for commons. I would check > out [discovery] first to see if that has a similar goal. > > I'd set it up separately to [lang] first, to see how big it is. It > feels a little frameworky, but may be suitable for inclusion. > > I also think that we should look to include ideas from the old [id] > project into [lang], as [id] is never going to be released. I wanted to propose that also for some time now. +1 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
Hi all guys, thanks for your interest!!! I think that joining our efforts we could deliver yet another interesting apache-commons feature :) @Ralph: I had a look at your stuff and, indeed, yours and mine have a lot in common!!! Times should be now mature enough to generalize that concepts and provide a unique, apache-commons solution. @Stephen: I recently maintained Discovery but as far as I can remember, there's no ClassPath scanning resolution. Anyway, sounds that Discovery would be a good place where contributing the ClassPath scanner... or not? OTOH, the class/annotation scanner could be contributed in Lang... thoughts? By the way, if you think it has to be a separate component, I could start importing in Sanbox, for me it's fine as well!! Just a question: do I have to send the Software Grant, before we start working on it? And we should open a vote, right? Many thanks in advance, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 9:30 AM, Stephen Colebourne wrote: > I've used scannotation before, which is reasonably well known I > believe, but could probably be improved on. I think with multiple > versions at Apache, it is a perfect concept for commons. I would check > out [discovery] first to see if that has a similar goal. > > I'd set it up separately to [lang] first, to see how big it is. It > feels a little frameworky, but may be suitable for inclusion. > > I also think that we should look to include ideas from the old [id] > project into [lang], as [id] is never going to be released. > > Stephen > > > On 10 June 2011 06:19, Ralph Goers wrote: >> >> On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: >> >>> Hi all guys, >>> before start working on Digester3 I experimented on GitHub, taking >>> inspiration from Google Guice APIs, embedded EDSLs in configuration >>> classess to solve 2 different kind of problems: >>> >>> * ClassPath scanning[1]: declare with fluent APIs a class path >>> scanner, filering classes users are interested in via fluent logic >>> language, and declaring actions have to be performed, once interested >>> classes have found. We already discussed about that idea time ago, but >>> it has been improved; >>> >>> * Class scanning[2]: Java users often create framework/libraries >>> based on Java5 MetaData Annotations interpreted at runtime, the >>> pattern they usually have to apply is: given a class, visiting all the >>> class inheritance hierarchy, and getting fields/constructors/methods >>> for each class; once found an (AnnotatedElement, Annotation) pair, >>> they have to perform an action. >>> So, the implemented classes aim to reduce the boilerplate and >>> redundant code simply by declaring actions that have to be performed >>> once the pairs (AnnotatedElement, Annotation) are found. >>> >> >> I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on >> some code I found somewhere else at Apache. You can see it at >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. >> It is used by >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. >> >> Of course, I have no idea if these bear any relationship to what you have >> done. >> >> Ralph >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] codebase looking for a place to be contributed to commons
I've used scannotation before, which is reasonably well known I believe, but could probably be improved on. I think with multiple versions at Apache, it is a perfect concept for commons. I would check out [discovery] first to see if that has a similar goal. I'd set it up separately to [lang] first, to see how big it is. It feels a little frameworky, but may be suitable for inclusion. I also think that we should look to include ideas from the old [id] project into [lang], as [id] is never going to be released. Stephen On 10 June 2011 06:19, Ralph Goers wrote: > > On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: > >> Hi all guys, >> before start working on Digester3 I experimented on GitHub, taking >> inspiration from Google Guice APIs, embedded EDSLs in configuration >> classess to solve 2 different kind of problems: >> >> * ClassPath scanning[1]: declare with fluent APIs a class path >> scanner, filering classes users are interested in via fluent logic >> language, and declaring actions have to be performed, once interested >> classes have found. We already discussed about that idea time ago, but >> it has been improved; >> >> * Class scanning[2]: Java users often create framework/libraries >> based on Java5 MetaData Annotations interpreted at runtime, the >> pattern they usually have to apply is: given a class, visiting all the >> class inheritance hierarchy, and getting fields/constructors/methods >> for each class; once found an (AnnotatedElement, Annotation) pair, >> they have to perform an action. >> So, the implemented classes aim to reduce the boilerplate and >> redundant code simply by declaring actions that have to be performed >> once the pairs (AnnotatedElement, Annotation) are found. >> > > I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on > some code I found somewhere else at Apache. You can see it at > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. > It is used by > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. > > Of course, I have no idea if these bear any relationship to what you have > done. > > Ralph > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][Digester] Accept the Digester3 on Sandbox as new Digester
+1 Simone Tripodi wrote: > Hi all guys, > After some month of hard work on Digester3 on Sandbox[1] (and a > failing attempt), I'm here to open a vote to accept the new Digester > APIs be moved on proper /trunk. > The idea is to move the current /trunk in a DIGESTER_2_X branch, then > move the Sandbox on current proper /trunk > > The vote will be open for the next 72 hours and will be closed on July > 12th, at 9:00pm > Please cast your votes, many thanks in advance!! > All the best, have a nice day! > Simo > > [ ] +1, accept the Digester3 on Sandbox as the codebase for the new > [ Digester ] +/- 0 > [ ] -1, because (provide a reason why) > > [1] http://commons.apache.org/sandbox/digester3/ > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
