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.