You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/06/11 22:32:23 UTC

[VOTE] split sources into src/api and src/impl

Hi gang,

at http://cvs.apache.org/viewcvs.cgi/avalon/framework/src/ you will 
notice an "api" dir and an "impl" dir. The meaning should be obvious. 
These result in seperate avalon-framework-${v}-api.jar and 
avalon-framework-${v}-impl.jar files, as well as in a single merged
avalon-framework-${v}.jar (which contains exactly the same stuff as 
before in the exact same place).

I think this is a good idea as it enforces clean seperation in a logical 
way and with an optimal dir layout, it works nicely, is easy to 
understand and maintain, fully backwards-compatible, and how we should 
strive to organize a lot of our code.

This is a "lazy consensus" vote to bring this stuff to your attention 
and give the opportunity to object before changes are finalized.

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [VOTE] split sources into src/api and src/impl

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 13 June 2003 04:44, Leo Simons wrote:
> Niclas Hedhman wrote:
> > On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote:
> >>I think this is a good idea as it enforces clean seperation in a logical
> >>way
> >
> > In a true Avalon spirit of SoC.
> >
> > Could I add, to have a 3rd directory/jar,
> > avalon-framework-compat-${v}.jar, where you stuff all the deprecated
> > classes?
>
> yeah, go ahead, add all you want! (well, if it makes sense)
>
> of course, a compat jar only makes sense once you actually have a few
> deprecated classes and interfaces.

There is the o.a.a.framework.component package plus Loggable, AbtractLoggable 
and more.

Point is; Preparing for handling the deprecation, so that the deprecated stuff 
can be taken out of the documentation, maybe even the default build, and a 
separate document describing "Migration from ver 3" (or whenever it was 
deprecated), "Drop the avalong-framework-compat.jar into..."


Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [VOTE] split sources into src/api and src/impl

Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote:
> 
>>I think this is a good idea as it enforces clean seperation in a logical
>>way 
> 
> In a true Avalon spirit of SoC.
> 
> Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, 
> where you stuff all the deprecated classes?

yeah, go ahead, add all you want! (well, if it makes sense)

of course, a compat jar only makes sense once you actually have a few 
deprecated classes and interfaces.

  - LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [VOTE] split sources into src/api and src/impl

Posted by Stephen McConnell <mc...@apache.org>.

Niclas Hedhman wrote:

>On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote:
>  
>
>>I think this is a good idea as it enforces clean seperation in a logical
>>way 
>>    
>>
>
>In a true Avalon spirit of SoC.
>
>Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, 
>where you stuff all the deprecated classes?
>

This could be problamatic. You have depricated classes and depricated 
interfaces.  To maintain the impl api seperation you would need to do 
the same thing on the compat classes.  This would result in:

   avalon-framework-api.jar
   avalon-framework-api-compat.jar
   avalon-framework-impl.jar
   avalon-framework-impl-compat.jar
   avalon-framework.jar

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [VOTE] split sources into src/api and src/impl

Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote:
> 
>>I think this is a good idea as it enforces clean seperation in a logical
>>way 
> 
> 
> In a true Avalon spirit of SoC.
> 
> Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, 
> where you stuff all the deprecated classes?


AND interfaces.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [VOTE] split sources into src/api and src/impl

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 11 June 2003 12:32 pm, Leo Simons wrote:
> I think this is a good idea as it enforces clean seperation in a logical
> way 

In a true Avalon spirit of SoC.

Could I add, to have a 3rd directory/jar, avalon-framework-compat-${v}.jar, 
where you stuff all the deprecated classes?

Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Cool! Will this allow us to have DefaultConfigurationBuilder.build( Source ) ?

Posted by Leo Simons <le...@apache.org>.
Anton Tagunov wrote:
>     DefaultConfigurationBuilder.build( Source )
> 
> where Source comes from excalibur-sourceresolve
> it wasn't possible to build this before but in
> future especially if maven will rule the world
> here it seems that it won't be a problem to
> have a dependency chain
> 
>    framework-impl -> sourceresolve -> framework-api
>                   ------------------> framework-api
> 
> will it?

hmm....Prolly not. Of course, we do have excalibur-configuration where 
that stuff can live! (or even in sourceresolve).

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Cool! Will this allow us to have DefaultConfigurationBuilder.build( Source ) ?

Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Leo!

LS> These result in seperate
LS> avalon-framework-${v}-api.jar and
LS> avalon-framework-${v}-impl.jar

Looks that this may potentially tear
a path to some cool things, like
it would be nice to have

    DefaultConfigurationBuilder.build( Source )

where Source comes from excalibur-sourceresolve
it wasn't possible to build this before but in
future especially if maven will rule the world
here it seems that it won't be a problem to
have a dependency chain

   framework-impl -> sourceresolve -> framework-api
                  ------------------> framework-api

will it?

- Anton

P.S.

The reason to want the mentioned method is that
currently we have to do

Source src = ...;
DefaultConfigurationBuilder.build(
      src.getInputStream(), src.getURI() )

and if we forget the src.getURI() or we're just new
to avalon and did not guess we were supposed to do
this then we'll get "nice" results from
Configuration.getLocation()
like "null:27:-1" :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org