Then your Blueprint is wrong, $ is a valid character so their Tclass is off. It 
is used by the compiler in certain places but there is no reason no to use it. 
I have classes with the name $!

I think we should be careful not to add too many options to bnd. I think a rule 
would be to remove any final package segment that starts with an upper case and 
is not fully upper case.

However, don't hold your breath ... this is low priority and I am very busy so 
a patch (with test cases) would be welcome.

   https://github.com/bndtools/bnd/issues/423

Kind regards,

        Peter Kriens


On 24 okt. 2013, at 16:21, CLEMENT Jean-Philippe 
<[email protected]> wrote:

> Blueprint XML does not accept $ in the class attribute: "The value 
> 'org.test.MyClass$MyPublicStaticInnerClass' of attribute 'class' on element 
> 'bean' is not valid with respect to its type, 'Tclass'".
> 
> Of course the cleanest way is to remove the inner class. In my case the 
> bundle is rather small so I override the Import-Package section.
> 
> Package names usually starts with a lowercase character, but this won't be 
> enough to put this as default behavior. Maybe a kind of "strict package" 
> option might be added to consider names beginning with an uppercase character 
> to be a class rather than a package. Does it make sense?
> 
> JP
> 
> -----Message d'origine-----
> De : Peter Kriens [mailto:[email protected]] 
> Envoyé : jeudi 24 octobre 2013 16:04
> À : [email protected]
> Objet : Re: maven-bundle-plugin issue with blueprint and inner-classes
> 
> You can try to use a $ instead of a . , 
> org.test.MyClass$MyPublicStaticInnerClass. Class.forName supports this so I 
> guess Spring will be ok. The problem is that the 
> org.test.MyClass.MyPublicStaticInnerClass in this form (as a String since it 
> is in XML) is indistinguishable to be an inner class or a package. This is 
> tricky to detect since it is a known ambiguous construct. In Java class the 
> actual names are separated by $ for exactly this reason. However, Spring XML 
> is just a text file with strings and we use XSLT to find the class names. So 
> don't count on this being fixed any time soon ...
> 
> Of course the simplest workaround is of course to not make it an inner class? 
> :-)
> 
> Kind regards,
> 
>       Peter Kriens
> 
> 
> 
> On 24 okt. 2013, at 08:57, CLEMENT Jean-Philippe 
> <[email protected]> wrote:
> 
>> Dear Felix Team,
>> 
>> It seems I found a bug (see below) in the Maven plugin. I'm not too sure 
>> which Jira project/component to select.
>> 
>> Is it a bug and in which project/component may I open it?
>> 
>> Regards,
>> JP
>> 
>> 
>> De : Achim Nierbeck [mailto:[email protected]] Envoyé : mercredi 
>> 23 octobre 2013 21:03 À : [email protected] Objet : Re: 
>> maven-bundle-plugin issue with blueprint and inner-classes
>> 
>> Hi JP,
>> 
>> you most likely found a bug :)
>> You'll need to issue it at the felix project, and most likely will 
>> also get a better answer there if there is a workaround for this 
>> already :)
>> 
>> 
>> regards, Achim
>> 
>> 2013/10/23 CLEMENT Jean-Philippe 
>> <[email protected]<mailto:jean-philippe.clement
>> @fr.thalesgroup.com>>
>> Dear experts,
>> 
>> I have an issue with the Maven Bundle plugin. It generates an invalid 
>> package when an inner class is used to instantiate a bean.
>> 
>> For instance the following blueprint:
>>           <bean class="org.test.MyClass.MyPublicStaticInnerClass"/>
>> 
>> Generates the following entry in the Import-Package section:
>>           Import-Package: org.test.MyClass
>> 
>> As MyClass is part of the bundle, no Import-Package entry should be 
>> generated.
>> 
>> Is there a workaround?
>> 
>> Regards,
>> JP
>> 
>> 
>> 
>> --
>> 
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web 
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project 
>> Lead OPS4J Pax for Vaadin 
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project 
>> Lead blog <http://notizblog.nierbeck.de/>
> 
> 
> ---------------------------------------------------------------------
> 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