You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2008/01/06 02:51:52 UTC
[IO] Planning IO 1.4 release
I would like to get an IO 1.4 release out in the near future. Looking
thru the issues tagged for 1.4 I would suggest the following:
1) Resolve the following issues, which all have patches except IO-149
which is trivial
IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
IO-105 - Add a FileUtils.copyDirectoryStructure method
IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
IO-135 - Add convenience deleteQuietly to FileUtils
2) Move the following issues to post-1.4
IO-137 - Added method for getting InputStream from
ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
and copy
IO-51 - Throttled input and output stream classes
IO-77 - add a convenience FileUtils.move(File src, File dest)
3) Upgrade to commons-parent-6 pom.xml which looks like the release
will be approved shortly
Thoughts on this?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 6, 2008 2:33 AM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > -----Original Message-----
> > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > Sent: Saturday, January 05, 2008 5:52 PM
> > To: Commons Developers List
> > Subject: [IO] Planning IO 1.4 release
> >
> > I would like to get an IO 1.4 release out in the near future. Looking
> > thru the issues tagged for 1.4 I would suggest the following:
> >
> > 1) Resolve the following issues, which all have patches except IO-149
> > which is trivial
> > IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > IO-105 - Add a FileUtils.copyDirectoryStructure method
> > IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > IO-135 - Add convenience deleteQuietly to FileUtils
>
> Seems like a good idea. +1 here.
>
> > 2) Move the following issues to post-1.4
> > IO-137 - Added method for getting InputStream from
> > ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > and copy
> > IO-51 - Throttled input and output stream classes
> > IO-77 - add a convenience FileUtils.move(File src, File dest)
>
> I do like this type of planning as it allows us to 'release early, release often' ;-)
>
> >
> > 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > will be approved shortly
>
> As long we do not wait for the pom.xml to be released, that's fine with me.
The vote will be concluded in a few hours so unless there is a rush of
-1s I hope to complete the release tommorrow.
Niall
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [IO] Planning IO 1.4 release
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Saturday, January 05, 2008 5:52 PM
> To: Commons Developers List
> Subject: [IO] Planning IO 1.4 release
>
> I would like to get an IO 1.4 release out in the near future. Looking
> thru the issues tagged for 1.4 I would suggest the following:
>
> 1) Resolve the following issues, which all have patches except IO-149
> which is trivial
> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> IO-105 - Add a FileUtils.copyDirectoryStructure method
> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> IO-135 - Add convenience deleteQuietly to FileUtils
Seems like a good idea. +1 here.
> 2) Move the following issues to post-1.4
> IO-137 - Added method for getting InputStream from
> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> and copy
> IO-51 - Throttled input and output stream classes
> IO-77 - add a convenience FileUtils.move(File src, File dest)
I do like this type of planning as it allows us to 'release early, release often' ;-)
>
> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> will be approved shortly
As long we do not wait for the pom.xml to be released, that's fine with me.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 8, 2008 1:00 AM, sebb <se...@gmail.com> wrote:
>
> On 08/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > On Jan 8, 2008 12:40 AM, sebb <se...@gmail.com> wrote:
> > >
> > > On 06/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > > > On Jan 6, 2008 6:18 PM, sebb <se...@gmail.com> wrote:
> > > > >
> > > > > On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> > > > > > Henri Yandell wrote:
> > > > > > > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > > > > >> I would like to get an IO 1.4 release out in the near future. Looking
> > > > > > >> thru the issues tagged for 1.4 I would suggest the following:
> > > > > > >>
> > > > > > >> 1) Resolve the following issues, which all have patches except IO-149
> > > > > > >> which is trivial
> > > > > > >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > > > > > >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> > > > > > >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > > > > > >> IO-135 - Add convenience deleteQuietly to FileUtils
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > >> 2) Move the following issues to post-1.4
> > > > > > >> IO-137 - Added method for getting InputStream from
> > > > > > >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > > > > > >> and copy
> > > > > > >> IO-51 - Throttled input and output stream classes
> > > > > > >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> > > > > > >
> > > > > > > +1 on IO-77 being post-1.4 as it lacks unit tests.
> > > > > > >
> > > > > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > > > > comes with tests. I'll volunteer to look at that.
> > > > > > >
> > > > > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > > > > > >
> > > > > > >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > > > > > >> will be approved shortly
> > > > > > >>
> > > > > > >> Thoughts on this?
> > > > > > >
> > > > > > > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
> > > > > >
> > > > > > For the Logging release I documented in RELEASE-NOTES.txt that the M1
> > > > > > build was deprecated and that it will be removed in a future release. If
> > > > > > it is still working that can be a smooth transition. Deprecate it and
> > > > > > remove it in the next release, or just remove it straight away.
> > > > > >
> > > > > > There is an Ant plugin for M2 as well. I haven't used it myself, but I
> > > > > > could have a go at it, if we think it'd be good to still have a basic
> > > > > > Ant build around.
> > > > > >
> > > > > > > And IO-148 + IO-127?
> > > > > > >
> > > > > > > Hen
> > > > > >
> > > > >
> > > > > I could not work out from the current web-site which versions of Java
> > > > > are supported.
> > > >
> > > > Theres a note about it in the release notes:
> > > >
> > > > http://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txt
> > > >
> > > > > Seems to me this should be added to the dependencies page.
> > > >
> > > > I've always thought that, but thats maven generated don't know how we
> > > > could do that?
> > >
> > > Where are the existing dependencies listed?
> >
> > In the pom.xml /project.xml and a maven plugin generates a report from
> > them - but I don't know of a way to have it list the JDK version in
> > either m1 or m2.
>
> What happens if you just add a dependency on "java"?
Firstly, maven dependencies need to be in the maven repo - and I don't
think java is - so the build would fail. Even if it was I'm sure it
would play havoc with maven which add dependencies to the classpath.
Niall
> > > > > Also, the current dependencies page lists junit as a run-time
> > > > > dependency, which seems wrong.
> > > >
> > > > Again thats a m1 issue. With m2 it does a better job with the
> > > > <scope>test</scope> on the generated page.
> > > >
> > >
> > > What about using <comment>?
> > >
> > > e.g. as used in commons-pool 1.4RC2.
> >
> > No need, just need to re-generate the site using m2 (rather than m1) -
> > and my plan ATM is to do the IO 1.4 release with m2.
> >
> > Niall
> >
> > > > > IClasses need documentation on whether they are thread-safe or not.
> > > >
> > > > Better docs are always nice but it needs someone to step up and do it.
> > > > If someone does then great, otherwise it [IO-134] should get moved to
> > > > post-1.4 IMO
> > > >
> > > > Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by sebb <se...@gmail.com>.
On 08/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Jan 8, 2008 12:40 AM, sebb <se...@gmail.com> wrote:
> >
> > On 06/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > > On Jan 6, 2008 6:18 PM, sebb <se...@gmail.com> wrote:
> > > >
> > > > On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> > > > > Henri Yandell wrote:
> > > > > > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > > > >> I would like to get an IO 1.4 release out in the near future. Looking
> > > > > >> thru the issues tagged for 1.4 I would suggest the following:
> > > > > >>
> > > > > >> 1) Resolve the following issues, which all have patches except IO-149
> > > > > >> which is trivial
> > > > > >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > > > > >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> > > > > >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > > > > >> IO-135 - Add convenience deleteQuietly to FileUtils
> > > > > >
> > > > > > +1
> > > > > >
> > > > > >> 2) Move the following issues to post-1.4
> > > > > >> IO-137 - Added method for getting InputStream from
> > > > > >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > > > > >> and copy
> > > > > >> IO-51 - Throttled input and output stream classes
> > > > > >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> > > > > >
> > > > > > +1 on IO-77 being post-1.4 as it lacks unit tests.
> > > > > >
> > > > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > > > comes with tests. I'll volunteer to look at that.
> > > > > >
> > > > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > > > > >
> > > > > >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > > > > >> will be approved shortly
> > > > > >>
> > > > > >> Thoughts on this?
> > > > > >
> > > > > > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
> > > > >
> > > > > For the Logging release I documented in RELEASE-NOTES.txt that the M1
> > > > > build was deprecated and that it will be removed in a future release. If
> > > > > it is still working that can be a smooth transition. Deprecate it and
> > > > > remove it in the next release, or just remove it straight away.
> > > > >
> > > > > There is an Ant plugin for M2 as well. I haven't used it myself, but I
> > > > > could have a go at it, if we think it'd be good to still have a basic
> > > > > Ant build around.
> > > > >
> > > > > > And IO-148 + IO-127?
> > > > > >
> > > > > > Hen
> > > > >
> > > >
> > > > I could not work out from the current web-site which versions of Java
> > > > are supported.
> > >
> > > Theres a note about it in the release notes:
> > >
> > > http://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txt
> > >
> > > > Seems to me this should be added to the dependencies page.
> > >
> > > I've always thought that, but thats maven generated don't know how we
> > > could do that?
> >
> > Where are the existing dependencies listed?
>
> In the pom.xml /project.xml and a maven plugin generates a report from
> them - but I don't know of a way to have it list the JDK version in
> either m1 or m2.
What happens if you just add a dependency on "java"?
> > > > Also, the current dependencies page lists junit as a run-time
> > > > dependency, which seems wrong.
> > >
> > > Again thats a m1 issue. With m2 it does a better job with the
> > > <scope>test</scope> on the generated page.
> > >
> >
> > What about using <comment>?
> >
> > e.g. as used in commons-pool 1.4RC2.
>
> No need, just need to re-generate the site using m2 (rather than m1) -
> and my plan ATM is to do the IO 1.4 release with m2.
>
> Niall
>
> > > > IClasses need documentation on whether they are thread-safe or not.
> > >
> > > Better docs are always nice but it needs someone to step up and do it.
> > > If someone does then great, otherwise it [IO-134] should get moved to
> > > post-1.4 IMO
> > >
> > > Niall
> > >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 8, 2008 12:40 AM, sebb <se...@gmail.com> wrote:
>
> On 06/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > On Jan 6, 2008 6:18 PM, sebb <se...@gmail.com> wrote:
> > >
> > > On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> > > > Henri Yandell wrote:
> > > > > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > > >> I would like to get an IO 1.4 release out in the near future. Looking
> > > > >> thru the issues tagged for 1.4 I would suggest the following:
> > > > >>
> > > > >> 1) Resolve the following issues, which all have patches except IO-149
> > > > >> which is trivial
> > > > >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > > > >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> > > > >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > > > >> IO-135 - Add convenience deleteQuietly to FileUtils
> > > > >
> > > > > +1
> > > > >
> > > > >> 2) Move the following issues to post-1.4
> > > > >> IO-137 - Added method for getting InputStream from
> > > > >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > > > >> and copy
> > > > >> IO-51 - Throttled input and output stream classes
> > > > >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> > > > >
> > > > > +1 on IO-77 being post-1.4 as it lacks unit tests.
> > > > >
> > > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > > comes with tests. I'll volunteer to look at that.
> > > > >
> > > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > > > >
> > > > >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > > > >> will be approved shortly
> > > > >>
> > > > >> Thoughts on this?
> > > > >
> > > > > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
> > > >
> > > > For the Logging release I documented in RELEASE-NOTES.txt that the M1
> > > > build was deprecated and that it will be removed in a future release. If
> > > > it is still working that can be a smooth transition. Deprecate it and
> > > > remove it in the next release, or just remove it straight away.
> > > >
> > > > There is an Ant plugin for M2 as well. I haven't used it myself, but I
> > > > could have a go at it, if we think it'd be good to still have a basic
> > > > Ant build around.
> > > >
> > > > > And IO-148 + IO-127?
> > > > >
> > > > > Hen
> > > >
> > >
> > > I could not work out from the current web-site which versions of Java
> > > are supported.
> >
> > Theres a note about it in the release notes:
> >
> > http://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txt
> >
> > > Seems to me this should be added to the dependencies page.
> >
> > I've always thought that, but thats maven generated don't know how we
> > could do that?
>
> Where are the existing dependencies listed?
In the pom.xml /project.xml and a maven plugin generates a report from
them - but I don't know of a way to have it list the JDK version in
either m1 or m2.
> > > Also, the current dependencies page lists junit as a run-time
> > > dependency, which seems wrong.
> >
> > Again thats a m1 issue. With m2 it does a better job with the
> > <scope>test</scope> on the generated page.
> >
>
> What about using <comment>?
>
> e.g. as used in commons-pool 1.4RC2.
No need, just need to re-generate the site using m2 (rather than m1) -
and my plan ATM is to do the IO 1.4 release with m2.
Niall
> > > IClasses need documentation on whether they are thread-safe or not.
> >
> > Better docs are always nice but it needs someone to step up and do it.
> > If someone does then great, otherwise it [IO-134] should get moved to
> > post-1.4 IMO
> >
> > Niall
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by sebb <se...@gmail.com>.
On 06/01/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Jan 6, 2008 6:18 PM, sebb <se...@gmail.com> wrote:
> >
> > On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> > > Henri Yandell wrote:
> > > > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > >> I would like to get an IO 1.4 release out in the near future. Looking
> > > >> thru the issues tagged for 1.4 I would suggest the following:
> > > >>
> > > >> 1) Resolve the following issues, which all have patches except IO-149
> > > >> which is trivial
> > > >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > > >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> > > >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > > >> IO-135 - Add convenience deleteQuietly to FileUtils
> > > >
> > > > +1
> > > >
> > > >> 2) Move the following issues to post-1.4
> > > >> IO-137 - Added method for getting InputStream from
> > > >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > > >> and copy
> > > >> IO-51 - Throttled input and output stream classes
> > > >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> > > >
> > > > +1 on IO-77 being post-1.4 as it lacks unit tests.
> > > >
> > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > comes with tests. I'll volunteer to look at that.
> > > >
> > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > > >
> > > >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > > >> will be approved shortly
> > > >>
> > > >> Thoughts on this?
> > > >
> > > > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
> > >
> > > For the Logging release I documented in RELEASE-NOTES.txt that the M1
> > > build was deprecated and that it will be removed in a future release. If
> > > it is still working that can be a smooth transition. Deprecate it and
> > > remove it in the next release, or just remove it straight away.
> > >
> > > There is an Ant plugin for M2 as well. I haven't used it myself, but I
> > > could have a go at it, if we think it'd be good to still have a basic
> > > Ant build around.
> > >
> > > > And IO-148 + IO-127?
> > > >
> > > > Hen
> > >
> >
> > I could not work out from the current web-site which versions of Java
> > are supported.
>
> Theres a note about it in the release notes:
>
> http://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txt
>
> > Seems to me this should be added to the dependencies page.
>
> I've always thought that, but thats maven generated don't know how we
> could do that?
Where are the existing dependencies listed?
> > Also, the current dependencies page lists junit as a run-time
> > dependency, which seems wrong.
>
> Again thats a m1 issue. With m2 it does a better job with the
> <scope>test</scope> on the generated page.
>
What about using <comment>?
e.g. as used in commons-pool 1.4RC2.
> > IClasses need documentation on whether they are thread-safe or not.
>
> Better docs are always nice but it needs someone to step up and do it.
> If someone does then great, otherwise it [IO-134] should get moved to
> post-1.4 IMO
>
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 6, 2008 6:18 PM, sebb <se...@gmail.com> wrote:
>
> On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> > Henri Yandell wrote:
> > > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > >> I would like to get an IO 1.4 release out in the near future. Looking
> > >> thru the issues tagged for 1.4 I would suggest the following:
> > >>
> > >> 1) Resolve the following issues, which all have patches except IO-149
> > >> which is trivial
> > >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> > >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > >> IO-135 - Add convenience deleteQuietly to FileUtils
> > >
> > > +1
> > >
> > >> 2) Move the following issues to post-1.4
> > >> IO-137 - Added method for getting InputStream from
> > >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > >> and copy
> > >> IO-51 - Throttled input and output stream classes
> > >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> > >
> > > +1 on IO-77 being post-1.4 as it lacks unit tests.
> > >
> > > I think we should deal with IO-137 as it's a minor enhancement and
> > > comes with tests. I'll volunteer to look at that.
> > >
> > > IO-51 has tests, so worth a look at if that can be done before the
> > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > >
> > >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > >> will be approved shortly
> > >>
> > >> Thoughts on this?
> > >
> > > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
> >
> > For the Logging release I documented in RELEASE-NOTES.txt that the M1
> > build was deprecated and that it will be removed in a future release. If
> > it is still working that can be a smooth transition. Deprecate it and
> > remove it in the next release, or just remove it straight away.
> >
> > There is an Ant plugin for M2 as well. I haven't used it myself, but I
> > could have a go at it, if we think it'd be good to still have a basic
> > Ant build around.
> >
> > > And IO-148 + IO-127?
> > >
> > > Hen
> >
>
> I could not work out from the current web-site which versions of Java
> are supported.
Theres a note about it in the release notes:
http://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txt
> Seems to me this should be added to the dependencies page.
I've always thought that, but thats maven generated don't know how we
could do that?
> Also, the current dependencies page lists junit as a run-time
> dependency, which seems wrong.
Again thats a m1 issue. With m2 it does a better job with the
<scope>test</scope> on the generated page.
> IClasses need documentation on whether they are thread-safe or not.
Better docs are always nice but it needs someone to step up and do it.
If someone does then great, otherwise it [IO-134] should get moved to
post-1.4 IMO
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by sebb <se...@gmail.com>.
On 06/01/2008, Dennis Lundberg <de...@apache.org> wrote:
> Henri Yandell wrote:
> > On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> >> I would like to get an IO 1.4 release out in the near future. Looking
> >> thru the issues tagged for 1.4 I would suggest the following:
> >>
> >> 1) Resolve the following issues, which all have patches except IO-149
> >> which is trivial
> >> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> >> IO-105 - Add a FileUtils.copyDirectoryStructure method
> >> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> >> IO-135 - Add convenience deleteQuietly to FileUtils
> >
> > +1
> >
> >> 2) Move the following issues to post-1.4
> >> IO-137 - Added method for getting InputStream from
> >> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> >> and copy
> >> IO-51 - Throttled input and output stream classes
> >> IO-77 - add a convenience FileUtils.move(File src, File dest)
> >
> > +1 on IO-77 being post-1.4 as it lacks unit tests.
> >
> > I think we should deal with IO-137 as it's a minor enhancement and
> > comes with tests. I'll volunteer to look at that.
> >
> > IO-51 has tests, so worth a look at if that can be done before the
> > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> >
> >> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> >> will be approved shortly
> >>
> >> Thoughts on this?
> >
> > Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
>
> For the Logging release I documented in RELEASE-NOTES.txt that the M1
> build was deprecated and that it will be removed in a future release. If
> it is still working that can be a smooth transition. Deprecate it and
> remove it in the next release, or just remove it straight away.
>
> There is an Ant plugin for M2 as well. I haven't used it myself, but I
> could have a go at it, if we think it'd be good to still have a basic
> Ant build around.
>
> > And IO-148 + IO-127?
> >
> > Hen
>
I could not work out from the current web-site which versions of Java
are supported.
Seems to me this should be added to the dependencies page.
Also, the current dependencies page lists junit as a run-time
dependency, which seems wrong.
IClasses need documentation on whether they are thread-safe or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
>> I would like to get an IO 1.4 release out in the near future. Looking
>> thru the issues tagged for 1.4 I would suggest the following:
>>
>> 1) Resolve the following issues, which all have patches except IO-149
>> which is trivial
>> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
>> IO-105 - Add a FileUtils.copyDirectoryStructure method
>> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
>> IO-135 - Add convenience deleteQuietly to FileUtils
>
> +1
>
>> 2) Move the following issues to post-1.4
>> IO-137 - Added method for getting InputStream from
>> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
>> and copy
>> IO-51 - Throttled input and output stream classes
>> IO-77 - add a convenience FileUtils.move(File src, File dest)
>
> +1 on IO-77 being post-1.4 as it lacks unit tests.
>
> I think we should deal with IO-137 as it's a minor enhancement and
> comes with tests. I'll volunteer to look at that.
>
> IO-51 has tests, so worth a look at if that can be done before the
> others are resolved. ie) punt to post-1.4 iff it's the last one left.
>
>> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
>> will be approved shortly
>>
>> Thoughts on this?
>
> Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
For the Logging release I documented in RELEASE-NOTES.txt that the M1
build was deprecated and that it will be removed in a future release. If
it is still working that can be a smooth transition. Deprecate it and
remove it in the next release, or just remove it straight away.
There is an Ant plugin for M2 as well. I haven't used it myself, but I
could have a go at it, if we think it'd be good to still have a basic
Ant build around.
> And IO-148 + IO-127?
>
> Hen
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 9, 2008 11:04 AM, Niall Pemberton <ni...@gmail.com> wrote:
> Henri and Jukka expressed interest on IO-137 - do you guys
> want to / have time to look at this?
Let's move it to post-1.4. The reset() issue still needs some thought
and probably shouldn't be rushed.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/9/08, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Jan 9, 2008 10:39 PM, Niall Pemberton <ni...@gmail.com> wrote:
>
> > Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>
> Yes, please!
>
<snip/>
Makes sense to me as well.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 9, 2008 10:39 PM, Niall Pemberton <ni...@gmail.com> wrote:
> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
Yes, please!
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/9/08, Dennis Lundberg <de...@apache.org> wrote:
<snip/>
> >> https://svn.apache.org/viewvc?view=rev&revision=610444
> >
> > Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>
> No, not in my opinion. We've agreed to disagree on which way to go with
> this. There are two option, each with its merits and flaws.
>
> A) Use maven-remote-resources-plugin
> B) Keep manually edited files in SVN and copy them manually to the
> correct places
>
> If supporting one of these (A) isn't allowed in the parent pom, then why
> should the other (B) be supported?
>
<snap/>
Because some variant of (B), such as the one you propose below (if it
works), will be amenable to many (though I stopped following all this
too closely, so that may just be what I gather).
-Rahul
>
> Anyway, on to the problem at hand here. I just found another antrun
> execution in IO:s pom, in the release profile. There's some code in
> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
> NOTICE.txt files. That could probably be removed now.
>
> But it just struck me - we've been going about this the wrong way! The
> plugins that we use (jar, javadoc, source) supports remote resources. So
> let us use that functionality instead of trying to create it ourselves.
> It's dead simple really: we create an antrun execution, much like the
> one I made, that copies our *local* resources to the same place that the
> remote-resources-plugin copies its resources to.
>
>
> <plugin>
> <!--
> - Copy LICENSE.txt and NOTICE.txt so that they are included
> - in distribution jar files.
> -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.1</version>
> <executions>
> <execution>
> <id>local.resources</id>
> <phase>generate-sources</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <tasks>
> <copy
> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
> <fileset dir="${basedir}">
> <include name="LICENSE.txt" />
> <include name="NOTICE.txt" />
> </fileset>
> </copy>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> I haven't tried this for real, but will play around with it and see if
> it would work.
>
> WDYT?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] IO 1.4 on Java 1.3 , IO 1.5 on Java 1.4
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 10, 2008 6:14 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Hello:
>
> I would like to propose simplifying the code and current release by:
>
> - Keeping IO 1.4 on Java 1.3 only. This means removing the Java 1.4 conditional code execution.
There isn't any conditional code execution - just four classes that
use Java 1.4 features - the rest is 1.3 compatible. We did discuss
this a couple of times - the latest here:
https://issues.apache.org/jira/browse/IO-127
I'm -1 to your propoal at this stage and for keeping what we have
which IMO is ready to release as it is now - just need to update the
docs and cut an RC. I was hoping/planning to do that in the next day
or so.
Niall
> - Setting the requirement for IO 1.5 on Java 1.4, allowing NIO implementations at will.
>
> Thoughts? Is this something we should [vote] on?
>
> Thanks,
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] project.xml name element inconsistency
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/10/08, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Hello all:
>
> I am seeing two types of names in project.xml name elements. For a project "Foo":
>
> - Foo
> - Commons Foo
>
> Can we standardize one pattern for all [commons] projects?
>
> Current examples:
>
> Codec (SVN)
> Commons Pool (SVN)
> FileUpload (1.2.1 rc3)
> IO (SVN)
> Lang (SVN)
>
> Over the two, I would pick "Commons Foo".
>
<snip/>
Me too.
-Rahul
> In project.xml there is no slot for a container project like "Commons". When I build a list of projects based on the names, the missing "Commons" prefix messes up the order.
>
> Thanks,
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[all] project.xml name element inconsistency
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Hello all:
I am seeing two types of names in project.xml name elements. For a project "Foo":
- Foo
- Commons Foo
Can we standardize one pattern for all [commons] projects?
Current examples:
Codec (SVN)
Commons Pool (SVN)
FileUpload (1.2.1 rc3)
IO (SVN)
Lang (SVN)
Over the two, I would pick "Commons Foo".
In project.xml there is no slot for a container project like "Commons". When I build a list of projects based on the names, the missing "Commons" prefix messes up the order.
Thanks,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Jan 10, 2008 1:38 AM, Niall Pemberton <ni...@gmail.com> wrote:
>> On Jan 10, 2008 12:25 AM, Dennis Lundberg <de...@apache.org> wrote:
>>> Niall Pemberton wrote:
>>>> On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>> Niall Pemberton wrote:
>>>>>>>>> OK so now were down to agreeing the exception in IO-77 - once thats
>>>>>>>>> done I can cut an RC.
>>>>>>>>>
>>>>>>>>> I'm starting to think that with the javadoc.jar Notice/License issue I
>>>>>>>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
>>>>>>>>> too much time battling with m2 recently).
>>>>>>>> Problem solved in r610444:
>>>>>>>> https://svn.apache.org/viewvc?view=rev&revision=610444
>>>>>>> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>>>>>> No, not in my opinion. We've agreed to disagree on which way to go with
>>>>>> this. There are two option, each with its merits and flaws.
>>>>>>
>>>>>> A) Use maven-remote-resources-plugin
>>>>>> B) Keep manually edited files in SVN and copy them manually to the
>>>>>> correct places
>>>>>>
>>>>>> If supporting one of these (A) isn't allowed in the parent pom, then why
>>>>>> should the other (B) be supported?
>>>>>>
>>>>>>
>>>>>> Anyway, on to the problem at hand here. I just found another antrun
>>>>>> execution in IO:s pom, in the release profile. There's some code in
>>>>>> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
>>>>>> NOTICE.txt files. That could probably be removed now.
>>>>>>
>>>>>> But it just struck me - we've been going about this the wrong way! The
>>>>>> plugins that we use (jar, javadoc, source) supports remote resources. So
>>>>>> let us use that functionality instead of trying to create it ourselves.
>>>>>> It's dead simple really: we create an antrun execution, much like the
>>>>>> one I made, that copies our *local* resources to the same place that the
>>>>>> remote-resources-plugin copies its resources to.
>>>> Also because supporting (B) doesn't prevent (A) - whereas the other
>>>> way, supporting (A) screws up (B).
>>> It seems that we keep misunderstanding each other. The last thing I
>>> proposed to support (A) was to add maven-remote-resources-plugin to
>>> pluginManagement. This makes sure that all projects that inherits from
>>> commons-parent and *uses* maven-remote-resources-plugin, will use the
>>> same version of said plugin. Nothing more. So nothing in that prevents
>>> (B) from working.
>>>
>>> I'm all for solutions that can support one approach, as long as it
>>> doesn't prevent other approaches.
>> Fair enough, my mis-understanding - I thought you were talking about
>> the whole remote-resources config rather than just the version in
>> plugin management. To be honest the main reason I didn't want to put
>> it back at that time was that it was during the vote for
>> commons-parent-6 and I didn't want it held up for something that I
>> believe we had decided not to use. I guess the fact that I screwed up
>> that release makes it quite funny.
>
> OK I just checked out the fileupload release when Jochen has used that
> plugin (via commons-parent-5) - so if people are going to use it we
> should put the version in the plugin management so that the builds
> re-createable. As an additional note we need to upgrade the javadoc
> plugin version in commons=parent as it requires 2.3 to include the
> Notice/License from remote resources.
+1 to both those changes.
> Niall
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 10, 2008 1:38 AM, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Jan 10, 2008 12:25 AM, Dennis Lundberg <de...@apache.org> wrote:
> >
> > Niall Pemberton wrote:
> > > On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > >> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >>> Niall Pemberton wrote:
> > >>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >>>>> Niall Pemberton wrote:
> > >>>>>> OK so now were down to agreeing the exception in IO-77 - once thats
> > >>>>>> done I can cut an RC.
> > >>>>>>
> > >>>>>> I'm starting to think that with the javadoc.jar Notice/License issue I
> > >>>>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> > >>>>>> too much time battling with m2 recently).
> > >>>>> Problem solved in r610444:
> > >>>>> https://svn.apache.org/viewvc?view=rev&revision=610444
> > >>>> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
> > >>> No, not in my opinion. We've agreed to disagree on which way to go with
> > >>> this. There are two option, each with its merits and flaws.
> > >>>
> > >>> A) Use maven-remote-resources-plugin
> > >>> B) Keep manually edited files in SVN and copy them manually to the
> > >>> correct places
> > >>>
> > >>> If supporting one of these (A) isn't allowed in the parent pom, then why
> > >>> should the other (B) be supported?
> > >>>
> > >>>
> > >>> Anyway, on to the problem at hand here. I just found another antrun
> > >>> execution in IO:s pom, in the release profile. There's some code in
> > >>> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
> > >>> NOTICE.txt files. That could probably be removed now.
> > >>>
> > >>> But it just struck me - we've been going about this the wrong way! The
> > >>> plugins that we use (jar, javadoc, source) supports remote resources. So
> > >>> let us use that functionality instead of trying to create it ourselves.
> > >>> It's dead simple really: we create an antrun execution, much like the
> > >>> one I made, that copies our *local* resources to the same place that the
> > >>> remote-resources-plugin copies its resources to.
> > >
> > > Also because supporting (B) doesn't prevent (A) - whereas the other
> > > way, supporting (A) screws up (B).
> >
> > It seems that we keep misunderstanding each other. The last thing I
> > proposed to support (A) was to add maven-remote-resources-plugin to
> > pluginManagement. This makes sure that all projects that inherits from
> > commons-parent and *uses* maven-remote-resources-plugin, will use the
> > same version of said plugin. Nothing more. So nothing in that prevents
> > (B) from working.
> >
> > I'm all for solutions that can support one approach, as long as it
> > doesn't prevent other approaches.
>
> Fair enough, my mis-understanding - I thought you were talking about
> the whole remote-resources config rather than just the version in
> plugin management. To be honest the main reason I didn't want to put
> it back at that time was that it was during the vote for
> commons-parent-6 and I didn't want it held up for something that I
> believe we had decided not to use. I guess the fact that I screwed up
> that release makes it quite funny.
OK I just checked out the fileupload release when Jochen has used that
plugin (via commons-parent-5) - so if people are going to use it we
should put the version in the plugin management so that the builds
re-createable. As an additional note we need to upgrade the javadoc
plugin version in commons=parent as it requires 2.3 to include the
Notice/License from remote resources.
Niall
> > >
> > > Niall
> > >
> > >>> <plugin>
> > >>> <!--
> > >>> - Copy LICENSE.txt and NOTICE.txt so that they are included
> > >>> - in distribution jar files.
> > >>> -->
> > >>> <groupId>org.apache.maven.plugins</groupId>
> > >>> <artifactId>maven-antrun-plugin</artifactId>
> > >>> <version>1.1</version>
> > >>> <executions>
> > >>> <execution>
> > >>> <id>local.resources</id>
> > >>> <phase>generate-sources</phase>
> > >>> <goals>
> > >>> <goal>run</goal>
> > >>> </goals>
> > >>> <configuration>
> > >>> <tasks>
> > >>> <copy
> > >>> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
> > >>> <fileset dir="${basedir}">
> > >>> <include name="LICENSE.txt" />
> > >>> <include name="NOTICE.txt" />
> > >>> </fileset>
> > >>> </copy>
> > >>> </tasks>
> > >>> </configuration>
> > >>> </execution>
> > >>> </executions>
> > >>> </plugin>
> > >>>
> > >>> I haven't tried this for real, but will play around with it and see if
> > >>> it would work.
> > >> I tried it and it didn't seem to work, but I could be doing something
> > >> wrong. My guess is that the javadoc plugin only collects defined
> > >> "resources" that are in that directory which is why the antrun soln
> > >> didn't work.
> >
> > You are right. I have experimented a bit and studied the source code for
> > the plugins. What maven-remote-resources-plugin does is inject the
> > remotely fetched resources into the resources in the (in memory) pom. So
> > what I proposed above will not work.
> >
> > The antrun that I put in svn is working fine though for the javadoc-jar.
> > Commons-io has some other antrun executions, as I mentioned before,
> > which makes the sources jar work. It's a hack, but it seems to do its
> > job. I will remove (from svn) the now superfluous antrun that rejars the
> > -javadoc jar file.
> >
> > >> On the issue of whether the other antrun solution should go in the
> > >> commons-parent pom - then I think the remote resources argument was
> > >> lost at this point and we should have a solution that works for the
> > >> whole of commons and therefore it should go in commons-parent -
> > >> otherwise we need to duplicate that solution in every component which
> > >> doesn't use remote resources. That kind of thing is going to put
> > >> people off making the switch to m2, whereas we should be trying to
> > >> make it as easy, issue free as possible.
> >
> > My standpoint on this is that we should not put everything into
> > commons-parent *right away*. The fact that we are still learning m2,
> > supports this. First we try something new out in one component. If that
> > works out well (after a full release cycle) then we can start do discuss
> > moving those bits into commons-parent.
>
> But thats not what happened with remote-resources which you put into
> commons-parent - which caused duplicate LICENSE and NOTICE files and
> garbage in the NOTICE file. I've tested this change on commons Chain,
> both with the normal setup and by deleting the NOTICE/LICENSE file and
> configuring the remote-resources plugin. Both worked OK. I think we
> should put it in - if down the road a problem appears then fixing it
> and doing a release is not that big a deal.
>
> So at the moment three people (Jochen, Rahul and myself) think it
> should go in and one (Dennis) is against - I'll leave it a while for
> other opinions, but if the majority agree then I'll commit it.
>
> > I'm trying my best here to help with the migration to m2. If we are
>
> Despite all recent argument, it is appreciated and I hope I haven't
> upset you too much.
>
> > going to migrate successfully we need to take many small steps.
> > Sometimes we must also be able to take a leap and adjust our file-names
> > (just an example) to make them work *together* with m2 instead of the
> > opposite. We must dare to let go of the past.
>
> I assume your talking about removing the ".txt" extensions from the
> NOTICE and LICENSE files. Firstly at least some of us think its more
> (windows) user-friendly to keep them. Secondly using Validator as an
> example - it currently has three working build systems - ant, m1 and
> m2 - so renaming the files to make m2 more easily means fixing the ant
> and m1 builds as well - and correcting at least one other build is
> going to apply to most other components as well, unless we wait until
> all are on m2. I think we need working m2 builds to encourage
> components to make the switch (and I've done quite a bit to help with
> that) and so a less invassive solution is needed which I proposed in
> MRRESOURCES-31. Its not maven were working against with this issue -
> its the apache-jar-resource-bundle. I believe that if the maven team
> does MRRESOURCES-31 and the dependencies meta-data (i.e. poms) get
> fixed so the contents of the NOTICE file are good - then I think you'd
> have a better chance of persuading commons to adopt remote-resources.
> It doesn't then leave much argument against using it - or at least
> making it available in commons parent.
>
> Niall
>
>
> > Easy and issue free sound good to me.
> >
> > >>
> > >> Niall
> > >>
> > >>
> > >>> WDYT?
> > >>>
> > >>>> Niall
> > >>>>
> > >>>
> > >>> <snip/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [IO] Planning IO 1.4 release
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, January 10, 2008 2:50 PM
> To: Jakarta Commons Developers List
> Subject: Re: [IO] Planning IO 1.4 release
>
> Dennis Lundberg wrote:
> > I just feel that there is sooo much discussion necessary to pull
> > something off here in commons. We have a saying in Sweden that sums it
> > up, but I'm not sure how it works after translation. It goes something
> > like this:
> >
> > "Much talk, but no work"
> >
> > I wish that some of the energy that goes into the discussions would go
> > into actual coding instead...
>
> <rant>
> So do I, but my opinion is that had we never ever used maven in commons,
> and only ever used ant we would have been *much* better off. (And so
> would our users, as they would have more up to date components to use,
> do to more real coding time being available).
Tangent: As long as I can build components with Ant (build jars and run tests) that's all I really need. So, let's not take that nice simple way of doings away.
>
> I'd love someone to analyse what threads actually occur on commons. It
> feels like 50% are just about maven and builds, and that is crazy for a
> tool that is meant to reduce the workload.
> </rant>
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Dennis Lundberg wrote:
> I just feel that there is sooo much discussion necessary to pull
> something off here in commons. We have a saying in Sweden that sums it
> up, but I'm not sure how it works after translation. It goes something
> like this:
>
> "Much talk, but no work"
>
> I wish that some of the energy that goes into the discussions would go
> into actual coding instead...
<rant>
So do I, but my opinion is that had we never ever used maven in commons,
and only ever used ant we would have been *much* better off. (And so
would our users, as they would have more up to date components to use,
do to more real coding time being available).
I'd love someone to analyse what threads actually occur on commons. It
feels like 50% are just about maven and builds, and that is crazy for a
tool that is meant to reduce the workload.
</rant>
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Jan 10, 2008 12:25 AM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>>> On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> OK so now were down to agreeing the exception in IO-77 - once thats
>>>>>>>> done I can cut an RC.
>>>>>>>>
>>>>>>>> I'm starting to think that with the javadoc.jar Notice/License issue I
>>>>>>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
>>>>>>>> too much time battling with m2 recently).
>>>>>>> Problem solved in r610444:
>>>>>>> https://svn.apache.org/viewvc?view=rev&revision=610444
>>>>>> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>>>>> No, not in my opinion. We've agreed to disagree on which way to go with
>>>>> this. There are two option, each with its merits and flaws.
>>>>>
>>>>> A) Use maven-remote-resources-plugin
>>>>> B) Keep manually edited files in SVN and copy them manually to the
>>>>> correct places
>>>>>
>>>>> If supporting one of these (A) isn't allowed in the parent pom, then why
>>>>> should the other (B) be supported?
>>>>>
>>>>>
>>>>> Anyway, on to the problem at hand here. I just found another antrun
>>>>> execution in IO:s pom, in the release profile. There's some code in
>>>>> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
>>>>> NOTICE.txt files. That could probably be removed now.
>>>>>
>>>>> But it just struck me - we've been going about this the wrong way! The
>>>>> plugins that we use (jar, javadoc, source) supports remote resources. So
>>>>> let us use that functionality instead of trying to create it ourselves.
>>>>> It's dead simple really: we create an antrun execution, much like the
>>>>> one I made, that copies our *local* resources to the same place that the
>>>>> remote-resources-plugin copies its resources to.
>>> Also because supporting (B) doesn't prevent (A) - whereas the other
>>> way, supporting (A) screws up (B).
>> It seems that we keep misunderstanding each other. The last thing I
>> proposed to support (A) was to add maven-remote-resources-plugin to
>> pluginManagement. This makes sure that all projects that inherits from
>> commons-parent and *uses* maven-remote-resources-plugin, will use the
>> same version of said plugin. Nothing more. So nothing in that prevents
>> (B) from working.
>>
>> I'm all for solutions that can support one approach, as long as it
>> doesn't prevent other approaches.
>
> Fair enough, my mis-understanding - I thought you were talking about
> the whole remote-resources config rather than just the version in
> plugin management. To be honest the main reason I didn't want to put
> it back at that time was that it was during the vote for
> commons-parent-6 and I didn't want it held up for something that I
> believe we had decided not to use. I guess the fact that I screwed up
> that release makes it quite funny.
:-)
>>> Niall
>>>
>>>>> <plugin>
>>>>> <!--
>>>>> - Copy LICENSE.txt and NOTICE.txt so that they are included
>>>>> - in distribution jar files.
>>>>> -->
>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>> <artifactId>maven-antrun-plugin</artifactId>
>>>>> <version>1.1</version>
>>>>> <executions>
>>>>> <execution>
>>>>> <id>local.resources</id>
>>>>> <phase>generate-sources</phase>
>>>>> <goals>
>>>>> <goal>run</goal>
>>>>> </goals>
>>>>> <configuration>
>>>>> <tasks>
>>>>> <copy
>>>>> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
>>>>> <fileset dir="${basedir}">
>>>>> <include name="LICENSE.txt" />
>>>>> <include name="NOTICE.txt" />
>>>>> </fileset>
>>>>> </copy>
>>>>> </tasks>
>>>>> </configuration>
>>>>> </execution>
>>>>> </executions>
>>>>> </plugin>
>>>>>
>>>>> I haven't tried this for real, but will play around with it and see if
>>>>> it would work.
>>>> I tried it and it didn't seem to work, but I could be doing something
>>>> wrong. My guess is that the javadoc plugin only collects defined
>>>> "resources" that are in that directory which is why the antrun soln
>>>> didn't work.
>> You are right. I have experimented a bit and studied the source code for
>> the plugins. What maven-remote-resources-plugin does is inject the
>> remotely fetched resources into the resources in the (in memory) pom. So
>> what I proposed above will not work.
>>
>> The antrun that I put in svn is working fine though for the javadoc-jar.
>> Commons-io has some other antrun executions, as I mentioned before,
>> which makes the sources jar work. It's a hack, but it seems to do its
>> job. I will remove (from svn) the now superfluous antrun that rejars the
>> -javadoc jar file.
>>
>>>> On the issue of whether the other antrun solution should go in the
>>>> commons-parent pom - then I think the remote resources argument was
>>>> lost at this point and we should have a solution that works for the
>>>> whole of commons and therefore it should go in commons-parent -
>>>> otherwise we need to duplicate that solution in every component which
>>>> doesn't use remote resources. That kind of thing is going to put
>>>> people off making the switch to m2, whereas we should be trying to
>>>> make it as easy, issue free as possible.
>> My standpoint on this is that we should not put everything into
>> commons-parent *right away*. The fact that we are still learning m2,
>> supports this. First we try something new out in one component. If that
>> works out well (after a full release cycle) then we can start do discuss
>> moving those bits into commons-parent.
>
> But thats not what happened with remote-resources which you put into
> commons-parent - which caused duplicate LICENSE and NOTICE files and
> garbage in the NOTICE file.
Right, that was a bad thing to do, and it was me who did it. Apart from
that it's an excellent example of what *not* to do ;-) Messing around
with the parent until something is tried and tested can lead to unwanted
effects.
> I've tested this change on commons Chain,
> both with the normal setup and by deleting the NOTICE/LICENSE file and
> configuring the remote-resources plugin. Both worked OK. I think we
> should put it in - if down the road a problem appears then fixing it
> and doing a release is not that big a deal.
It's good that it works for both setups.
> So at the moment three people (Jochen, Rahul and myself) think it
> should go in and one (Dennis) is against - I'll leave it a while for
> other opinions, but if the majority agree then I'll commit it.
That's what votes are for.
>> I'm trying my best here to help with the migration to m2. If we are
>
> Despite all recent argument, it is appreciated and I hope I haven't
> upset you too much.
I just feel that there is sooo much discussion necessary to pull
something off here in commons. We have a saying in Sweden that sums it
up, but I'm not sure how it works after translation. It goes something
like this:
"Much talk, but no work"
I wish that some of the energy that goes into the discussions would go
into actual coding instead...
>> going to migrate successfully we need to take many small steps.
>> Sometimes we must also be able to take a leap and adjust our file-names
>> (just an example) to make them work *together* with m2 instead of the
>> opposite. We must dare to let go of the past.
>
> I assume your talking about removing the ".txt" extensions from the
> NOTICE and LICENSE files. Firstly at least some of us think its more
> (windows) user-friendly to keep them. Secondly using Validator as an
> example - it currently has three working build systems - ant, m1 and
> m2 - so renaming the files to make m2 more easily means fixing the ant
> and m1 builds as well - and correcting at least one other build is
> going to apply to most other components as well, unless we wait until
> all are on m2.
That is a sign that it's time to make a jump, in this case drop support
for at least one of the three build systems. IMO if a component switches
to m2 it's time to drop the m1 support in that component. My comment was
meant generally, the file extensions was just an illustrative example.
> I think we need working m2 builds to encourage
> components to make the switch (and I've done quite a bit to help with
> that) and so a less invassive solution is needed which I proposed in
> MRRESOURCES-31. Its not maven were working against with this issue -
> its the apache-jar-resource-bundle.
Again, if you have to jump through too many hoops to make it happen,
it's sign that something is wrong. We're bending over backwards to
maintain one-to-many build systems.
> I believe that if the maven team
> does MRRESOURCES-31 and the dependencies meta-data (i.e. poms) get
> fixed so the contents of the NOTICE file are good - then I think you'd
> have a better chance of persuading commons to adopt remote-resources.
> It doesn't then leave much argument against using it - or at least
> making it available in commons parent.
The metadata is the most serious flaw with using
remote-resources-plugin, because it is difficult for us to fix. But for
components with zero dependencies, which is rather common (!) here in
commons, using the remote-resources-plugin should work fine.
> Niall
>
>> Easy and issue free sound good to me.
>>
>>>> Niall
>>>>
>>>>
>>>>> WDYT?
>>>>>
>>>>>> Niall
>>>>>>
>>>>> <snip/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[IO] IO 1.4 on Java 1.3 , IO 1.5 on Java 1.4
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Hello:
I would like to propose simplifying the code and current release by:
- Keeping IO 1.4 on Java 1.3 only. This means removing the Java 1.4 conditional code execution.
- Setting the requirement for IO 1.5 on Java 1.4, allowing NIO implementations at will.
Thoughts? Is this something we should [vote] on?
Thanks,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 10, 2008 12:25 AM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
> >> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>> Niall Pemberton wrote:
> >>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>>> Niall Pemberton wrote:
> >>>>>> OK so now were down to agreeing the exception in IO-77 - once thats
> >>>>>> done I can cut an RC.
> >>>>>>
> >>>>>> I'm starting to think that with the javadoc.jar Notice/License issue I
> >>>>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> >>>>>> too much time battling with m2 recently).
> >>>>> Problem solved in r610444:
> >>>>> https://svn.apache.org/viewvc?view=rev&revision=610444
> >>>> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
> >>> No, not in my opinion. We've agreed to disagree on which way to go with
> >>> this. There are two option, each with its merits and flaws.
> >>>
> >>> A) Use maven-remote-resources-plugin
> >>> B) Keep manually edited files in SVN and copy them manually to the
> >>> correct places
> >>>
> >>> If supporting one of these (A) isn't allowed in the parent pom, then why
> >>> should the other (B) be supported?
> >>>
> >>>
> >>> Anyway, on to the problem at hand here. I just found another antrun
> >>> execution in IO:s pom, in the release profile. There's some code in
> >>> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
> >>> NOTICE.txt files. That could probably be removed now.
> >>>
> >>> But it just struck me - we've been going about this the wrong way! The
> >>> plugins that we use (jar, javadoc, source) supports remote resources. So
> >>> let us use that functionality instead of trying to create it ourselves.
> >>> It's dead simple really: we create an antrun execution, much like the
> >>> one I made, that copies our *local* resources to the same place that the
> >>> remote-resources-plugin copies its resources to.
> >
> > Also because supporting (B) doesn't prevent (A) - whereas the other
> > way, supporting (A) screws up (B).
>
> It seems that we keep misunderstanding each other. The last thing I
> proposed to support (A) was to add maven-remote-resources-plugin to
> pluginManagement. This makes sure that all projects that inherits from
> commons-parent and *uses* maven-remote-resources-plugin, will use the
> same version of said plugin. Nothing more. So nothing in that prevents
> (B) from working.
>
> I'm all for solutions that can support one approach, as long as it
> doesn't prevent other approaches.
Fair enough, my mis-understanding - I thought you were talking about
the whole remote-resources config rather than just the version in
plugin management. To be honest the main reason I didn't want to put
it back at that time was that it was during the vote for
commons-parent-6 and I didn't want it held up for something that I
believe we had decided not to use. I guess the fact that I screwed up
that release makes it quite funny.
> >
> > Niall
> >
> >>> <plugin>
> >>> <!--
> >>> - Copy LICENSE.txt and NOTICE.txt so that they are included
> >>> - in distribution jar files.
> >>> -->
> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> <artifactId>maven-antrun-plugin</artifactId>
> >>> <version>1.1</version>
> >>> <executions>
> >>> <execution>
> >>> <id>local.resources</id>
> >>> <phase>generate-sources</phase>
> >>> <goals>
> >>> <goal>run</goal>
> >>> </goals>
> >>> <configuration>
> >>> <tasks>
> >>> <copy
> >>> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
> >>> <fileset dir="${basedir}">
> >>> <include name="LICENSE.txt" />
> >>> <include name="NOTICE.txt" />
> >>> </fileset>
> >>> </copy>
> >>> </tasks>
> >>> </configuration>
> >>> </execution>
> >>> </executions>
> >>> </plugin>
> >>>
> >>> I haven't tried this for real, but will play around with it and see if
> >>> it would work.
> >> I tried it and it didn't seem to work, but I could be doing something
> >> wrong. My guess is that the javadoc plugin only collects defined
> >> "resources" that are in that directory which is why the antrun soln
> >> didn't work.
>
> You are right. I have experimented a bit and studied the source code for
> the plugins. What maven-remote-resources-plugin does is inject the
> remotely fetched resources into the resources in the (in memory) pom. So
> what I proposed above will not work.
>
> The antrun that I put in svn is working fine though for the javadoc-jar.
> Commons-io has some other antrun executions, as I mentioned before,
> which makes the sources jar work. It's a hack, but it seems to do its
> job. I will remove (from svn) the now superfluous antrun that rejars the
> -javadoc jar file.
>
> >> On the issue of whether the other antrun solution should go in the
> >> commons-parent pom - then I think the remote resources argument was
> >> lost at this point and we should have a solution that works for the
> >> whole of commons and therefore it should go in commons-parent -
> >> otherwise we need to duplicate that solution in every component which
> >> doesn't use remote resources. That kind of thing is going to put
> >> people off making the switch to m2, whereas we should be trying to
> >> make it as easy, issue free as possible.
>
> My standpoint on this is that we should not put everything into
> commons-parent *right away*. The fact that we are still learning m2,
> supports this. First we try something new out in one component. If that
> works out well (after a full release cycle) then we can start do discuss
> moving those bits into commons-parent.
But thats not what happened with remote-resources which you put into
commons-parent - which caused duplicate LICENSE and NOTICE files and
garbage in the NOTICE file. I've tested this change on commons Chain,
both with the normal setup and by deleting the NOTICE/LICENSE file and
configuring the remote-resources plugin. Both worked OK. I think we
should put it in - if down the road a problem appears then fixing it
and doing a release is not that big a deal.
So at the moment three people (Jochen, Rahul and myself) think it
should go in and one (Dennis) is against - I'll leave it a while for
other opinions, but if the majority agree then I'll commit it.
> I'm trying my best here to help with the migration to m2. If we are
Despite all recent argument, it is appreciated and I hope I haven't
upset you too much.
> going to migrate successfully we need to take many small steps.
> Sometimes we must also be able to take a leap and adjust our file-names
> (just an example) to make them work *together* with m2 instead of the
> opposite. We must dare to let go of the past.
I assume your talking about removing the ".txt" extensions from the
NOTICE and LICENSE files. Firstly at least some of us think its more
(windows) user-friendly to keep them. Secondly using Validator as an
example - it currently has three working build systems - ant, m1 and
m2 - so renaming the files to make m2 more easily means fixing the ant
and m1 builds as well - and correcting at least one other build is
going to apply to most other components as well, unless we wait until
all are on m2. I think we need working m2 builds to encourage
components to make the switch (and I've done quite a bit to help with
that) and so a less invassive solution is needed which I proposed in
MRRESOURCES-31. Its not maven were working against with this issue -
its the apache-jar-resource-bundle. I believe that if the maven team
does MRRESOURCES-31 and the dependencies meta-data (i.e. poms) get
fixed so the contents of the NOTICE file are good - then I think you'd
have a better chance of persuading commons to adopt remote-resources.
It doesn't then leave much argument against using it - or at least
making it available in commons parent.
Niall
> Easy and issue free sound good to me.
>
> >>
> >> Niall
> >>
> >>
> >>> WDYT?
> >>>
> >>>> Niall
> >>>>
> >>>
> >>> <snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
>> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> Niall Pemberton wrote:
>>>> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> OK so now were down to agreeing the exception in IO-77 - once thats
>>>>>> done I can cut an RC.
>>>>>>
>>>>>> I'm starting to think that with the javadoc.jar Notice/License issue I
>>>>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
>>>>>> too much time battling with m2 recently).
>>>>> Problem solved in r610444:
>>>>> https://svn.apache.org/viewvc?view=rev&revision=610444
>>>> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>>> No, not in my opinion. We've agreed to disagree on which way to go with
>>> this. There are two option, each with its merits and flaws.
>>>
>>> A) Use maven-remote-resources-plugin
>>> B) Keep manually edited files in SVN and copy them manually to the
>>> correct places
>>>
>>> If supporting one of these (A) isn't allowed in the parent pom, then why
>>> should the other (B) be supported?
>>>
>>>
>>> Anyway, on to the problem at hand here. I just found another antrun
>>> execution in IO:s pom, in the release profile. There's some code in
>>> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
>>> NOTICE.txt files. That could probably be removed now.
>>>
>>> But it just struck me - we've been going about this the wrong way! The
>>> plugins that we use (jar, javadoc, source) supports remote resources. So
>>> let us use that functionality instead of trying to create it ourselves.
>>> It's dead simple really: we create an antrun execution, much like the
>>> one I made, that copies our *local* resources to the same place that the
>>> remote-resources-plugin copies its resources to.
>
> Also because supporting (B) doesn't prevent (A) - whereas the other
> way, supporting (A) screws up (B).
It seems that we keep misunderstanding each other. The last thing I
proposed to support (A) was to add maven-remote-resources-plugin to
pluginManagement. This makes sure that all projects that inherits from
commons-parent and *uses* maven-remote-resources-plugin, will use the
same version of said plugin. Nothing more. So nothing in that prevents
(B) from working.
I'm all for solutions that can support one approach, as long as it
doesn't prevent other approaches.
>
> Niall
>
>>> <plugin>
>>> <!--
>>> - Copy LICENSE.txt and NOTICE.txt so that they are included
>>> - in distribution jar files.
>>> -->
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-antrun-plugin</artifactId>
>>> <version>1.1</version>
>>> <executions>
>>> <execution>
>>> <id>local.resources</id>
>>> <phase>generate-sources</phase>
>>> <goals>
>>> <goal>run</goal>
>>> </goals>
>>> <configuration>
>>> <tasks>
>>> <copy
>>> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
>>> <fileset dir="${basedir}">
>>> <include name="LICENSE.txt" />
>>> <include name="NOTICE.txt" />
>>> </fileset>
>>> </copy>
>>> </tasks>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>>
>>> I haven't tried this for real, but will play around with it and see if
>>> it would work.
>> I tried it and it didn't seem to work, but I could be doing something
>> wrong. My guess is that the javadoc plugin only collects defined
>> "resources" that are in that directory which is why the antrun soln
>> didn't work.
You are right. I have experimented a bit and studied the source code for
the plugins. What maven-remote-resources-plugin does is inject the
remotely fetched resources into the resources in the (in memory) pom. So
what I proposed above will not work.
The antrun that I put in svn is working fine though for the javadoc-jar.
Commons-io has some other antrun executions, as I mentioned before,
which makes the sources jar work. It's a hack, but it seems to do its
job. I will remove (from svn) the now superfluous antrun that rejars the
-javadoc jar file.
>> On the issue of whether the other antrun solution should go in the
>> commons-parent pom - then I think the remote resources argument was
>> lost at this point and we should have a solution that works for the
>> whole of commons and therefore it should go in commons-parent -
>> otherwise we need to duplicate that solution in every component which
>> doesn't use remote resources. That kind of thing is going to put
>> people off making the switch to m2, whereas we should be trying to
>> make it as easy, issue free as possible.
My standpoint on this is that we should not put everything into
commons-parent *right away*. The fact that we are still learning m2,
supports this. First we try something new out in one component. If that
works out well (after a full release cycle) then we can start do discuss
moving those bits into commons-parent.
I'm trying my best here to help with the migration to m2. If we are
going to migrate successfully we need to take many small steps.
Sometimes we must also be able to take a leap and adjust our file-names
(just an example) to make them work *together* with m2 instead of the
opposite. We must dare to let go of the past.
Easy and issue free sound good to me.
>>
>> Niall
>>
>>
>>> WDYT?
>>>
>>>> Niall
>>>>
>>>
>>> <snip/>
>>>
>>> --
>>>
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 9, 2008 11:01 PM, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
> > Niall Pemberton wrote:
> > > On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >> Niall Pemberton wrote:
> > >>> OK so now were down to agreeing the exception in IO-77 - once thats
> > >>> done I can cut an RC.
> > >>>
> > >>> I'm starting to think that with the javadoc.jar Notice/License issue I
> > >>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> > >>> too much time battling with m2 recently).
> > >> Problem solved in r610444:
> > >> https://svn.apache.org/viewvc?view=rev&revision=610444
> > >
> > > Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
> >
> > No, not in my opinion. We've agreed to disagree on which way to go with
> > this. There are two option, each with its merits and flaws.
> >
> > A) Use maven-remote-resources-plugin
> > B) Keep manually edited files in SVN and copy them manually to the
> > correct places
> >
> > If supporting one of these (A) isn't allowed in the parent pom, then why
> > should the other (B) be supported?
> >
> >
> > Anyway, on to the problem at hand here. I just found another antrun
> > execution in IO:s pom, in the release profile. There's some code in
> > there that recreates the -javadoc.jar and inserts the LICENSE.txt and
> > NOTICE.txt files. That could probably be removed now.
> >
> > But it just struck me - we've been going about this the wrong way! The
> > plugins that we use (jar, javadoc, source) supports remote resources. So
> > let us use that functionality instead of trying to create it ourselves.
> > It's dead simple really: we create an antrun execution, much like the
> > one I made, that copies our *local* resources to the same place that the
> > remote-resources-plugin copies its resources to.
Also because supporting (B) doesn't prevent (A) - whereas the other
way, supporting (A) screws up (B).
Niall
> > <plugin>
> > <!--
> > - Copy LICENSE.txt and NOTICE.txt so that they are included
> > - in distribution jar files.
> > -->
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-antrun-plugin</artifactId>
> > <version>1.1</version>
> > <executions>
> > <execution>
> > <id>local.resources</id>
> > <phase>generate-sources</phase>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <configuration>
> > <tasks>
> > <copy
> > todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
> > <fileset dir="${basedir}">
> > <include name="LICENSE.txt" />
> > <include name="NOTICE.txt" />
> > </fileset>
> > </copy>
> > </tasks>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> >
> > I haven't tried this for real, but will play around with it and see if
> > it would work.
>
> I tried it and it didn't seem to work, but I could be doing something
> wrong. My guess is that the javadoc plugin only collects defined
> "resources" that are in that directory which is why the antrun soln
> didn't work.
>
> On the issue of whether the other antrun solution should go in the
> commons-parent pom - then I think the remote resources argument was
> lost at this point and we should have a solution that works for the
> whole of commons and therefore it should go in commons-parent -
> otherwise we need to duplicate that solution in every component which
> doesn't use remote resources. That kind of thing is going to put
> people off making the switch to m2, whereas we should be trying to
> make it as easy, issue free as possible.
>
> Niall
>
>
> > WDYT?
> >
> > >
> > > Niall
> > >
> >
> >
> > <snip/>
> >
> > --
> >
> > Dennis Lundberg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 9, 2008 10:16 PM, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> OK so now were down to agreeing the exception in IO-77 - once thats
> >>> done I can cut an RC.
> >>>
> >>> I'm starting to think that with the javadoc.jar Notice/License issue I
> >>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> >>> too much time battling with m2 recently).
> >> Problem solved in r610444:
> >> https://svn.apache.org/viewvc?view=rev&revision=610444
> >
> > Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
>
> No, not in my opinion. We've agreed to disagree on which way to go with
> this. There are two option, each with its merits and flaws.
>
> A) Use maven-remote-resources-plugin
> B) Keep manually edited files in SVN and copy them manually to the
> correct places
>
> If supporting one of these (A) isn't allowed in the parent pom, then why
> should the other (B) be supported?
>
>
> Anyway, on to the problem at hand here. I just found another antrun
> execution in IO:s pom, in the release profile. There's some code in
> there that recreates the -javadoc.jar and inserts the LICENSE.txt and
> NOTICE.txt files. That could probably be removed now.
>
> But it just struck me - we've been going about this the wrong way! The
> plugins that we use (jar, javadoc, source) supports remote resources. So
> let us use that functionality instead of trying to create it ourselves.
> It's dead simple really: we create an antrun execution, much like the
> one I made, that copies our *local* resources to the same place that the
> remote-resources-plugin copies its resources to.
>
>
> <plugin>
> <!--
> - Copy LICENSE.txt and NOTICE.txt so that they are included
> - in distribution jar files.
> -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.1</version>
> <executions>
> <execution>
> <id>local.resources</id>
> <phase>generate-sources</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <tasks>
> <copy
> todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
> <fileset dir="${basedir}">
> <include name="LICENSE.txt" />
> <include name="NOTICE.txt" />
> </fileset>
> </copy>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> I haven't tried this for real, but will play around with it and see if
> it would work.
I tried it and it didn't seem to work, but I could be doing something
wrong. My guess is that the javadoc plugin only collects defined
"resources" that are in that directory which is why the antrun soln
didn't work.
On the issue of whether the other antrun solution should go in the
commons-parent pom - then I think the remote resources argument was
lost at this point and we should have a solution that works for the
whole of commons and therefore it should go in commons-parent -
otherwise we need to duplicate that solution in every component which
doesn't use remote resources. That kind of thing is going to put
people off making the switch to m2, whereas we should be trying to
make it as easy, issue free as possible.
Niall
> WDYT?
>
> >
> > Niall
> >
>
>
> <snip/>
>
> --
>
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 9, 2008 11:16 PM, Dennis Lundberg <de...@apache.org> wrote:
> No, not in my opinion. We've agreed to disagree on which way to go with
> this. There are two option, each with its merits and flaws.
>
> A) Use maven-remote-resources-plugin
> B) Keep manually edited files in SVN and copy them manually to the
> correct places
>
> If supporting one of these (A) isn't allowed in the parent pom, then why
> should the other (B) be supported?
Although I agree with your preference for the
maven-remote-resources-plugin, I strongly disagree with the resolution
to not handle these things in the commons-parent pom. If there is no
other way to resolve that, then I'd be in favour for a majority vote.
Your suggestion below is, IMO, a variant of (B). If you're happy with
it, I am well.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>>> OK so now were down to agreeing the exception in IO-77 - once thats
>>> done I can cut an RC.
>>>
>>> I'm starting to think that with the javadoc.jar Notice/License issue I
>>> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
>>> too much time battling with m2 recently).
>> Problem solved in r610444:
>> https://svn.apache.org/viewvc?view=rev&revision=610444
>
> Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
No, not in my opinion. We've agreed to disagree on which way to go with
this. There are two option, each with its merits and flaws.
A) Use maven-remote-resources-plugin
B) Keep manually edited files in SVN and copy them manually to the
correct places
If supporting one of these (A) isn't allowed in the parent pom, then why
should the other (B) be supported?
Anyway, on to the problem at hand here. I just found another antrun
execution in IO:s pom, in the release profile. There's some code in
there that recreates the -javadoc.jar and inserts the LICENSE.txt and
NOTICE.txt files. That could probably be removed now.
But it just struck me - we've been going about this the wrong way! The
plugins that we use (jar, javadoc, source) supports remote resources. So
let us use that functionality instead of trying to create it ourselves.
It's dead simple really: we create an antrun execution, much like the
one I made, that copies our *local* resources to the same place that the
remote-resources-plugin copies its resources to.
<plugin>
<!--
- Copy LICENSE.txt and NOTICE.txt so that they are included
- in distribution jar files.
-->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>local.resources</id>
<phase>generate-sources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<copy
todir="${project.build.directory}/maven-shared-archive-resources/META-INF">
<fileset dir="${basedir}">
<include name="LICENSE.txt" />
<include name="NOTICE.txt" />
</fileset>
</copy>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
I haven't tried this for real, but will play around with it and see if
it would work.
WDYT?
>
> Niall
>
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 9, 2008 4:41 PM, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > OK so now were down to agreeing the exception in IO-77 - once thats
> > done I can cut an RC.
> >
> > I'm starting to think that with the javadoc.jar Notice/License issue I
> > may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> > too much time battling with m2 recently).
>
> Problem solved in r610444:
> https://svn.apache.org/viewvc?view=rev&revision=610444
Thanks - shouldn't we do this in commons-parent pom though, not just for IO?
Niall
> > Niall
> >
> > On Jan 9, 2008 9:24 AM, Henri Yandell <fl...@gmail.com> wrote:
> >> Happy to move IO-137 over to post-1.4.
> >>
> >> Hen
> >>
> >>
> >> On Jan 9, 2008 1:04 AM, Niall Pemberton <ni...@gmail.com> wrote:
> >>> OK looks like were nearly ready for IO 1.4 release - theres a minor
> >>> issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
> >>> whether we're going to do anything about for 1.4 or move it to
> >>> post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
> >>> want to / have time to look at this?
> >>>
> >>> https://issues.apache.org/jira/browse/IO-77
> >>> https://issues.apache.org/jira/browse/IO-137
> >>>
> >>> Niall
> >>>
> >>>
> >>> On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> +1 to Commons IO 1.4!
> >>>>
> >>>> On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
> >>>>> On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> >>>>>> I think we should deal with IO-137 as it's a minor enhancement and
> >>>>>> comes with tests. I'll volunteer to look at that.
> >>>>> I looked at this a while back and using the baos buffers directly in
> >>>>> an InputStream raises a safety issue (if the baos is modified while
> >>>>> the InputStream is being read) - do we care about that?
> >>>> I kind of agree. I was thinking about proposing a "copy on write" flag
> >>>> to reset() that would start with a new set of buffers when there are
> >>>> InputStreams reading from the same buffers, but that seems too complex
> >>>> to me.
> >>>>
> >>>> Apart from that, I like the general idea in IO-137 (it's similar to my
> >>>> readFrom() proposal) so I'd like to see it in 1.4 if there's a
> >>>> consensus on what form the feature should take. I'm willing to invest
> >>>> some time to work out the details.
> >>>>
> >>>>>> IO-51 has tests, so worth a look at if that can be done before the
> >>>>>> others are resolved. ie) punt to post-1.4 iff it's the last one left.
> >>>>> I had a brief look and my initial thought was the Limiter should just
> >>>>> be doing the throttling and the reading/writing should be in the
> >>>>> input/output implementations - but I haven't looked in detail.
> >>>> I looked at IO-51 a few months ago, and came to the same conclusion.
> >>>> The implementation isn't too modular and probably too complex (i.e.
> >>>> could be done with less code). Of course I didn't have time to come up
> >>>> with an alternative implementation.
> >>>>
> >>>> I like the feature though, and I have some use cases where it would
> >>>> come in handy, but I think it's better to improve the Limiter API
> >>>> before the feature gets released.
> >>>>
> >>>>> IO-148 is done from my PoV - I left it open in case anyone wanted to
> >>>>> object to me renaming it today. If Gary and Jukka are happy then we
> >>>>> can mark it as fixed.
> >>>> I'm happy.
> >>>>
> >>>> BR,
> >>>>
> >>>> Jukka Zitting
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> OK so now were down to agreeing the exception in IO-77 - once thats
> done I can cut an RC.
>
> I'm starting to think that with the javadoc.jar Notice/License issue I
> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> too much time battling with m2 recently).
Problem solved in r610444:
https://svn.apache.org/viewvc?view=rev&revision=610444
> Niall
>
> On Jan 9, 2008 9:24 AM, Henri Yandell <fl...@gmail.com> wrote:
>> Happy to move IO-137 over to post-1.4.
>>
>> Hen
>>
>>
>> On Jan 9, 2008 1:04 AM, Niall Pemberton <ni...@gmail.com> wrote:
>>> OK looks like were nearly ready for IO 1.4 release - theres a minor
>>> issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
>>> whether we're going to do anything about for 1.4 or move it to
>>> post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
>>> want to / have time to look at this?
>>>
>>> https://issues.apache.org/jira/browse/IO-77
>>> https://issues.apache.org/jira/browse/IO-137
>>>
>>> Niall
>>>
>>>
>>> On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> +1 to Commons IO 1.4!
>>>>
>>>> On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
>>>>>> I think we should deal with IO-137 as it's a minor enhancement and
>>>>>> comes with tests. I'll volunteer to look at that.
>>>>> I looked at this a while back and using the baos buffers directly in
>>>>> an InputStream raises a safety issue (if the baos is modified while
>>>>> the InputStream is being read) - do we care about that?
>>>> I kind of agree. I was thinking about proposing a "copy on write" flag
>>>> to reset() that would start with a new set of buffers when there are
>>>> InputStreams reading from the same buffers, but that seems too complex
>>>> to me.
>>>>
>>>> Apart from that, I like the general idea in IO-137 (it's similar to my
>>>> readFrom() proposal) so I'd like to see it in 1.4 if there's a
>>>> consensus on what form the feature should take. I'm willing to invest
>>>> some time to work out the details.
>>>>
>>>>>> IO-51 has tests, so worth a look at if that can be done before the
>>>>>> others are resolved. ie) punt to post-1.4 iff it's the last one left.
>>>>> I had a brief look and my initial thought was the Limiter should just
>>>>> be doing the throttling and the reading/writing should be in the
>>>>> input/output implementations - but I haven't looked in detail.
>>>> I looked at IO-51 a few months ago, and came to the same conclusion.
>>>> The implementation isn't too modular and probably too complex (i.e.
>>>> could be done with less code). Of course I didn't have time to come up
>>>> with an alternative implementation.
>>>>
>>>> I like the feature though, and I have some use cases where it would
>>>> come in handy, but I think it's better to improve the Limiter API
>>>> before the feature gets released.
>>>>
>>>>> IO-148 is done from my PoV - I left it open in case anyone wanted to
>>>>> object to me renaming it today. If Gary and Jukka are happy then we
>>>>> can mark it as fixed.
>>>> I'm happy.
>>>>
>>>> BR,
>>>>
>>>> Jukka Zitting
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by nicolas de loof <ni...@apache.org>.
I attached a new pacth to IO-77.
It implements Holger
Hoffstätte<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=h2o>suggestion
to use NIO for file copy - when a java
1.4 runtime is available - and relies on buffers on java 1.3.
Nico.
2008/1/9, Niall Pemberton <ni...@gmail.com>:
>
> OK so now were down to agreeing the exception in IO-77 - once thats
> done I can cut an RC.
>
> I'm starting to think that with the javadoc.jar Notice/License issue I
> may cut the rc with m1, since m2 seems to painful ATM (I've spent far
> too much time battling with m2 recently).
>
> Niall
>
> On Jan 9, 2008 9:24 AM, Henri Yandell <fl...@gmail.com> wrote:
> > Happy to move IO-137 over to post-1.4.
> >
> > Hen
> >
> >
> > On Jan 9, 2008 1:04 AM, Niall Pemberton <ni...@gmail.com>
> wrote:
> > > OK looks like were nearly ready for IO 1.4 release - theres a minor
> > > issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
> > > whether we're going to do anything about for 1.4 or move it to
> > > post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
> > > want to / have time to look at this?
> > >
> > > https://issues.apache.org/jira/browse/IO-77
> > > https://issues.apache.org/jira/browse/IO-137
> > >
> > > Niall
> > >
> > >
> > > On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > +1 to Commons IO 1.4!
> > > >
> > > > On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com>
> wrote:
> > > > > On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> > > > > > I think we should deal with IO-137 as it's a minor enhancement
> and
> > > > > > comes with tests. I'll volunteer to look at that.
> > > > >
> > > > > I looked at this a while back and using the baos buffers directly
> in
> > > > > an InputStream raises a safety issue (if the baos is modified
> while
> > > > > the InputStream is being read) - do we care about that?
> > > >
> > > > I kind of agree. I was thinking about proposing a "copy on write"
> flag
> > > > to reset() that would start with a new set of buffers when there are
> > > > InputStreams reading from the same buffers, but that seems too
> complex
> > > > to me.
> > > >
> > > > Apart from that, I like the general idea in IO-137 (it's similar to
> my
> > > > readFrom() proposal) so I'd like to see it in 1.4 if there's a
> > > > consensus on what form the feature should take. I'm willing to
> invest
> > > > some time to work out the details.
> > > >
> > > > > > IO-51 has tests, so worth a look at if that can be done before
> the
> > > > > > others are resolved. ie) punt to post-1.4 iff it's the last one
> left.
> > > > >
> > > > > I had a brief look and my initial thought was the Limiter should
> just
> > > > > be doing the throttling and the reading/writing should be in the
> > > > > input/output implementations - but I haven't looked in detail.
> > > >
> > > > I looked at IO-51 a few months ago, and came to the same conclusion.
> > > > The implementation isn't too modular and probably too complex (i.e.
> > > > could be done with less code). Of course I didn't have time to come
> up
> > > > with an alternative implementation.
> > > >
> > > > I like the feature though, and I have some use cases where it would
> > > > come in handy, but I think it's better to improve the Limiter API
> > > > before the feature gets released.
> > > >
> > > > > IO-148 is done from my PoV - I left it open in case anyone wanted
> to
> > > > > object to me renaming it today. If Gary and Jukka are happy then
> we
> > > > > can mark it as fixed.
> > > >
> > > > I'm happy.
> > > >
> > > > BR,
> > > >
> > > > Jukka Zitting
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
OK so now were down to agreeing the exception in IO-77 - once thats
done I can cut an RC.
I'm starting to think that with the javadoc.jar Notice/License issue I
may cut the rc with m1, since m2 seems to painful ATM (I've spent far
too much time battling with m2 recently).
Niall
On Jan 9, 2008 9:24 AM, Henri Yandell <fl...@gmail.com> wrote:
> Happy to move IO-137 over to post-1.4.
>
> Hen
>
>
> On Jan 9, 2008 1:04 AM, Niall Pemberton <ni...@gmail.com> wrote:
> > OK looks like were nearly ready for IO 1.4 release - theres a minor
> > issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
> > whether we're going to do anything about for 1.4 or move it to
> > post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
> > want to / have time to look at this?
> >
> > https://issues.apache.org/jira/browse/IO-77
> > https://issues.apache.org/jira/browse/IO-137
> >
> > Niall
> >
> >
> > On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
> > > Hi,
> > >
> > > +1 to Commons IO 1.4!
> > >
> > > On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
> > > > On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> > > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > > comes with tests. I'll volunteer to look at that.
> > > >
> > > > I looked at this a while back and using the baos buffers directly in
> > > > an InputStream raises a safety issue (if the baos is modified while
> > > > the InputStream is being read) - do we care about that?
> > >
> > > I kind of agree. I was thinking about proposing a "copy on write" flag
> > > to reset() that would start with a new set of buffers when there are
> > > InputStreams reading from the same buffers, but that seems too complex
> > > to me.
> > >
> > > Apart from that, I like the general idea in IO-137 (it's similar to my
> > > readFrom() proposal) so I'd like to see it in 1.4 if there's a
> > > consensus on what form the feature should take. I'm willing to invest
> > > some time to work out the details.
> > >
> > > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > > >
> > > > I had a brief look and my initial thought was the Limiter should just
> > > > be doing the throttling and the reading/writing should be in the
> > > > input/output implementations - but I haven't looked in detail.
> > >
> > > I looked at IO-51 a few months ago, and came to the same conclusion.
> > > The implementation isn't too modular and probably too complex (i.e.
> > > could be done with less code). Of course I didn't have time to come up
> > > with an alternative implementation.
> > >
> > > I like the feature though, and I have some use cases where it would
> > > come in handy, but I think it's better to improve the Limiter API
> > > before the feature gets released.
> > >
> > > > IO-148 is done from my PoV - I left it open in case anyone wanted to
> > > > object to me renaming it today. If Gary and Jukka are happy then we
> > > > can mark it as fixed.
> > >
> > > I'm happy.
> > >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Henri Yandell <fl...@gmail.com>.
Happy to move IO-137 over to post-1.4.
Hen
On Jan 9, 2008 1:04 AM, Niall Pemberton <ni...@gmail.com> wrote:
> OK looks like were nearly ready for IO 1.4 release - theres a minor
> issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
> whether we're going to do anything about for 1.4 or move it to
> post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
> want to / have time to look at this?
>
> https://issues.apache.org/jira/browse/IO-77
> https://issues.apache.org/jira/browse/IO-137
>
> Niall
>
>
> On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
> > Hi,
> >
> > +1 to Commons IO 1.4!
> >
> > On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
> > > On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> > > > I think we should deal with IO-137 as it's a minor enhancement and
> > > > comes with tests. I'll volunteer to look at that.
> > >
> > > I looked at this a while back and using the baos buffers directly in
> > > an InputStream raises a safety issue (if the baos is modified while
> > > the InputStream is being read) - do we care about that?
> >
> > I kind of agree. I was thinking about proposing a "copy on write" flag
> > to reset() that would start with a new set of buffers when there are
> > InputStreams reading from the same buffers, but that seems too complex
> > to me.
> >
> > Apart from that, I like the general idea in IO-137 (it's similar to my
> > readFrom() proposal) so I'd like to see it in 1.4 if there's a
> > consensus on what form the feature should take. I'm willing to invest
> > some time to work out the details.
> >
> > > > IO-51 has tests, so worth a look at if that can be done before the
> > > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> > >
> > > I had a brief look and my initial thought was the Limiter should just
> > > be doing the throttling and the reading/writing should be in the
> > > input/output implementations - but I haven't looked in detail.
> >
> > I looked at IO-51 a few months ago, and came to the same conclusion.
> > The implementation isn't too modular and probably too complex (i.e.
> > could be done with less code). Of course I didn't have time to come up
> > with an alternative implementation.
> >
> > I like the feature though, and I have some use cases where it would
> > come in handy, but I think it's better to improve the Limiter API
> > before the feature gets released.
> >
> > > IO-148 is done from my PoV - I left it open in case anyone wanted to
> > > object to me renaming it today. If Gary and Jukka are happy then we
> > > can mark it as fixed.
> >
> > I'm happy.
> >
> > BR,
> >
> > Jukka Zitting
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
OK looks like were nearly ready for IO 1.4 release - theres a minor
issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide
whether we're going to do anything about for 1.4 or move it to
post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys
want to / have time to look at this?
https://issues.apache.org/jira/browse/IO-77
https://issues.apache.org/jira/browse/IO-137
Niall
On Jan 6, 2008 7:05 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> +1 to Commons IO 1.4!
>
> On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
> > On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> > > I think we should deal with IO-137 as it's a minor enhancement and
> > > comes with tests. I'll volunteer to look at that.
> >
> > I looked at this a while back and using the baos buffers directly in
> > an InputStream raises a safety issue (if the baos is modified while
> > the InputStream is being read) - do we care about that?
>
> I kind of agree. I was thinking about proposing a "copy on write" flag
> to reset() that would start with a new set of buffers when there are
> InputStreams reading from the same buffers, but that seems too complex
> to me.
>
> Apart from that, I like the general idea in IO-137 (it's similar to my
> readFrom() proposal) so I'd like to see it in 1.4 if there's a
> consensus on what form the feature should take. I'm willing to invest
> some time to work out the details.
>
> > > IO-51 has tests, so worth a look at if that can be done before the
> > > others are resolved. ie) punt to post-1.4 iff it's the last one left.
> >
> > I had a brief look and my initial thought was the Limiter should just
> > be doing the throttling and the reading/writing should be in the
> > input/output implementations - but I haven't looked in detail.
>
> I looked at IO-51 a few months ago, and came to the same conclusion.
> The implementation isn't too modular and probably too complex (i.e.
> could be done with less code). Of course I didn't have time to come up
> with an alternative implementation.
>
> I like the feature though, and I have some use cases where it would
> come in handy, but I think it's better to improve the Limiter API
> before the feature gets released.
>
> > IO-148 is done from my PoV - I left it open in case anyone wanted to
> > object to me renaming it today. If Gary and Jukka are happy then we
> > can mark it as fixed.
>
> I'm happy.
>
> BR,
>
> Jukka Zitting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
+1 to Commons IO 1.4!
On Jan 6, 2008 4:58 AM, Niall Pemberton <ni...@gmail.com> wrote:
> On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> > I think we should deal with IO-137 as it's a minor enhancement and
> > comes with tests. I'll volunteer to look at that.
>
> I looked at this a while back and using the baos buffers directly in
> an InputStream raises a safety issue (if the baos is modified while
> the InputStream is being read) - do we care about that?
I kind of agree. I was thinking about proposing a "copy on write" flag
to reset() that would start with a new set of buffers when there are
InputStreams reading from the same buffers, but that seems too complex
to me.
Apart from that, I like the general idea in IO-137 (it's similar to my
readFrom() proposal) so I'd like to see it in 1.4 if there's a
consensus on what form the feature should take. I'm willing to invest
some time to work out the details.
> > IO-51 has tests, so worth a look at if that can be done before the
> > others are resolved. ie) punt to post-1.4 iff it's the last one left.
>
> I had a brief look and my initial thought was the Limiter should just
> be doing the throttling and the reading/writing should be in the
> input/output implementations - but I haven't looked in detail.
I looked at IO-51 a few months ago, and came to the same conclusion.
The implementation isn't too modular and probably too complex (i.e.
could be done with less code). Of course I didn't have time to come up
with an alternative implementation.
I like the feature though, and I have some use cases where it would
come in handy, but I think it's better to improve the Limiter API
before the feature gets released.
> IO-148 is done from my PoV - I left it open in case anyone wanted to
> object to me renaming it today. If Gary and Jukka are happy then we
> can mark it as fixed.
I'm happy.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 6, 2008 2:23 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > I would like to get an IO 1.4 release out in the near future. Looking
> > thru the issues tagged for 1.4 I would suggest the following:
> >
> > 1) Resolve the following issues, which all have patches except IO-149
> > which is trivial
> > IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > IO-105 - Add a FileUtils.copyDirectoryStructure method
> > IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > IO-135 - Add convenience deleteQuietly to FileUtils
>
> +1
>
> > 2) Move the following issues to post-1.4
> > IO-137 - Added method for getting InputStream from
> > ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > and copy
> > IO-51 - Throttled input and output stream classes
> > IO-77 - add a convenience FileUtils.move(File src, File dest)
>
> +1 on IO-77 being post-1.4 as it lacks unit tests.
>
> I think we should deal with IO-137 as it's a minor enhancement and
> comes with tests. I'll volunteer to look at that.
I looked at this a while back and using the baos buffers directly in
an InputStream raises a safety issue (if the baos is modified while
the InputStream is being read) - do we care about that?
> IO-51 has tests, so worth a look at if that can be done before the
> others are resolved. ie) punt to post-1.4 iff it's the last one left.
I had a brief look and my initial thought was the Limiter should just
be doing the throttling and the reading/writing should be in the
input/output implementations - but I haven't looked in detail.
> > 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > will be approved shortly
> >
> > Thoughts on this?
>
> Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
Removing ant is fine by me - I'd like to keep the m1 build as it works
- I think we should only delete them when people stop bothering to
keep them up to date.
> And IO-148 + IO-127?
IO-127 was really just a discussion. We haven't actually moved to JDK
1.4 minimum - just introduced 3 impls that require JDK 1.4. The rest
is still JDK 1.3 compatible with the source/target options.
IO-148 is done from my PoV - I left it open in case anyone wanted to
object to me renaming it today. If Gary and Jukka are happy then we
can mark it as fixed.
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Henri Yandell <fl...@gmail.com>.
On Jan 5, 2008 5:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> I would like to get an IO 1.4 release out in the near future. Looking
> thru the issues tagged for 1.4 I would suggest the following:
>
> 1) Resolve the following issues, which all have patches except IO-149
> which is trivial
> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> IO-105 - Add a FileUtils.copyDirectoryStructure method
> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> IO-135 - Add convenience deleteQuietly to FileUtils
+1
> 2) Move the following issues to post-1.4
> IO-137 - Added method for getting InputStream from
> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> and copy
> IO-51 - Throttled input and output stream classes
> IO-77 - add a convenience FileUtils.move(File src, File dest)
+1 on IO-77 being post-1.4 as it lacks unit tests.
I think we should deal with IO-137 as it's a minor enhancement and
comes with tests. I'll volunteer to look at that.
IO-51 has tests, so worth a look at if that can be done before the
others are resolved. ie) punt to post-1.4 iff it's the last one left.
> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> will be approved shortly
>
> Thoughts on this?
Delete the M1 build, and maybe Ant given that the build.xml is M1 generated.
And IO-148 + IO-127?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I reviewed the tasks list, and coded up IO-153 :-)
Stephen
Niall Pemberton wrote:
> I would like to get an IO 1.4 release out in the near future. Looking
> thru the issues tagged for 1.4 I would suggest the following:
>
> 1) Resolve the following issues, which all have patches except IO-149
> which is trivial
> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> IO-105 - Add a FileUtils.copyDirectoryStructure method
> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> IO-135 - Add convenience deleteQuietly to FileUtils
>
> 2) Move the following issues to post-1.4
> IO-137 - Added method for getting InputStream from
> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> and copy
> IO-51 - Throttled input and output stream classes
> IO-77 - add a convenience FileUtils.move(File src, File dest)
>
> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> will be approved shortly
>
> Thoughts on this?
>
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Carsten Ziegeler <cz...@apache.org>.
Niall Pemberton wrote:
>
> I'd prefer to keep it as it is since it could be in for more than one
> release and it means not having to remember to update the OSGi info.
> Plus anyone wanting to create their own modified custom IO 1.4 version
> can simply change the pom version number and the OSGi bundle info will
> be correct.
>
Yes, that's fine - many thanks for applying the patch!!
For future versions the only thing you might need to change is the
package list (if new packages are added or if you start using other
third party libs).
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 7, 2008 3:45 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Niall Pemberton schrieb:
> > On Jan 7, 2008 2:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> >> Carsten Ziegeler wrote:
> >>> Niall Pemberton wrote:
> >>>> On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> >>>>> It would be great if the release contains the OSGi meta information :)
> >>>>> I'll come up with a patch just for 1.4 that does not use the snapshot
> >>>>> version of the maven bundle plugin. Interested :) ?
> >>>> Yes please
> >>>>
> >>> Great! I assume you're assung maven 2 to build the release?
> >>>
> >> Ok, here is the patch for the pom.xml, you just have to add the
> >> additional manifest entries using the jar plugin. It would be great if
> >> this would go into the final release.
> >
> > Thanks for the patch - I modified it slightly so that the version
> > numbers are not hard coded:
> > http://svn.apache.org/viewvc?view=rev&revision=609639
> >
> > I've uploaded a copy of the jar it generates here:
> > http://people.apache.org/~niallp/commons-io-osgi/
> >
> Ah, sorry for that, I forgot to mention it: this only works for non
> snapshot versions.
> The version 1.4-SNAPSHOT is an invalid version for OSGi as the dash is
> not allowed. Therefore the resulting jar is not usable :(
OK thanks for the info.
> That's why I copy/pasted the version everywhere :)
> Of course ${pom.version} works for the final 1.4 release.
I'd prefer to keep it as it is since it could be in for more than one
release and it means not having to remember to update the OSGi info.
Plus anyone wanting to create their own modified custom IO 1.4 version
can simply change the pom version number and the OSGi bundle info will
be correct.
Niall
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Carsten Ziegeler <cz...@apache.org>.
Niall Pemberton schrieb:
> On Jan 7, 2008 2:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Carsten Ziegeler wrote:
>>> Niall Pemberton wrote:
>>>> On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>> It would be great if the release contains the OSGi meta information :)
>>>>> I'll come up with a patch just for 1.4 that does not use the snapshot
>>>>> version of the maven bundle plugin. Interested :) ?
>>>> Yes please
>>>>
>>> Great! I assume you're assung maven 2 to build the release?
>>>
>> Ok, here is the patch for the pom.xml, you just have to add the
>> additional manifest entries using the jar plugin. It would be great if
>> this would go into the final release.
>
> Thanks for the patch - I modified it slightly so that the version
> numbers are not hard coded:
> http://svn.apache.org/viewvc?view=rev&revision=609639
>
> I've uploaded a copy of the jar it generates here:
> http://people.apache.org/~niallp/commons-io-osgi/
>
Ah, sorry for that, I forgot to mention it: this only works for non
snapshot versions.
The version 1.4-SNAPSHOT is an invalid version for OSGi as the dash is
not allowed. Therefore the resulting jar is not usable :(
That's why I copy/pasted the version everywhere :)
Of course ${pom.version} works for the final 1.4 release.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 7, 2008 2:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Carsten Ziegeler wrote:
> > Niall Pemberton wrote:
> >> On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> >>> It would be great if the release contains the OSGi meta information :)
> >>> I'll come up with a patch just for 1.4 that does not use the snapshot
> >>> version of the maven bundle plugin. Interested :) ?
> >>
> >> Yes please
> >>
> > Great! I assume you're assung maven 2 to build the release?
> >
> Ok, here is the patch for the pom.xml, you just have to add the
> additional manifest entries using the jar plugin. It would be great if
> this would go into the final release.
Thanks for the patch - I modified it slightly so that the version
numbers are not hard coded:
http://svn.apache.org/viewvc?view=rev&revision=609639
I've uploaded a copy of the jar it generates here:
http://people.apache.org/~niallp/commons-io-osgi/
Niall
> <plugin>
> <artifactId>maven-jar-plugin</artifactId>
> <configuration>
> <archive>
> <manifestEntries>
>
> <Bundle-SymbolicName>org.apache.commons.io</Bundle-SymbolicName>
>
> <Bundle-License>http://www.apache.org/licenses/LICENSE-2.0.txt</Bundle-License>
> <Bundle-ManifestVersion>2</Bundle-ManifestVersion>
> <Bundle-Name>Apache Commons IO Bundle</Bundle-Name>
> <Bundle-Vendor>The Apache Software
> Foundation</Bundle-Vendor>
> <Bundle-Version>1.4.0</Bundle-Version>
> <Export-Package>
> org.apache.commons.io;version=1.4.0,
> org.apache.commons.io.comparator;version=1.4.0,
> org.apache.commons.io.filefilter;version=1.4.0,
> org.apache.commons.io.input;version=1.4.0,
> org.apache.commons.io.output;version=1.4.0
> </Export-Package>
> <Import-Package>
> org.apache.commons.io;version=1.4.0,
> org.apache.commons.io.comparator;version=1.4.0,
> org.apache.commons.io.filefilter;version=1.4.0,
> org.apache.commons.io.input;version=1.4.0,
> org.apache.commons.io.output;version=1.4.0
> </Import-Package>
> </manifestEntries>
> </archive>
> </configuration>
> </plugin>
>
>
> Thanks
>
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Niall Pemberton wrote:
>> On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> It would be great if the release contains the OSGi meta information :)
>>> I'll come up with a patch just for 1.4 that does not use the snapshot
>>> version of the maven bundle plugin. Interested :) ?
>>
>> Yes please
>>
> Great! I assume you're assung maven 2 to build the release?
>
Ok, here is the patch for the pom.xml, you just have to add the
additional manifest entries using the jar plugin. It would be great if
this would go into the final release.
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Bundle-SymbolicName>org.apache.commons.io</Bundle-SymbolicName>
<Bundle-License>http://www.apache.org/licenses/LICENSE-2.0.txt</Bundle-License>
<Bundle-ManifestVersion>2</Bundle-ManifestVersion>
<Bundle-Name>Apache Commons IO Bundle</Bundle-Name>
<Bundle-Vendor>The Apache Software
Foundation</Bundle-Vendor>
<Bundle-Version>1.4.0</Bundle-Version>
<Export-Package>
org.apache.commons.io;version=1.4.0,
org.apache.commons.io.comparator;version=1.4.0,
org.apache.commons.io.filefilter;version=1.4.0,
org.apache.commons.io.input;version=1.4.0,
org.apache.commons.io.output;version=1.4.0
</Export-Package>
<Import-Package>
org.apache.commons.io;version=1.4.0,
org.apache.commons.io.comparator;version=1.4.0,
org.apache.commons.io.filefilter;version=1.4.0,
org.apache.commons.io.input;version=1.4.0,
org.apache.commons.io.output;version=1.4.0
</Import-Package>
</manifestEntries>
</archive>
</configuration>
</plugin>
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Carsten Ziegeler <cz...@apache.org>.
Niall Pemberton wrote:
> On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> It would be great if the release contains the OSGi meta information :)
>> I'll come up with a patch just for 1.4 that does not use the snapshot
>> version of the maven bundle plugin. Interested :) ?
>
> Yes please
>
Great! I assume you're assung maven 2 to build the release?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 7, 2008 9:34 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> It would be great if the release contains the OSGi meta information :)
> I'll come up with a patch just for 1.4 that does not use the snapshot
> version of the maven bundle plugin. Interested :) ?
Yes please
Niall
> Carsten
>
>
> Niall Pemberton wrote:
> > I would like to get an IO 1.4 release out in the near future. Looking
> > thru the issues tagged for 1.4 I would suggest the following:
> >
> > 1) Resolve the following issues, which all have patches except IO-149
> > which is trivial
> > IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > IO-105 - Add a FileUtils.copyDirectoryStructure method
> > IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > IO-135 - Add convenience deleteQuietly to FileUtils
> >
> > 2) Move the following issues to post-1.4
> > IO-137 - Added method for getting InputStream from
> > ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > and copy
> > IO-51 - Throttled input and output stream classes
> > IO-77 - add a convenience FileUtils.move(File src, File dest)
> >
> > 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > will be approved shortly
> >
> > Thoughts on this?
> >
> > Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Planning IO 1.4 release
Posted by nicolas de loof <ni...@apache.org>.
I've just attached a new patch for IO-77 with a testcase
I'm also added a "moveDirectory" method (with testcase) as suggested in
comments.
Please review .. and include in 1.4 release !
2008/1/7, Carsten Ziegeler <cz...@apache.org>:
>
> It would be great if the release contains the OSGi meta information :)
> I'll come up with a patch just for 1.4 that does not use the snapshot
> version of the maven bundle plugin. Interested :) ?
>
> Carsten
>
> Niall Pemberton wrote:
> > I would like to get an IO 1.4 release out in the near future. Looking
> > thru the issues tagged for 1.4 I would suggest the following:
> >
> > 1) Resolve the following issues, which all have patches except IO-149
> > which is trivial
> > IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> > IO-105 - Add a FileUtils.copyDirectoryStructure method
> > IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> > IO-135 - Add convenience deleteQuietly to FileUtils
> >
> > 2) Move the following issues to post-1.4
> > IO-137 - Added method for getting InputStream from
> > ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> > and copy
> > IO-51 - Throttled input and output stream classes
> > IO-77 - add a convenience FileUtils.move(File src, File dest)
> >
> > 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> > will be approved shortly
> >
> > Thoughts on this?
> >
> > Niall
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [IO] Planning IO 1.4 release
Posted by Carsten Ziegeler <cz...@apache.org>.
It would be great if the release contains the OSGi meta information :)
I'll come up with a patch just for 1.4 that does not use the snapshot
version of the maven bundle plugin. Interested :) ?
Carsten
Niall Pemberton wrote:
> I would like to get an IO 1.4 release out in the near future. Looking
> thru the issues tagged for 1.4 I would suggest the following:
>
> 1) Resolve the following issues, which all have patches except IO-149
> which is trivial
> IO-149 - Make FilenameUtils.EXTENSION_SEPARATOR public
> IO-105 - Add a FileUtils.copyDirectoryStructure method
> IO-152 - Add ByteArrayOutputStream.readFrom(InputStream)
> IO-135 - Add convenience deleteQuietly to FileUtils
>
> 2) Move the following issues to post-1.4
> IO-137 - Added method for getting InputStream from
> ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation
> and copy
> IO-51 - Throttled input and output stream classes
> IO-77 - add a convenience FileUtils.move(File src, File dest)
>
> 3) Upgrade to commons-parent-6 pom.xml which looks like the release
> will be approved shortly
>
> Thoughts on this?
>
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org