Re[2]: Overriding class when creating a bundle

[Peter Kriens <Pe...@aQute.biz>]

Bnd follows the classpath order as far as I can see. For the maven
plugin I get the classpath from maven.

Anyway, split packages are a pain in the ... Preventing them and ant
least treating them consciously is always a better idea.

Kind regards,

     Peter Kriens
     
CZ> Thanks for the answer, Peter! Yes we could use this is kind of a workaround.

CZ> The deeper question for me is, if this could/should be fixed in the
CZ> plugin (or bnd)? So classes earlier in the class path take precedence
CZ> over classes later in the classpath?

CZ> CARSTEN

CZ> Peter Kriens wrote:
>> You can use Include-Resource to include the classes from your sources.
>> The classpath expansion looks for a package along the classpath, if
>> found it does not look further. However, Include-Resource works
>> independent from this expansion.
>> 
>> Kind regards,
>> 
>>      Peter Kriens
>>      
>> CZ> Hi,
>> 
>> CZ> we are using the maven bundle plugin (which works great btw) and now
>> CZ> face the following problem:
>> 
>> CZ> Together with our own code we want to bundle a 3rd party library and at
>> CZ> the same time override some classes from this library with our own
>> CZ> classes (to include some hot fixes and patches).
>> 
>> CZ> So, basically we have a maven project which has our own code and the
>> CZ> patch code in source, a dependency to the 3rd party library and that's
>> CZ> it. When building the bundle, it seems that the clases from the 3rd
>> CZ> party artifact are preferred and therefore our patches never make it
>> CZ> into the bundle.
>> 
>> CZ> Is there a way of achieving this?
>> 
>> CZ> Regards
>> CZ> Carsten
>> 
>> 




-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

Re: Overriding class when creating a bundle

[Stuart McCulloch <st...@jayway.net>]

On 18/07/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Peter Kriens wrote:
> > Bnd follows the classpath order as far as I can see. For the maven
> > plugin I get the classpath from maven.
> I had a quick look at the source code of bndlib (0.0.160) and from what
> I saw I have the feeling that if I use for example "export package
> org.apache.felix.*" and classes for this package are more then once in
> the classpath, then the later ones overwrite the earlier ones. I hope my
> analysis is correct (and I don't make a fool of myself) as I think that
> Jar#putResource() is the method in question and it does not check if a
> resource already exists.
> Could this be the problem?

I think so - just been debugging a problem for niclas where a class
in target/classes was being overridden by a matching entry from a
dependency (both internal classes, not exported).

If I modify the putResource method to return if the resource already
exists, then this class doesn't get overriden and the correct version
appears in the final bundle.

>
> >
> > Anyway, split packages are a pain in the ... Preventing them and ant
> > least treating them consciously is always a better idea.
> >
> :)

definitely - in this case, the culprit was a leftover class from a
refactoring...

>
> Regards
> Carsten
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>


-- 
Cheers, Stuart

Re: Overriding class when creating a bundle

[Carsten Ziegeler <cz...@apache.org>]

Peter Kriens wrote:
> Bnd follows the classpath order as far as I can see. For the maven
> plugin I get the classpath from maven.
I had a quick look at the source code of bndlib (0.0.160) and from what
I saw I have the feeling that if I use for example "export package
org.apache.felix.*" and classes for this package are more then once in
the classpath, then the later ones overwrite the earlier ones. I hope my
analysis is correct (and I don't make a fool of myself) as I think that
Jar#putResource() is the method in question and it does not check if a
resource already exists.
Could this be the problem?

> 
> Anyway, split packages are a pain in the ... Preventing them and ant
> least treating them consciously is always a better idea.
> 
:)

Regards
Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org