You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/10/26 10:27:46 UTC
[io] 1.1 tasks
A starter list:
1) Change ant/maven to exclude finder directory (for 1.1, stays in CVS until
worked on)
2) Check all method names and signatures in FilenameUtils (and any other
class whose first release it is)
3) Decide on whether to merge WildcardUtils with FilenameUtils
4) Check whether there are any other method names we got wrong in 1.0 and we
want to fix now (like CopyUtils)
5) Check jdiff and clirr for compatability
Any more?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] 1.1 tasks
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, 29 Oct 2004 12:49:59 +0100 (BST), Stephen Colebourne
<sc...@btopenworld.com> wrote:
> --- Martin Cooper <mf...@gmail.com> wrote:
> > > 1) Change ant/maven to exclude finder directory
> > (for 1.1, stays in CVS until
> > > worked on)
> >
> > Do we have concensus that it won't be part of 1.1?
> My understanding was that it wasn't finished,
> therefore exculsion was the most appropriate solution.
I'm happy with this. Reviewing the code, there's less to be finished
than I thought.
MaxDepth/MinDepth needs implementing.
Min and Max time options have an additional option of daystart, to
imply when the min and max times are from. This isn't implemented yet.
The Size option currently only does equality, and is in blocks of 512
bytes (copying find command, but no real reason to do this). It needs
to understand > and < and also to ditch the unix 512 byte thing. Also
needs to understand k, m and g as suffixes.
> > > 2) Check all method names and signatures in
> > FilenameUtils (and any other
> > > class whose first release it is)
> >
> > What are we checking for, exactly?
> What I mean by this is 'does the API make sense?',
> 'are the method names the best they could be?'. Its
> not about coding standards.
>
> I include this because on lang and io previous
> releases we have released and then evaluated methods
> for common sense - we should try to do a QA review
> before release.
Jeremais?
All I remember is that it was a mess. Will start digging into it again.
> > > 3) Decide on whether to merge WildcardUtils with
> > FilenameUtils
> >
> > How do we decide that? Why would we? Why would we
> > not?
>
> WildcardUtils is task focussed, so doesn't fit this
> classification, so I would argue for it to be rolled
> into FilenameUtils.
Provided Filename is complete, I'm happy with this.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] 1.1 tasks
Posted by Stephen Colebourne <sc...@btopenworld.com>.
--- Martin Cooper <mf...@gmail.com> wrote:
> > 1) Change ant/maven to exclude finder directory
> (for 1.1, stays in CVS until
> > worked on)
>
> Do we have concensus that it won't be part of 1.1?
My understanding was that it wasn't finished,
therefore exculsion was the most appropriate solution.
> > 2) Check all method names and signatures in
> FilenameUtils (and any other
> > class whose first release it is)
>
> What are we checking for, exactly?
What I mean by this is 'does the API make sense?',
'are the method names the best they could be?'. Its
not about coding standards.
I include this because on lang and io previous
releases we have released and then evaluated methods
for common sense - we should try to do a QA review
before release.
> > 3) Decide on whether to merge WildcardUtils with
> FilenameUtils
>
> How do we decide that? Why would we? Why would we
> not?
At present its MHO that [io] is best with utility
classes focussed on what they work on. Thus, a class
for Stream/WRiter/Reader (IOUtils), one for files
(FileUtils) and one for filenames (FilenameUtils).
WildcardUtils is task focussed, so doesn't fit this
classification, so I would argue for it to be rolled
into FilenameUtils.
> > 4) Check whether there are any other method names
> we got wrong in 1.0 and we
> > want to fix now (like CopyUtils)
>
> Again, what are we checking for, exactly?
See #2. To some degree this is gut feel based on how
usable the library is in real life.
> > 5) Check jdiff and clirr for compatability
>
> Hints on what this means would be appreciated, since
> I have no clue...
We must ensure that 1.1 is source and binary
compatible with 1.0. We use jdiff and clirr to do
this.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] 1.1 tasks
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 26 Oct 2004 09:27:46 +0100, Stephen Colebourne
<sc...@btopenworld.com> wrote:
> A starter list:
>
> 1) Change ant/maven to exclude finder directory (for 1.1, stays in CVS until
> worked on)
Do we have concensus that it won't be part of 1.1? (I've been sick for
a couple of days, and am just now trying to catch up, but I haven't
seen much, if any, discourse on this, beyond the initial suggestion.)
> 2) Check all method names and signatures in FilenameUtils (and any other
> class whose first release it is)
What are we checking for, exactly? I do see some method params marked
'final' and others not. A set of guidelines (wiki page?) would be
useful if we want other people (myself included) to be able to help
out here.
> 3) Decide on whether to merge WildcardUtils with FilenameUtils
How do we decide that? Why would we? Why would we not?
> 4) Check whether there are any other method names we got wrong in 1.0 and we
> want to fix now (like CopyUtils)
Again, what are we checking for, exactly? Can we define "right" and
"wrong" in some way that someone could determine validity and so
provide patches?
> 5) Check jdiff and clirr for compatability
Hints on what this means would be appreciated, since I have no clue...
--
Martin Cooper
>
> Any more?
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org