[jira] Assigned: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework

2008-04-25 Thread Grzegorz Kossakowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski reassigned COCOON-2176:


Assignee: Grzegorz Kossakowski

 Remove dependency on CocoonSourceResolver from Servlet Service Framework
 

 Key: COCOON-2176
 URL: https://issues.apache.org/jira/browse/COCOON-2176
 Project: Cocoon
  Issue Type: Task
  Components: - Servlet service framework
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
 Attachments: COCOON-2176-Webapp.tar.gz


 The Servlet Service Framework depends on CocoonSourceResolver class from 
 cocoon-core. CocoonSourceResolver class is used to resolve paths in 
 context-path using custom source implementation, see ServletFactoryBean class 
 for details.
  The SSF is meant to be Cocoon-independent subproject so this dependency must 
 be removed as soon as possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework

2008-04-25 Thread Grzegorz Kossakowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski closed COCOON-2176.


 Resolution: Fixed
Fix version (Component): Parent values: Servlet Service Framework(10247). 
Level 1 values: 1.1.0-dev(10351). 

 Remove dependency on CocoonSourceResolver from Servlet Service Framework
 

 Key: COCOON-2176
 URL: https://issues.apache.org/jira/browse/COCOON-2176
 Project: Cocoon
  Issue Type: Task
  Components: - Servlet service framework
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
 Attachments: COCOON-2176-Webapp-25.04.2008.tar.gz, 
 COCOON-2176-Webapp.tar.gz


 The Servlet Service Framework depends on CocoonSourceResolver class from 
 cocoon-core. CocoonSourceResolver class is used to resolve paths in 
 context-path using custom source implementation, see ServletFactoryBean class 
 for details.
  The SSF is meant to be Cocoon-independent subproject so this dependency must 
 be removed as soon as possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (COCOON-2176) Remove dependency on CocoonSourceResolver from Servlet Service Framework

2008-04-25 Thread Grzegorz Kossakowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski updated COCOON-2176:
-

Attachment: COCOON-2176-Webapp-25.04.2008.tar.gz

Attaching modified test-case that depends on refactored SSF that is free of 
CocoonSourceResolver dependencies.

This test-case passes so the bug can be closed.

Many thanks to Reinhard for his work that made this happen!

 Remove dependency on CocoonSourceResolver from Servlet Service Framework
 

 Key: COCOON-2176
 URL: https://issues.apache.org/jira/browse/COCOON-2176
 Project: Cocoon
  Issue Type: Task
  Components: - Servlet service framework
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
 Attachments: COCOON-2176-Webapp-25.04.2008.tar.gz, 
 COCOON-2176-Webapp.tar.gz


 The Servlet Service Framework depends on CocoonSourceResolver class from 
 cocoon-core. CocoonSourceResolver class is used to resolve paths in 
 context-path using custom source implementation, see ServletFactoryBean class 
 for details.
  The SSF is meant to be Cocoon-independent subproject so this dependency must 
 be removed as soon as possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Preparing OSGi-ready artifacts

2008-04-25 Thread Grzegorz Kossakowski

Hi folks,

I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very good to me. I'm thinking about 
releasing first milestone of this module (along with cocoon-jnet) but I've been struck by a little 
mess in packages we have in SSF and cocoon-jnet.


Let's have a look at SSF, we have following packages:

  o.a.c.callstack.*
  o.a.c.servletscope.*
  o.a.c.servletservice.*

Now cocoon-jnet:
  o.a.c.jnet.*
  o.a.excalibur.sourceresolve.jnet.*


This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g. o.a.c.servletservice.*) per one 
module (artifact, JAR, you name it)?
2. What OSGi folks can say about this situation? I remember that there was some requirement to have 
clean package structure in order to run in OSGi environment easily but I'm not expert in this area.
3. Why cocoon-jnet has excalibur-specific classes at all? I thought that we agreed we are not going 
to support Sources as URLs and only focus on new functionality. Then 
o.a.excalibur.sourceresolve.jnet.* should be removed right?


--
Grzegorz Kossakowski