Re: Exclusions does not work with dependency managment?

Grzegorz Kossakowski wrote:

> I also tried dependency plug-in already and had the same results as you. 
> It does not mention dependency we are talking about. I have no idea why.
> However, I'm almost sure. Try mvn eclipse:eclipse and import project. 
> You'll see avalon-framework-4.1.3.jar in build path added so it does 
> come from that module, doesn't it? Also, you'll see it while executing:
> mvn install -X
> 
> Can you verify my findings?

Unfortunately yes :(

[INFO] [eclipse:eclipse]
[DEBUG] org.apache.cocoon:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT 
(selected for null)
[DEBUG]   commons-collections:commons-collections:jar:3.2:compile 
(selected for compile)
[DEBUG]   commons-jxpath:commons-jxpath:jar:1.2:compile (selected for 
compile)
[DEBUG]     junit:junit:jar:3.8:compile (applying version: 3.8.2)
[DEBUG]     junit:junit:jar:3.8.2:compile (applying scope: test)
[DEBUG]     junit:junit:jar:3.8.2:test (selected for test)
[DEBUG]     xml-apis:xml-apis:jar:2.0.2:compile (applying version: 1.3.02)
[DEBUG]     xml-apis:xml-apis:jar:1.3.02:compile (selected for compile)
[DEBUG]     commons-logging:commons-logging:jar:1.0:compile (applying 
version: 1.1)
[DEBUG]     commons-logging:commons-logging:jar:1.1:compile (selected 
for compile)
[DEBUG]       log4j:log4j:jar:1.2.12:compile (applying version: 1.2.14)

Re: Why we have our own SAXParser interface?

Grzegorz Kossakowski wrote:

> Carsten Ziegeler napisał(a):
>> The main reason was to have a simple bean based implementation  
>> that is not tied to Avalon/Excalibur.
>> The sax parser is one of our core components so having this inside  
>> Cocoon makes sense and reduces dependencies while at the same time  
>> allows refactoring the stuff to better fit our needs.
>
> Just to be sure: we should opt for using new interface everywhere  
> in Cocoon, right?
>
Yes, I think so - at least for new code we should use the new  
interfaces.
Actually I forgot the main reason for the new stuff :) The Avalon  
version is pooled which does not fit nicely into the bean approach  
(and Spring); we have supported for pooling Avalon components, but  
obviously pooling is not the best solution. The new stuff does not  
require pooling anymore.

Carsten

> -- 
> Grzegorz Kossakowski

--
Carsten Ziegeler

Is "block-path" input module still supported?

Re: Is "block-path" input module still supported?

[jira] Closed: (COCOON-2048) ImageOp: overlay a transparent image on another one

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

Lars Trieloff closed COCOON-2048.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2-dev (Current SVN)
         Assignee: Lars Trieloff

Fixed last week. Thank you.

> ImageOp: overlay a transparent image on another one
> ---------------------------------------------------
>
>                 Key: COCOON-2048
>                 URL: https://issues.apache.org/jira/browse/COCOON-2048
>             Project: Cocoon
>          Issue Type: New Feature
>          Components: Blocks: ImageOp
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>         Assigned To: Lars Trieloff
>             Fix For: 2.2-dev (Current SVN)
>
>         Attachments: delete.png, imageop-overlay-operation-sample.patch, imageop-overlay-operation.patch
>
>
> New OverlayOperation that puts another image on top of the image used by the ImageOpReader. Useful to
overcome problems with browsers like IE that cannot put a transparent <img> on top of a background image.
> Example usage:
>      <map:read type="image-op-overlay" src="background-image.jpg" >
>           <map:parameter name="overlay-offset-x" value="10" />
>           <map:parameter name="overlay-offset-y" value="20" />
>           <map:parameter name="overlay-source" value="overlay-image.png"/>
>      </map:read>

--

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

Re: [2.2] Can't build with empty local repository (problems with cocoon-deployer-plugin)

Re: svn commit: r534018 - in /cocoon: trunk/tools/cocoon-rcl/cocoon-rcl-plugin/ whiteboard/old-maven-plugins/cocoon-rcl-plugin/

Hi,

On 1 May 2007, at 12:47, reinhard <at> apache.org wrote:

> Author: reinhard
> Date: Tue May  1 04:47:14 2007
> New Revision: 534018
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=534018
> Log:
> keep the old maven plugins easily accessible
> for some time
>
> Added:
>     cocoon/whiteboard/old-maven-plugins/cocoon-rcl-plugin/
>       - copied from r534017, cocoon/trunk/tools/cocoon-rcl/cocoon- 
> rcl-plugin/
> Removed:
>     cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-plugin/

*sigh*

Reinhard, you're making my life _VERY_ difficult 

I see little discussion on the mailing list about this sort of change  
(other than a brief "I've started to merge" a couple of days ago).  
I'm happy that you're doing the work, but not happy at the pain it  
causes.

I'm trying to keep track of 2.2, document changes, and write slides  
on using it ... but it's a frustrating experience! Having to trawl  
through commit messages to find when things are about to move is  
painful. I never know when a clean build on a new box is going to  
fail, because jars are suddenly missing, moved or whatever. This has  
pretty much been my experience for the last couple of months 

If you're at Apachecon, maybe we can have a beer and you can help me  
understand all this?

Thanks,

Andrew.
--
Andrew Savory, Managing Director, Sourcesense UK
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.sourcesense.com/

Re: svn commit: r534018 - in /cocoon: trunk/tools/cocoon-rcl/cocoon-rcl-plugin/ whiteboard/old-maven-plugins/cocoon-rcl-plugin/

Andrew Savory wrote:
> Hi,
> 
> On 1 May 2007, at 12:47, reinhard <at> apache.org wrote:
> 
>> Author: reinhard
>> Date: Tue May  1 04:47:14 2007
>> New Revision: 534018
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=534018
>> Log:
>> keep the old maven plugins easily accessible
>> for some time
>>
>> Added:
>>     cocoon/whiteboard/old-maven-plugins/cocoon-rcl-plugin/
>>       - copied from r534017, 
>> cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-plugin/
>> Removed:
>>     cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-plugin/
> 
> *sigh*
> 
> Reinhard, you're making my life _VERY_ difficult 
> 
> I see little discussion on the mailing list 

that's unfortunatly true but I can't do more than announcing things 
(http://marc.info/?l=xml-cocoon-dev&m=117705703514534&w=2). If nobody answers 
for more than 10 days!, I except that others agree.

> about this sort of change 
> (other than a brief "I've started to merge" a couple of days ago). I'm 
> happy that you're doing the work, but not happy at the pain it causes.

sorry for this.

> I'm trying to keep track of 2.2, document changes, and write slides on 
> using it ... but it's a frustrating experience! Having to trawl through 
> commit messages to find when things are about to move is painful. 

Though I think that this statement is not really fair, I understand your 
frustration.

> I 
> never know when a clean build on a new box is going to fail, because 
> jars are suddenly missing, moved or whatever. This has pretty much been 
> my experience for the last couple of months 
> 
> If you're at Apachecon, maybe we can have a beer and you can help me 
> understand all this?

sure

--

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: svn commit: r534018 - in /cocoon: trunk/tools/cocoon-rcl/cocoon-rcl-plugin/ whiteboard/old-maven-plugins/cocoon-rcl-plugin/

Reinhard Poetz napisał(a):
>> I see little discussion on the mailing list 
> 
> that's unfortunatly true but I can't do more than announcing things
> (http://marc.info/?l=xml-cocoon-dev&m=117705703514534&w=2). If nobody
> answers for more than 10 days!, I except that others agree.

Oups. I did not respond to your e-mail at first time because I wasn't sure why we need this deployer plug-in at
all and
I had not dug later on.
Sorry for that. I'll ask my questions in original thread.

--

-- 
Grzegorz Kossakowski

Re: Cocoon Maven plugin - Merging deployer & rcl

Reinhard Poetz napisał(a):
> Giacomo Pati wrote:
>> BTW: Can we have a released deployer plugin as well.
> 
> I think that Cocoon should only have one Maven plugin with as many goals
> as needed. Hence I propose that we merge the deployer and the reloading
> classloader plugin into a single one:
>  cocoon:deploy ..... provides shielding and *.xpatch support for "war"
>                      proejcts

Why we need cocoon:deploy at all? I remember that deployer was needed to do some assembly work but it's not needed
anymore because everything is performed at runtime, right?
What's that *.xpatch support? Functionality for patching web.xml file or something else?

>  cocoon:rcl ........ provides a minimal web environment for blocks
>                      ("jar") amd complete reloading of all resources
>                      (Cocoon resources, Java files, Spring context)
> 
> I'm sure that other goals will follow in the future (scaffolding,
> upgrade support, etc.).

It would be great if Cocoon had mechanisms to could make upgrading easier but to be honest I can hardly
imagine such
tool. Can you elaborate a little bit?
Oh, and what's "scaffolding" thing? (here, probably my poor English is showing off)

All in all, as usual your proposal is great and go ahead. I hope this changes will be straightforward and lead
to quick
release of Cocoon plug-in 

--

-- 
Grzegorz Kossakowski