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 some
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
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 objections?
+1
Thanks for your job :-)
On 7/6/10, Rahul Akolkar rahul.akol...@gmail.com wrote:
2010/7/5 Xun Long Gui ustbco...@gmail.com:
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
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]
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
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
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
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
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=diffrev1=6rev2=7
--
If the vote
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
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=diffrev1=99rev2=100
On Wed, Jul 14, 2010 at 12:30 PM, Simone Tripodi
simone.trip...@gmail.com 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
On Wed, Jul 14, 2010 at 12:37 PM, Fabrizio Morbini fmorb...@gmail.com 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/
snip/
Great, good
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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=372416projectId=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:
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
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/
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 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 Digester
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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=372452projectId=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
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
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
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
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
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
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
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson gudnabr...@gmail.com 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
On Wed, Jul 14, 2010 at 11:07 PM, Matt Benson gudnabr...@gmail.com 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
On Jul 14, 2010, at 10:14 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:12 PM, Matt Benson
gudnabr...@gmail.com 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
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson gudnabr...@gmail.com 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
On Jul 14, 2010, at 10:45 PM, James Carman wrote:
On Wed, Jul 14, 2010 at 11:27 PM, Matt Benson
gudnabr...@gmail.com 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
On Wed, Jul 14, 2010 at 11:52 PM, Matt Benson gudnabr...@gmail.com 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
34 matches
Mail list logo
