That's part of the (unresolved) discussion of splitting AntCore into AntLibs 
and creating a combined release ...
- What should be a "core" component?
  <svn>   --> SVN-AntLib
  <copy>  --> Filesystem-AntLib ???
  ...
- What is the AntCore version the AntLib must be compatible with?
  HEAD, Last Released, Older ...
- Create several distributions
  a) core only
  b) minimal (basically the functionality of "old" core)
  c) complete (Core and all AntLibs the Ant project offers)
- What is the layout of an installed Ant with Antlibs?
  (I am creating one for my work: 

        |   index.html                           New Initial Point for 
documentation
        |   toc.html                             Links to: Ant Manual, Site, 
AntLib docs
        |   
        +---antlibs                              Installed AntLibs
        |   |   ant-antunit-1.0.jar              Apache Ant AntUnit
        |   |   ant-dotnet-1.0.jar               Apache Ant DotNet
        |   |   ant-rzfAntlib-0.1-SNAPSHOT.jar   Custom Tasks
        |   |   antlib_ccm.jar                   Custom Synergy (based on 
Apache Ant)
        |   |   
        |   +---ant-antunit-1.0                  docs of AntUnit
        |   +---ant-dotnet-1.0                   docs of DotNet
        |   +---ant-rzfAntlib-0.1-SNAPSHOT       docs of Custom Tasks
        |   \---antlib_ccm                       docs of Custom Synergy
        |               
        +---bin
        |       ant.bat                          modified: "-lib antlibs"
        |       
        +---docs                                 Original Ant-bin-Distro
        +---etc                                  Original Ant-bin-Distro
        \---lib                                  Original Ant-bin-Distro
    


Personally I think splitting is good as we could get rid of a huge codebase with
lots of dependencies. And we can focus knowledge on an AntLib: introduce new 
committers per
AntLib ...
And we could get rid off "old" tasknames (javadoc2, ...) while refactoring.

BWC is a problem here ...
* build file bwc
  I think we should provide BWC for existing build files. That could be done 
with 
  automatically load special AntLib uri's. Maybe a new "-antlib" parameter and 
a modified
  start script with "-lib antlib -antlib antlib:org.apache.ant.svn -antlib 
antlib:org.apache.ant.cvs".
* API bwc
  This would be fine, but we earn lot of old api code. No clean refactoring 
would be possible.
  Idea: "AntLib OldAPI" with facade classed in the old java namespace 
delegating to the new
  implementing classes. Must be loaded by default.



Jan



>-----Ursprüngliche Nachricht-----
>Von: Peter Reilly [mailto:[EMAIL PROTECTED] 
>Gesendet: Freitag, 9. März 2007 11:35
>An: Ant Developers List
>Betreff: Re: CVS - to antlib or not?
>
>On 3/9/07, Peter Reilly <[EMAIL PROTECTED]> wrote:
>> No,
>> I do not like this.
>>
>> We have svn in ant core, and due to bc reasons
>opps that should be cvs....
>> we always will.
>>
>> I would perfer to move svn to ant core, or
>> at least bundle the ant-svn antlib with the release
>> of ant so that one does not have to
>> do an extra download.
>>
>> Peter
>>
>>
>> On 3/9/07, Kevin Jackson <[EMAIL PROTECTED]> wrote:
>> > Hi all,
>> >
>> > Since we have an svn antlib, I was thinking should we move the cvs
>> > code out of the core into it's own lib?
>> >
>> > I've done the majority of the work (setting up the projects copying
>> > and renaming code etc), but I need to know whether this is 
>acceptable
>> > for sandbox or not?
>> >
>> > For BWC we could delegate calls to the normal CVS task to 
>the antlib
>> > version for now and then later remove the stub in the core after a
>> > reasonable amount of time has passed.
>> >
>> > My rationale for doing this is to get most of the SCM 
>stuff out of the
>> > core and into separate antlibs.  CVS is just low-hanging fruit so I
>> > thought we could at least give it some thought.
>> >
>> > Any objections?
>> > Kev
>> >
>> > 
>---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to