On Wed, Jul 14, 2010 at 11:52 PM, Matt Benson wrote:
> Easier to just follow a rule then debate about special cases, IMO. Do it!
Yeah, I'm one of the ones who is kind of a stickler on this list about
renaming packages, so I guess I should go ahead and do it. That way,
it stays consistent.
On Jul 14, 2010, at 10:45 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson
wrote:
This is in the neighborhood, but let me drop some stuff in there
tomorrow so
we can do a little CTR. :D
I am splitting proxy into multiple modules right now and I'll check it
into tha
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson wrote:
> This is in the neighborhood, but let me drop some stuff in there tomorrow so
> we can do a little CTR. :D
>
I am splitting proxy into multiple modules right now and I'll check it
into that branch so that folks can see what I have in mind as
On Jul 14, 2010, at 10:14 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson
wrote:
I would support [proxy] becoming a multi-module project; among
other things
we could selectively have a larger set of dependencies this way.
How would
you feel about the module that co
On Wed, Jul 14, 2010 at 11:07 PM, Matt Benson wrote:
> I believe that's the code I originally pulled in [lang] for TypeUtils.
> However, since the latest contributions I've merged, the [lang] one now far
> surpasses the handling in [proxy]. So I know the recording is there, but I
> hadn't tracke
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson wrote:
> I would support [proxy] becoming a multi-module project; among other things
> we could selectively have a larger set of dependencies this way. How would
> you feel about the module that contains the recording functionality
> depending on [lan
On Jul 14, 2010, at 9:21 PM, James Carman wrote:
All,
One of the biggest complaints I've received from folks about the proxy
library is that it's not based on interfaces.
What is the typical basis of a complaint? I.e., what problem does
the abstract class cause?
The main class is the
P
On Jul 14, 2010, at 9:15 PM, James Carman wrote:
Well, the proxy code needs a bit of work. First, I'd say, I need to
rollback the serializability requirement for all generated proxies.
It's easy enough to make your proxies serializable if you just add
java.io.Serializable to the list of classe
All,
One of the biggest complaints I've received from folks about the proxy
library is that it's not based on interfaces. The main class is the
ProxyFactory class and it's a concrete class which implements all
proxying logic using JDK proxies. We did this for maintainability
(adding stuff to the
Well, the proxy code needs a bit of work. First, I'd say, I need to
rollback the serializability requirement for all generated proxies.
It's easy enough to make your proxies serializable if you just add
java.io.Serializable to the list of classes/interfaces you want
proxied (I'll put in a test cas
James,
What's the status of the genericized proxy 2.0 branch? I think the code I
talked about yesterday is basically a fancy way to describe building an
Interceptor. So proxy might be a good home for it. It's not really limited to
annotations anyway, though I could see providing a subclass
Something went wrong with Continuum when I tried to add the Net build
originally - the site said it was busy or undergoing maintenance.
I tried again later and succeeded, but it looks like the first build
had actually been created.
Hopefully I've deleted the second build definition which is the o
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=372452&projectId=2704
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Wed 14 Jul 2010 03:36:20 -0700
Finished at: Wed 14 Jul 2010 03:41:42 -0700
Total time: 5m 21s
Build Trigg
There are still a few Commons components that have yet to change to
the groupId "org.apache.commons".
These are not automatically included in Nexus - AIUI each groupId is
enabled separately.
The ones that still appear to be using their own groupIds are:
beanutils betwixt chain cli (*) codec coll
Hi James,
the commons-digester library is IMHO still an excellent XML->Object
mapper even JAXB is, of course, most popular and more adopted.
Otherwise that project could be deprecated :P
By definition, the Object->XML is not supported, from the
commons-digester homepage[1]: "Basically, the Digeste
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "CommonsGroupids" page has been changed by sebbapache.
The comment on this change is: GroupIds and Nexus plans.
http://wiki.apache.org/commons/CommonsGroupids
-
Hi Rahul,
thanks for your reply, very appreciated :) during the next 2 weeks,
when you'll be away, I'll try to complete what is missing so when
you'll come back we could start importing the new stuff.
Have a nice day, best regards,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.or
There is only one Daemon release in the Maven repo as far as I can
make out - 1.0.1 - which is from way back in Jakarta time.
AIUI, there are no plans to make any further releases to Maven
repositories, because the component is not really useful as a Maven
dependency.
However, the groupId is curr
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=372416&projectId=2704
Build statistics:
State: Ok
Previous Build: No previous build.
Started at: Wed 14 Jul 2010 01:36:27 -0700
Finished at: Wed 14 Jul 2010 01:38:32 -0700
Total time: 2m 4s
Build Trigger: S
Why not just use JAXB 2.0 which includes annotations? What itch does
this code scratch that hasn't been done already? Does your code
support going from the objects to the XML? Most of the time when you
have these XML -> object situations, it's nice to be able to go the
other way, also (such as i
On Wed, Jul 14, 2010 at 12:37 PM, Fabrizio Morbini wrote:
> Hi, we got the approval the release our visual editor i mentioned a
> few weeks back. If you are interested in using/testing/contributing_to
> it, it is available at: http://code.google.com/p/scxmlgui/
>
Great, good to know. Two comment
On Wed, Jul 14, 2010 at 12:30 PM, Simone Tripodi
wrote:
> Hi all guys, Digester maintainers,
> time ago[1] I proposed a sandbox[1] to work on a new feature for the
> digester, adding the Java5 Annotation analysis to create Digester
> rules.
> I didn't have the need to modify the original digester
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "FrontPage" page has been changed by sebbapache.
The comment on this change is: Add links to Nexus and Groupids.
http://wiki.apache.org/commons/FrontPage?action=diff&rev1=99&rev2=10
Hi, we got the approval the release our visual editor i mentioned a
few weeks back. If you are interested in using/testing/contributing_to
it, it is available at: http://code.google.com/p/scxmlgui/
thanks,
fabrizio.
-
To unsubscr
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "UsingNexus" page has been changed by sebbapache.
http://wiki.apache.org/commons/UsingNexus?action=diff&rev1=6&rev2=7
--
If the v
Hi all guys, Digester maintainers,
time ago[1] I proposed a sandbox[1] to work on a new feature for the
digester, adding the Java5 Annotation analysis to create Digester
rules.
I didn't have the need to modify the original digester code, but
rather I added a new package where adding the new feature
Some change in Ant has broken the property handling in the Jelly/Ant
integration. By manually replacing jars in my local repository I found
out that the tests pass with Ant 1.8.0 but fail with 1.8.1.
Given that Ant's property handling has changed dramatically in 1.8.x and
Ant even marked this as
I don't know what triggered the test failures, but in some cases tests
now fail because the order of namespace declarations is different from
the expected order - while the XML documents themselves should
semantically be the same.
Is anybody interested on looking into this or should we disable the
it looks as if the jaxme taglib was incompatible with newer versions of
jaxme which isn't too surprising.
It doesn't look as if anybody was interested in keeping Jelly
up-to-date, shall we remove the Gump build of the jaxme tags?
Stefan
---
The 2.x codeline is now the main codeline, so as agreed, I've swapped
the SVN locations around.
The 2.x codeline is now at:
https://svn.apache.org/repos/asf/commons/proper/net/trunk
If you have an SVN workspace for NET 2, you need to run svn switch on it:
svn switch [path] https://svn.apache.org
Thanks for your job :-)
On 7/6/10, Rahul Akolkar wrote:
> 2010/7/5 Xun Long Gui :
>> Hi Rahul,
>>
>> By now, everything of GSoC Visual SCXML project is going well with our
>> initial plan. This project have this function list:
>> 1. Implement Eclipse GMF based SCXML document visual editor tool;
>
Le 14/07/2010 10:22, Jörg Schaible a écrit :
> sebb wrote:
>
>> There does not seem to be any need for a further release of the NET
>> 1.x line, which is currently the trunk version, so I propose to:
>>
>> * rename trunk as branches/NET_1_x
>> * rename branches/NET_2_0 as trunk
>>
>> Any objection
On 2010-07-12, sebb wrote:
> There does not seem to be any need for a further release of the NET
> 1.x line, which is currently the trunk version, so I propose to:
> * rename trunk as branches/NET_1_x
> * rename branches/NET_2_0 as trunk
+1
A while back the Ant folks were informed that the FTP
sebb wrote:
> There does not seem to be any need for a further release of the NET
> 1.x line, which is currently the trunk version, so I propose to:
>
> * rename trunk as branches/NET_1_x
> * rename branches/NET_2_0 as trunk
>
> Any objections?
+1
it's never good if the head revision is on som
34 matches
Mail list logo
