cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: Connecting 2 blocks with C3.0
Date Mon, 25 Feb 2013 09:16:19 GMT
On 25/02/2013 05:42, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] ------------------------------------------------------------------------
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] ------------------------------------------------------------------------
>
> I have added the repositories to my pom.xml

Hi,
let me try to summarize your situation (correct me if I am wrong):

1. you have generated the C3 project before the fix for COCOON3-105 
(that removed the default support for blockcontext:/)
2. recently you have re-built this project, Maven re-downloaded the 
latest versions of C3 SNAPSHOT artifacts (containing the fix for 
COCOON3-105, hence not working by default with blockcontext;/ stuff); 
with these new dependencies, you started getting error messages about 
classes not found

At this point you have two options:

(a) stuck with blockcontext:/ stuff: simply re-add this dependency in 
the webapp (i.e. the Maven submodule project that collects all blocks)

<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-block-deployment</artifactId>
<version>1.2.1</version>
</dependency>

(b) adapt your project to the new structure: the easiest path to achieve 
this is to generate an empty project (or take mine [1] as reference) and 
start changing / removing / adding things in your project by taking the 
empty one as reference.

My guess is that you are in the middle of (b); however, (a) is by far 
easier and quicker. The choice is up to you.

> On the side of this discussion, I am wondering if there is a release
> date for C3.0. I have been prototyping a project for a client,
> and really can not much done, due to the continuous changes introduced
> to a "beta" phase !  If we can just stop changing the configurations,
> and
> make the project in a "Real Beta" state and focus on bug fixing and
> documentation, I think it will help users like me getting things done.

I must correct you, C3 is not yet in "beta" phase: the latest stable 
release is still "alpha", as the disclaimer says at

http://cocoon.apache.org/3.0/alpha-warning.html

You would be using the stable, e.g. not changing over time, C3 artifacts 
if your C3 version was 3.0.0-alpha-3.

Instead, you are using the 3.0.0-beta-1-SNAPSHOT artifacts, which are 
more cool because embed all latest fixes and features but is also more 
unstable.

If you are interested in which issues are left before releasing the 
stable 3.0.0-beta-1 version, please take a look at

https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON3%20AND%20fixVersion%20%3D%20%223.0.0-beta-1%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC


If you are willing to help to speed up and improve this process, your 
contribution is highly appreciated.

Regards.

> On Mon, Feb 11, 2013 at 10:09 AM, Francesco Chicchiriccò
> <ilgrosso@apache.org> wrote:
>> On 09/02/2013 22:04, Mansour Al Akeel wrote:
>>> I am still looking for the way to call pipeline in another block and not
>>> an xslt file.
>>> For example:
>>>
>>> assuming I have a block called "contents" and the mounting path is
>>> "/contents" in the active configuration.
>>> What would be the url to call ?? Currently I have this:
>>>
>>>
>>>          <map:generate
>>> src="servlet:contents:/contents/documentId/{map:1}/{map:2}.xml"/>
>>> My understanding (if like C2.2), I would be using:
>>>
>>> servlet:block-name:/mount-point/url-to-match
>>>
>>> Is this correct ??
>>
>> In this respect nothing has changed since C2.2: I have updated my sample
>> application [1] to include a specific entry for invoking another block's
>> pipeline.
>> As you will see from [2] and [3], I have just applied the C2.2 instructions
>> from [4].
>>
>> Regards.
>>
>> [1] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105
>> [2] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/src/main/resources/META-INF/cocoon/spring/mysite2-servlet-service.xml
>> [3] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/mysite2/rcl.properties
>> [4] http://cocoon.apache.org/2.2/1291_1_1.html

-- 
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message