Looks like it is an expected behavior. See the comment from the primary
author of the plugin:
https://issues.apache.org/jira/browse/FELIX-636?focusedCommentId=12614009#action_12614009
Thanks,
Sahoo
Ken Paulsen wrote:
>
> I've filed the issue: http://issues.apache.org/jira/browse/FELIX-636
>
> Thanks Sahoo!
>
> Ken
>
>
>
> Sahoo wrote:
>> Ken,
>>
>> As per the documentation of maven-bundle-plugin [1],
>> <Bundle-SymbolicName> is assumed to be "${groupId}.${artifactId}."
>>
>> So, this appears to be a bug, if not in source, in documentation at
>> least. So, please file a bug in Felix issue tracker [2] under the
>> subcat maven-bundle-plugin.
>>
>> While you are waiting for them to fix the code, override the default
>> value in pom.xml by adding something like this in plugin configuration:
>> <instructions>
>> <Bundle-SymbolicName>${groupId}.${artifactId}</Bundle-SymbolicName>
>> </instructions>
>>
>> HTH,
>> Sahoo
>>
>> [1] http://felix.apache.org/site/maven-bundle-plugin-bnd.html
>> [2] http://issues.apache.org/jira/browse/FELIX
>>
>> Ken Paulsen wrote:
>>>
>>> Hi Sahoo,
>>>
>>> Re-adding the dev alias.
>>>
>>> Should I file a bug against the bnd plugin? Or do you think this is
>>> correct behavior when the artifact name matches the last element of
>>> the group id? To repeat my first email, I have the following in the
>>> pom.xml:
>>>
>>> <groupId>org.glassfish.jsftemplating</groupId>
>>> <artifactId>jsftemplating</artifactId>
>>>
>>> After I build, I get the following in the MANIFEST.MF:
>>>
>>> Bundle-SymbolicName: org.glassfish.jsftemplating
>>>
>>> Notice it only has 1 "jsftemplating" in the symbolic name. If I
>>> change the artifactId to something else and make no other changes, I
>>> get the expected results. For example, if I put this in the pom.xml:
>>>
>>> <groupId>org.glassfish.jsftemplating</groupId>
>>> <artifactId>jsft</artifactId>
>>>
>>> I get this in the MANIFEST.MF:
>>>
>>> Bundle-SymbolicName: org.glassfish.jsftemplating.jsft
>>>
>>> Notice now both the full groupId AND artifact id appear in the
>>> symbolic name. This is what I expected to see.
>>>
>>> So assuming this is a bug, where do I file the report? If it's not
>>> a bug, can you explain why? And what I should do to work around
>>> this strange behavior?
>>>
>>> Thanks!
>>>
>>> Ken
>>>
>>> Sahoo wrote:
>>>> I would expect that to be a configuration issue in your pom.xml.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Ken Paulsen wrote:
>>>>>
>>>>> Do you know why it isn't generating this correctly then?
>>>>>
>>>>> Ken
>>>>>
>>>>> Sahoo wrote:
>>>>>> Ken Paulsen wrote:
>>>>>>>
>>>>>>> I am also experiencing this. I figured out the problem. When I
>>>>>>> opened up the MANIFEST.MF file for the repackaged
>>>>>>> jsftemplating.jar, it had:
>>>>>>>
>>>>>>> Bundle-SymbolicName: org.glassfish.jsftemplating
>>>>>>>
>>>>>>> The pom.xml file has:
>>>>>>>
>>>>>>> <groupId>org.glassfish.jsftemplating</groupId>
>>>>>>> <artifactId>jsftemplating</artifactId>
>>>>>>>
>>>>>>> So I believe this should mean the bundle symbolic name is
>>>>>>> supposed to be "org.glassfish.jsftemplating.jsftemplating". Sahoo?
>>>>>> Yes, that's the default value.
>>>>>>
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>>>
>>>>>>> I didn't see this error because I had previously had the
>>>>>>> artifactId set to "jsft" in which case it correctly generated
>>>>>>> the symbolic name of: "org.glassfish.jsftemplating.jsft". When
>>>>>>> I did a quick search/replace of "jsft" for "jsftemplating" it
>>>>>>> breaks b/c of this.
>>>>>>>
>>>>>>> Work-a-round: change the admingui/war/pom.xml file's
>>>>>>> HK2-Import-Bundles value where it says
>>>>>>> "org.glassfish.jsftemplating.jsftemplating" to
>>>>>>> "org.glassfish.jsftemplating".
>>>>>>>
>>>>>>> Sahoo, all the files are currently checked in if you want to
>>>>>>> observe this. You can simply build the
>>>>>>> v3/admingui/jsftemplating/pom.xml to see this.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Ken
>>>>>>>
>>>>>>>
>>>>>>> Anissa Lam wrote:
>>>>>>>>
>>>>>>>> build entire v3 and admingui
>>>>>>>> cp dataprovider.jar and jsftemplating.jar to glassfish/modules
>>>>>>>> start server
>>>>>>>> deploy admingui/war/target/admingui.war successfully
>>>>>>>>
>>>>>>>> When trying to go to http://localhost:8080/admingui, get 404
>>>>>>>> error.
>>>>>>>>
>>>>>>>> server log says:
>>>>>>>> NFO: Initializing Mojarra (1.2_08-b06-FCS) for context '/admingui'
>>>>>>>> Jul 15, 2008 7:13:27 PM com.sun.enterprise.web.WebApplication
>>>>>>>> start
>>>>>>>> INFO: Loading application admingui at /admingui
>>>>>>>> Jul 15, 2008 7:13:27 PM
>>>>>>>> com.sun.enterprise.v3.deployment.DeployCommand execute
>>>>>>>> INFO: Deployment of admingui done is 9563 ms
>>>>>>>> Jul 15, 2008 7:13:47 PM org.apache.jasper.servlet.JspServlet
>>>>>>>> serviceJspFile
>>>>>>>> SEVERE: PWC6117: File
>>>>>>>> "/export/Users/anilam/Awork/V3/v3-new/v3/glassfish/domains/domain1/applications/admingui/login.jsp"
>>>>>>>> not found
>>>>>>>>
>>>>>>>> If you want to take a look, the workspace is on bigtruck.sfbay
>>>>>>>>
>>>>>>>> server at:
>>>>>>>> /export/Users/anilam/Awork/V3/v3-new/v3/glassfish (unzip of
>>>>>>>> web.zip)
>>>>>>>> workspace is /export/Users/anilam/Awork/V3/v3-new/v3
>>>>>>>> repository is /export/Users/anilam/Awork/V3/v3-new/repository
>>>>>>>>
>>>>>>>> Anissa.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>