In case someone missed the thread on general
here is a re-post as Brett suggested...
Thanks for the positive feedback so far.
BTW: How far is the SVN migration?
cheers
--
Torsten
Torsten Curdt wrote:
Hey, folks!
Over at cocoon we have some code that might be worth
sharing on jakarta commons. So I
neral
here is a re-post as Brett suggested...
Thanks for the positive feedback so far.
BTW: How far is the SVN migration?
cheers
--
Torsten
Torsten Curdt wrote:
Hey, folks!
Over at cocoon we have some code that might be worth
sharing on jakarta commons. So I was wondering
if the sandbox is open t
Dmitri Plotnikov wrote:
Dear Shirasu,
Congratulations on this wonderful piece of work and thank you very much for
your decision to contribute it to Apache!
Great stuff!
2. Do we have any licensing issues with XOM?
I believe we can use it, it is covered by LGPL.
If it's LGPL it's not ok as for the c
Dmitri Plotnikov wrote:
Torsten,
Just to clarify the issue: we are not talking about including XOM
with JXPath, we only need it to build against. We would not actually
commit any non-Apache licensed code to the Apache repository. Is
that equally bad?
AFAIK currently even just a simple import stat
I think we will have to wait 'till the issues around the licenses are resolved.
I am very sorry about that.
For now I could put a link on the JXPath home page pointing to your site.
I hope that this issue will be resolved.
A link to my site and any comments are welcome.
Once again, thank you.
Sh
This is a vote thread for migrating commons to SVN. If this vote
I can only express my opinion here. ...but whether I talk
about our experiences over at cocoon or my experiences with
other repositories.
...even if subclipse is not yet comparable with the
excellent cvs client that comes with eclips
Any objections to receiving test cases using junit?
Phil, of course not! :)
...actually it was my plan using junit for that.
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROT
As the subversion changeover for jakarta-commons has gone remarkably
smoothly, I would just like to say thanks to all those who made it
happen, in particular:
Justin Erenkrantz
Tim O'Brien
Henri Yandell
Guys, your hard work is greatly appreciated, and I'm looking forward to
using a 21st-centu
Phil,
thanks for the patch! I did apply some of
it ...see the comments inline
Some notes:
* The simplelog setup wasn't working at all for me for anything less
than info, so I added log4j into the project.xml. Works fine now. Not
sure if you were having a similar problem? junit is also added to
p
* I added a ContinuationException class that can be thrown to clients
using this code instead of stuff like
java.lang.reflect.InvocationTargetException that is dependent on the
underlying bytecode toolkit.
That class was missing in your patch.
Besides I am wondering what you mean
by "dependand on
I've had the need for this ReflectionUtils class in a couple
of projects already. It's also being used within Cocoon.
IMHO it would make sense to have it lang.
..what do you guys think? Should I prepare a patch?
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/javaflow/trunk/src/java/org/apa
Closing an OutputStream twice is a bug or is it indeed nitpicking? ;)
Bummer missed that one :)
That nitpicking was not aimed at your submission.
...it was on a new line on the commit message ;)
Well, the point is that the file writing code is
temporary anyway. I should go away in the near future.
Stephen Colebourne wrote:
By using an interface strategy to find methods I believe that this takes
it out of scope for [lang]. We have tried to restrict lang to tasks that
are non-framework like and non-religious.
I see
I am also being harsh, because there is a [reflect] component in the
sandbox, w
Hi All,
I'm going to be in Vienna, Austria for a few weeks. I just wondered if
anyone here is from thereabouts, as it would be great to meet up with
some fellow jakarta types.
...if you don't want to cut it down to only jakarta
folks it might be worth asking on party@
cheers
--
Torsten
signature.
WHIRLYCOTT wrote:
Torsten Curdt wrote:
Well, the point is that the file writing code is
temporary anyway. I should go away in the near future.
That's why fixing it is not that important.
Yes, I was going to ask about that one... can you let me in on your
plans for this? I agree that it shou
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the "get"s on the map are going
to return an object. That's why I would like
to avoid synchronizing the "get" access.
Now since a "put" might corrupt the
Guys,
thanks everyone for the useful input!
Since this part of the code is really(!)
a hotspot I am really careful with any
additional overhead.
...but looks like I need to have a
closer look into the concurrent package
then.
Regarding the FastHashMap: since the
use is more or less discouraged ...w
While playing with javaflow, I found out the hard way that the
ContinuationClassLoader
is only transforming java that is in a certain package. I made this
Sorry, about that of course that should be made coonfigurable.
patch to transform
classes that implement Continuable and leave the others a
...makes sense
Here's a quick patch to make the eclipse compiler ignore unused
imports. I made it here locally since when testing "scripts", I
sometimes forget to clean up the imports. This seems to help.
Thanks
--
Torsten
signature.asc
Description: OpenPGP digital signature
Art,
of course the compilation might not be finished right after
the instantiation of the classloader. ...jci is using an
asynchronous approach.
Can you explain why you need this? I understand this is
bit of a pain for unit testing but I am not seeing it as
a problem in the real use. ...please expl
First, I thought it might make some sense to make a interface for
Continuation
to implement. Something along the lines of IContinuation, so that we can
reference continuations in a different classloader without loading the
continuation
class itself.
Hm... just wondering whether it you really need
While I did some work with ASM I found it
very nice to work with ...and so I wanted
get rid of a direct BCEL dependency. Which
Fyi, I'm working on porting the current BCEL ClassTransformer over to ASM.
Awesome news! Thanks for the effort!
...but for now I think rewriting on the
package name is qui
it's a little ironic that both richard and i have held that opinion for
a long while now. however, ceki's and brian's investigations are now
starting to persuade me that there is actually some hope for much
improved discovery from the 1.0.x series of releases.
there are a number of subtle issue
Art Gramlich wrote:
> Is there any reason why the Fam thread can't be setDaemon(true) or
> alternately have someway to stop it?
Probably make sense ...I would also like to add the feature so
you can subscribe multiple directories to be monitored. Removing
the last one could stop the thread. ...jus
...so the real question is "is it ok to have a proper component use
maven2" ...right?
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I believe that our users will find "5 == JDK5" to be an easier concept to grasp.
+1
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 10/25/06, James Carman <[EMAIL PROTECTED]> wrote:
For someone who uses Commons Collections a lot in their applications, this
is going to be quite a pain if I want to upgrade. Yes, I realize that
there's such a thing as find and replace, but the fact that I have to do
that if I want to upgrade
> One reason that I proposed (c) is simply that when you say
> "collections5" or "collections2" aloud it sounds like you're talking
> about a version of Collections, whereas if you say
> "commons5-collections" it's more suggestive of a fork, which is what
> we're really trying to get at.
...is i
> Well, easy ...then you don't upgrade ;)
>
> Sorry, but the fact that an upgrade is not always is as easy as
> replacing a jar is not an argument (IMO) As long as there is an
> upgrade path it's up to the user to walk that path or not. The
> important thing though is to have such a path.
This see
I still think that's a better world than package name changing every
time we want to make a non-backwards compatible change.
Frankly speaking - I don't really say a way around this if you want to
save people from dependency hell.
cheers
--
Torsten
--
There are clearly good reasons / circumstances to take the approach
you suggest, but it is a user unfriendly approach. As a user I like to
try out new versions by dropping in a new jar - before taking the
decision to upgrade. This approach rules that out and it wouldn't
surprise me if users starte
On 10/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 10/30/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > There are clearly good reasons / circumstances to take the approach
> > you suggest, but it is a user unfriendly approach. As a user I like to
> > try o
On 11/7/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Stephen Colebourne btopenworld.com> writes:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
I really wonder why this should be a concern of the actual component at
Hi all (but probably mainly to Thorsten :-)
;)
I'd like to reuse the FilesystemAlterationMonitor but without the
Runnable logic in it.
Couldn't we separate the monitoring process from the looping part, so
that the filesystem observation logic could be used lets say with Quartz
to trigger it?
Do you want a Jira entry for the patch?
That would be good!
I've called the splitted class FilesystemAlterationObserver (the one
containing the observation code, and yes, any better naming suggestion
welcome) and left the the FilesystemAlterationMonitor just with the
Runnable logic.
Hm.. no
i would like to make a patch for the homepage. In the commons-compress
section the examples should be replaced with:
http://wiki.apache.org/jakarta-commons/Compress
If you agree, please tell me how can i do this or where i can find
information about to do this.
The homepage is/will get generate
On 29.12.2006, at 16:31, Dennis Lundberg wrote:
Rahul Akolkar wrote:
On 12/29/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
The idea of using a different protocol is fine by me, as long as
I can
continue to use "scp" is I want to. That does seem to be the default
setting. So +1 for that
+1 for both!
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 from me
On 23.01.2007, at 18:30, Niall Pemberton wrote:
+1 from me.
Niall
On 1/23/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
I've made a second release candidate of IO 1.3, tagged IO_1_3_RC2.
Available at:
http://people.apache.org/~bayard/commons-io/1.3-rc2/
Various build files, clir
compress - Despite our attempt to get this released, nothing seems to
have happened here. Anyone?
IMO the API still needs work. I was trying to implement another
archiver and just gave up on it.
With TrueZip working (but being far from perfect either) it is just
very hard to justify the time
On 19.02.2007, at 10:08, Henri Yandell wrote:
On 2/19/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> compress - Despite our attempt to get this released, nothing
seems to
> have happened here. Anyone?
IMO the API still needs work. I was trying to implement another
archiver and
https://issues.apache.org/jira/browse/SANDBOX-106
In my summary this issue is still listed as "open issue assigned to me"
When I drill down into the issue it is already close.
Anyone a clue?
cheers
--
Torsten
-
To unsubscribe,
reason for it.
Hen
On 2/20/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
https://issues.apache.org/jira/browse/SANDBOX-106
In my summary this issue is still listed as "open issue assigned
to me"
When I drill down into the issue it is already close
I would like to know that if ContinuationClassloader is compatible
with the standard ClassLoader mechanism in OSGi runtime environments
(like Knopflerfish,etc).
What's the exact meaning of "compatible" here?
Second question is that can anyone provide me code snippets to
prove that Conti
I would like to know that if ContinuationClassloader is compatible
with the standard ClassLoader mechanism in OSGi runtime environments
(like Knopflerfish,etc).
What's the exact meaning of "compatible" here?
As I understand that Javaflow has a typical class ...bytecode.Stack
object which
Let's assume that I have a class extends Thread and it is complied
and packed in a file of .jar format. Addtionally, I consider the
class as a black box. How can I acquire the continuation object of
this class in any random instant point of time? Is it mandatory to
inject/weave "Continuatio
I've been meaning to do this for a long time. There are a couple of
questions to consider before rolling the release:
1. How should it be built?
Ant, Maven 1 or Maven 2. I've been working on the Maven 2 build and
feel confident about in it now. Was kind of hoping that
logging-1.1.1 would be
Definitely happy to give M2 a try; but I'd rather not change the
groupId on a bugfix release. We already have an M2 release in
FileUpload that didn't change the groupid so that's not a worry. Plus
I want to get it done quickly :)
Ah ...my "+1 for changing the groupId" was not meant for this bug
While I wrote the commons book I've already stumble across some
parser bugs. I always ended up using our own parser implementation.
Now I am trying to get this
http://svn.apache.org/viewvc/jakarta/commons/sandbox/jci/trunk/
examples/src/main/java/org/apache/commons/jci/examples/commandline/
On 16.03.2007, at 05:28, Henri Yandell wrote:
On 3/15/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
IMO we should do a cli 1.0.1 bug release and get then get 2.0 out of
the door ASAP.
Someone needs to have the energy (and comprehension) to push them out.
I get the CLI 1.x code and ca
OK ...so here is the story. There is bug in the 1.0 release of CLI
that I've encountered a couple of times now. This time while I was
writing a "javac" compatible command line interface for the jci
examples. So I thought I have a look at the source, but what a
mess! Just have a look h
I'd like to bring this well before an actual vote.
At the moment I am still in the middle of documenting and fixing up
JCI for a first 1.0 release. I hope to be able to provide a first RC1
at the end of next week ...latest the week after.
There are a few things about JCI that are worth talk
On 17.03.2007, at 15:20, Oleg Kalnichevski wrote:
Folks,
Please correct me if I am wrong, but the auto-discovery mechanism in
Commons Logging is believed to be the only major gripe about JCL.
What happened to the idea of releasing a version of JCL that
retains the
full API compatibility wi
Seems like a bad idea for a Commons component:
* Potential confusion due to version numbers of modules moving
independently etc..
* Its unlikely that releasing one module is significantly easier than
releasing all.
* Its likely that even though after a given quantum of time major
changes are in on
2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be able to have individual releases of the modules.
Suggestio
2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be able to have individual releases of the modules.
Suggestio
Let's check with Oliver on the commons-configuration-integration. I
know that was a subject that's come up a few times (last time I
needed
a cli type thing, I went with configuration and much preferred
it; it
just needs a cli like option).
I had a short glance at this branch (I was not awar
Having fixed the bugs, it seemed to work fine for JMeter, so I thought
it might be useful for others, and so it was provided as a patch for
Commons CLI.
Since JMeter has its own copy, it does not matter to us whether the
CLI copy is ever released, but it seems a shame as it is working well
for us
On 18.03.2007, at 06:51, Mario Ivankovits wrote:
Hi!
I had a quick look at the "filesystem alteration monitor" module -
looks like could be useful component for people outside of JCI.
I was thinking the same. But atm I would rather just get it releases.
That probably means as part of JCI.
Just briefly scanned through ...but I like that direction!
Only suggestion is to rename commons-logging-api to commons-logging-
core ...it has more than just the API definition in it.
cheers
--
Torsten
On 23.03.2007, at 19:56, Boris Unckel wrote:
Hello,
I have seen the recent discussions
As already announced I would like to move
http://jakarta.apache.org/commons/sandbox/jci/
out of the sandbox so I can then prepare a first RC. Please cast your
votes for the graduation!
cheers
--
Torsten
-
To unsubscribe, e
For some reason suddenly I get this nice set of exceptions (see
below) when building
http://jakarta.apache.org/commons/sandbox/jci/
Character 0x0? Would be nice to know in what file. I could not find one
#!/usr/bin/ruby
require 'find'
Find.find('./') do |f|
if ! ( f =~ /.class$/ || f
3/29/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
For some reason suddenly I get this nice set of exceptions (see
below) when building
http://jakarta.apache.org/commons/sandbox/jci/
Character 0x0? Would be nice to know in what file. I could not
find one
#!/usr/bin/ruby
re
3x +1 might be enough ...but that does not really make me feel
optimistic about the release vote ;)
No more?
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Great. So the result is as follows.
+1:
Niall Pemberton
Jörg Schaible
Torsten Curdt
Henri Yandell
Davanum Srinivas
Mario Ivankovits
Oliver Heger
Martin van den Bemt
+0:
Rahul Akolkar
-1: none
...and thereby accepted :)
cheers
--
Torsten
Could someone create a "jci" component in jira please? Would also be
good to move the issues from the sandbox there
https://issues.apache.org/jira/secure/IssueNavigator.jspa?
reset=true&mode=hide&pid=12310491&sorter/order=DESC&sorter/
field=priority&resolution=-1&component=12311185
cheers
-
I've noticed that the plugin versions are not specified in the
commons parent pom. From my experience this is a *really* bad idea as
maven then picks the most recent from local repository. Which again
can easily lead to inconsistent site builds across the team. So if no
one objects I will a
On 01.04.2007, at 18:29, Henri Yandell wrote:
On 4/1/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Could someone create a "jci" component in jira please?
JCI project created.
Would also be
good to move the issues from the sandbox there
https://issues.apache
On 02.04.2007, at 09:49, Stephen Colebourne wrote:
Henri Yandell wrote:
Personally I think we should only have the plugins defined if the
release jar itself needs them for stability.
...and then have the project define the reports they want?
Otherwise we just deal
with whatever pain Maven
Guys,
Do we already have docs on how to do commmons releases with maven2
somewhere?
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 03.04.2007, at 01:34, Phil Steitz wrote:
On 4/2/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Guys,
Do we already have docs on how to do commmons releases with maven2
somewhere?
No. Once [dbcp] is out (pushing it out as we speak), do we expect any
more 1.x releases? If not, we
So I got further. So it looks like this
mvn -Prc release:prepare
mvn -Prc release:perform -Dgpg.passphrase=... -Darguments="-
Dgpg.passphrase=..."
almost does the job. Builds and prepares the whole thing. Even does
the upload BUT
...I cannot find the artifacts in the remote repo (but in
I took a while to get the m2 multi project release build working but
I am glad to announce...
We got "a" first release candiate :)
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
Not even nitpicking on the website or documentation??
I cannot believe I can call a vote on the first RC :)
cheers
--
Torsten
On 04.04.2007, at 21:04, Torsten Curdt wrote:
I took a while to get the m2 multi project release build working
but I am glad to announce...
We got "a&q
Since RC1 is working fine for cocoon and other parties I would like
to call a vote on the release for commons jci.
http://jakarta.apache.org/commons/jci/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-
Feel free to fix :)
...but I fear that would required another RC round then
cheers
--
Torsten
On 11.04.2007, at 18:07, Niall Pemberton wrote:
I'll try and review tonight - if I find any build/site nitpicks do you
mind if I fix them or do you prefer patches?
Niall
On 4/11/07, Torsten
On 11.04.2007, at 23:33, Rahul Akolkar wrote:
On 4/10/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Since RC1 is working fine for cocoon and other parties I would like
to call a vote on the release for commons jci.
http://jakarta.apache.org/commons/jci/
The site menus on all
Niall, really appreciate our input!
On 12.04.2007, at 06:22, Niall Pemberton wrote:
1) NOTICE / LICENSE
The issue raised by Rahul about the missing NOTICE and LICENSE files
gets a bit complex.They are not specified as a "resource" element in
version 2 of the commons parent pom (which AFAIK woul
On 13.04.2007, at 06:22, Niall Pemberton wrote:
I added LICENSE and NOTICE files to all modules - these are now being
included in the generated jars.
I also added assembly to create source and binary distros (not
including JSR199 and Examples - is that correct?).
Awesome Niall! Thanks a lot!
On 12.04.2007, at 19:56, Niall Pemberton wrote:
On 4/12/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Niall, really appreciate our input!
On 12.04.2007, at 06:22, Niall Pemberton wrote:
> 1) NOTICE / LICENSE
> The issue raised by Rahul about the missing NOTICE and LICENSE
fi
On 19.04.2007, at 16:46, Niall Pemberton wrote:
I'd quite like to work on JCI - any objections to adding myself?
Of course not ...sure - go ahead!
If theres a preference for me to start off submiting Jira tickets
rather than directly committing I don't have a problem with that.
Since I only
Great, thanks!
On 19.04.2007, at 16:31, Niall Pemberton wrote:
Found a few source file headers still with copyright statement - hope
you don't mind but I just dived in and fixed them:
http://svn.apache.org/viewvc?view=rev&revision=530425
Niall
On 4/11/07, Torsten Curdt <[EMA
On 06.05.2007, at 19:51, Henri Yandell wrote:
On 5/1/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 5/1/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> On 5/2/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> > (http://wiki.apache.org/jakarta-commons/TLPResolution) and
secondly,
> > anyone
On 15.05.2007, at 23:29, [EMAIL PROTECTED] wrote:
I'm interested in merging some earlier archival work (in C) into
commons
compress and would like to know who to coordinate with. The
changes will
be... substantial... and I'll probably just fork the project for
now, with
a goal of merging
As we talked about on how to do release on at commons I am wondering
if these profiles really make sense:
release
apache.releases
Apache Release Distribution Repository
${commons.deployment.protocol}://people.apache.org/
www/people.apache.org
On 17.05.2007, at 01:52, Henri Yandell wrote:
On 5/16/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
So we would basically always do a
export PASSPHRASE=secret
mvn release:prepare -Prc
mvn release:perform -Prc -Dgpg.passphrase=$PASSPHRASE -
Darguments="-
Prc -Dgpg
On 17.05.2007, at 17:36, Wendy Smoak wrote:
On 5/16/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
As we talked about on how to do release on at commons I am wondering
if these profiles really make sense:
...
rc
apache.snapshots
On 18.05.2007, at 05:13, Bear Giles wrote:
Thorbjørn Ravn Andersen wrote:
I therefore suggest that the tar methods should be migrated to the
vfs module (if suitable) and that the compress module should
contain methods that can compress/uncompress streams (which is
easily extendable to fil
Ehm... could we first sort out the repository question I brought
up? ...and preferably also the related release process?
We should also add the version numbers to the plugins.
I'd say: let's work this out over the weekend and re-start the vote
in a couple of days.
cheers
--
Torsten
On 18.
On 18.05.2007, at 10:44, Jochen Wiedmann wrote:
On 5/18/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Ehm... could we first sort out the repository question I brought
up? ...and preferably also the related release process?
We should also add the version numbers to the plugins.
I
G... why oh why are commmons collection classes inside beanutils?!
@[EMAIL PROTECTED]@
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 5/18/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> G... why oh why are commmons collection classes inside
beanutils?!
http://tinyurl.com/yvma2q
http://tinyurl.com/2hs3hp
Niall
> @[EMAI
On 18.05.2007, at 13:57, Niall Pemberton wrote:
I wasn't part of the decision at the time, but (at least some if not
all) these classes are in the BeanUtils public API so changing the
package would have (and still will) broken binary compatibility (to
remove the dependency on Collections 'coz of
On 18.05.2007, at 18:37, Stephen Colebourne wrote:
Torsten Curdt wrote:
On 18.05.2007, at 13:57, Niall Pemberton wrote:
I wasn't part of the decision at the time, but (at least some if not
all) these classes are in the BeanUtils public API so changing the
package would have (and still
Now this is the part that I don't understand. Why would that have
been an incompatible change? The changes should have been internal to
beanutils.
Because BeanUtils exposes FastHashMap in its public API (and Digester
does the same with ArrayStack) - its the return type from four
methods.
Ahhh
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
Stephen Colebourne skrev den 18-05-2007 18:37:
Changing the package name would have been, and still is, backwards
incompatible. As such it is unacceptable for such a widely used
package as [beanutils]. I am -1 to arbitrarily changin
On 18.05.2007, at 19:17, Bear Giles wrote:
Torsten Curdt wrote:
Hm... seems like I disagree here. I want a simple library that
deals with common compression and archive formats
- tar
- ar
- cpio
- gzip
- bzip2
- zip
VFS is a filesystem abstraction layer. It may use the
library
On 19.05.2007, at 21:37, Stephen Colebourne wrote:
Torsten Curdt wrote:
On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
I suggest marking the offending methods as deprecated for the 1.x
series, and schedule them for removal in the 2.x series.
Well, then let's create a 2.x branc
On every release you (try to) do with maven you learn something new.
That's great - isn't it? :p
Anyway... I am (finally) happy to announce that commmon-jci RC2 is
available at
http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/
apache/commons/commons-jci/1.0/
http://people.ap
1 - 100 of 456 matches
Mail list logo
