You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by gi...@apache.org on 2006/01/09 21:12:40 UTC
svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Author: giacomo
Date: Mon Jan 9 12:12:17 2006
New Revision: 367382
URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
Log:
try to fix issues with JMX but couldn't test it as current build.sh isn't working for a full build
Added:
cocoon/trunk/lib/core/mx4j-3.0.1.jar (with props)
Removed:
cocoon/trunk/lib/core/jetty-jmx-5.1.8.jar
cocoon/trunk/lib/core/mx4j-jmx-3.0.1.jar
Modified:
cocoon/trunk/lib/jars.xml
Added: cocoon/trunk/lib/core/mx4j-3.0.1.jar
URL: http://svn.apache.org/viewcvs/cocoon/trunk/lib/core/mx4j-3.0.1.jar?rev=367382&view=auto
==============================================================================
Binary file - no diff available.
Propchange: cocoon/trunk/lib/core/mx4j-3.0.1.jar
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Modified: cocoon/trunk/lib/jars.xml
URL: http://svn.apache.org/viewcvs/cocoon/trunk/lib/jars.xml?rev=367382&r1=367381&r2=367382&view=diff
==============================================================================
--- cocoon/trunk/lib/jars.xml (original)
+++ cocoon/trunk/lib/jars.xml Mon Jan 9 12:12:17 2006
@@ -1298,24 +1298,14 @@
<homepage>http://jdbi.codehaus.org/</homepage>
</file>
- <file id="mx4j-jmx">
- <title>JMX interfaces</title>
+ <file id="mx4j">
+ <title>JMX implementation</title>
<description>
- The JMX interfaces from the MX4J project.
+ The JMX implementation from the MX4J project.
</description>
<used-by>Core</used-by>
- <lib>core/mx4j-jmx-3.0.1.jar</lib>
+ <lib>core/mx4j-3.0.1.jar</lib>
<homepage>http://mx4j.sourceforge.net/</homepage>
- </file>
-
- <file id="jetty-jmx">
- <title>Jetty JMX</title>
- <description>
- Jetty JMX support for ModelMBeanImpl.
- </description>
- <used-by>Core</used-by>
- <lib>core/jetty-jmx-5.1.8.jar</lib>
- <homepage>http://jetty.mortbay.org/jetty/</homepage>
</file>
</jars>
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>
> The main thing that lacking and that is more complicated, is to deply
> all blocks into the cocoon-webapp. We did that with some ant code that
> copied configuration snippets to the right places. We have no
> replacement for that yet, but IIUC Reinhard and Jorg are working on some
> solution.
Right, my plan is to commit the Maven-indepandant stuff this week and start to
work on the (hopefully thin) Maven plugin, that will wrap the deployer, next week.
--
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: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jan 2006, Daniel Fagerstrom wrote:
> Date: Mon, 09 Jan 2006 23:47:31 +0100
> From: Daniel Fagerstrom <da...@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
> jars.xml
>
> Giacomo Pati skrev:
> ...
>> ATM non of our build tools is able to fully build Cocoon :-(
>
> The projects in the top level POM builds except for cocoon-core, and that
> depends on a missing dependency on JMXUtils that have been added since
> yesterday.
Oops, sorry. I've missed them. Will add immediately
> For the rest of the blocks they built under Maven a month ago or so. Since
> then the groupId and version has changed: apache-cocoon -> org.apache.cocoon
> and 2.2-SNAPSHOT -> 2.2.0-SNAPSHOT. By changing that everywhere and possibly
> some more things all the blocks should be possible to build with Maven again.
>
> The main thing that lacking and that is more complicated, is to deply all
> blocks into the cocoon-webapp. We did that with some ant code that copied
> configuration snippets to the right places. We have no replacement for that
> yet, but IIUC Reinhard and Jorg are working on some solution.
Ok.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDw1QVLNdJvZjjVZARAgnYAJ4xpLEvw3VM965uwas+7ioCL8sl0QCgtisQ
N+IPuwV02/ip1I0txwsq96c=
=/s/o
-----END PGP SIGNATURE-----
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Giacomo Pati skrev:
...
> ATM non of our build tools is able to fully build Cocoon :-(
The projects in the top level POM builds except for cocoon-core, and
that depends on a missing dependency on JMXUtils that have been added
since yesterday.
For the rest of the blocks they built under Maven a month ago or so.
Since then the groupId and version has changed: apache-cocoon ->
org.apache.cocoon and 2.2-SNAPSHOT -> 2.2.0-SNAPSHOT. By changing that
everywhere and possibly some more things all the blocks should be
possible to build with Maven again.
The main thing that lacking and that is more complicated, is to deply
all blocks into the cocoon-webapp. We did that with some ant code that
copied configuration snippets to the right places. We have no
replacement for that yet, but IIUC Reinhard and Jorg are working on some
solution.
/Daniel
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jan 2006, Jorg Heymans wrote:
> Date: Mon, 09 Jan 2006 21:21:05 +0100
> From: Jorg Heymans <jh...@domek.be>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
> jars.xml
>
>
> giacomo@apache.org wrote:
>> Author: giacomo
>> Date: Mon Jan 9 12:12:17 2006
>> New Revision: 367382
>>
>> URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
>> Log:
>> try to fix issues with JMX but couldn't test it as current build.sh isn't working for a full build
>
>
> build.sh is broken because of the repository flattening.
>
> I'm wondering actually how long we should still keep trunk/lib around.
> It can confuse people into thinking that this way of building is
> still/will still be supported.
ATM non of our build tools is able to fully build Cocoon :-(
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDwtYBLNdJvZjjVZARAuRiAKC2M1+7hweM5DZ7AjJi8xfPHMJskwCfahAi
s1RIa9lLqdMzQ+tyYpbU78E=
=IUG2
-----END PGP SIGNATURE-----
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 9 Jan 2006, Daniel Fagerstrom wrote:
> Date: Mon, 09 Jan 2006 21:58:59 +0100
> From: Daniel Fagerstrom <da...@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
> jars.xml
>
> Jorg Heymans skrev:
>> giacomo@apache.org wrote:
>>
>> > Author: giacomo
>> > Date: Mon Jan 9 12:12:17 2006
>> > New Revision: 367382
>> >
>> > URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
>> > Log:
>> > try to fix issues with JMX but couldn't test it as current build.sh isn't
>> > working for a full build
>>
>> build.sh is broken because of the repository flattening.
>>
>> I'm wondering actually how long we should still keep trunk/lib around.
>> It can confuse people into thinking that this way of building is
>> still/will still be supported.
>
> I would prefer removing the trunk/lib and Ant build system ASAP, and that
> everybody helps getting the parts they care for working with the Maven build.
Yes, ASAP!
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDwtffLNdJvZjjVZARAoWUAKDh2gUx6psdcAQuKLgLm0ynO9TffwCgkUyA
7DPqCmR50ih5DISYSqOfxzs=
=ggGP
-----END PGP SIGNATURE-----
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 10 Jan 2006, Leszek Gawron wrote:
> Date: Tue, 10 Jan 2006 09:23:46 +0100
> From: Leszek Gawron <lg...@mobilebox.pl>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
> jars.xml
>
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Tue, 10 Jan 2006, Leszek Gawron wrote:
>>
>> > Date: Tue, 10 Jan 2006 01:45:33 +0100
>> > From: Leszek Gawron <lg...@mobilebox.pl>
>> > Reply-To: dev@cocoon.apache.org
>> > To: dev@cocoon.apache.org
>> > Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
>> > core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar
>> > core/mx4j-jmx-3.0.1.jar
>> > jars.xml
>> >
>> > Daniel Fagerstrom wrote:
>> >
>> > > Leszek Gawron skrev:
>> > >
>> > > > Daniel Fagerstrom wrote:
>> > >
>> > > ...
>> > >
>> > > > > I would prefer removing the trunk/lib and Ant build system ASAP,
>> > > and > > that everybody helps getting the parts they care for working
>> > > with the > > Maven build.
>> > > > > > Before taking such drastic moves we should probably have a
>> > > full > replacement for current build system. Up till now we had quite
>> > > a nice > solution [1]. If we are to drop it we should resolve
>> > > following issues:
>> > > > > 1. developers/more advanced users often use trunk snapshots even
>> > > for > production (I have probably never used a released version :)).
>> > > If so > there has to be a support in our build system to deploy
>> > > artifacts not > only to apache repository but also to
>> > > company's/individual's repository. > I am not talking here about
>> > > simple 'mvn install' which only copies the > file on the same
>> > > computer to local repo.
>> > >
>> > >
>> > > The release plugin take care of this:
>> > > http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you
>> > > can
>> > > overide where it reads from, I'm not shure about if there if you can
>> > > override the release repository without changing the root POM.
>> >
>> >
>> > The official documentation states the only way to do this is to change
>> > cocoon's POM and that is not a solution I would advise to users.
>>
>>
>> I do not really understand the issue you are talking about (what would you
>> like to deploy to your own repo? Cocoon itself?) But maybe have a look at
>> the profile concept of Maven at
>>
>> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>>
>> A profile can be used similar to M1 build.properties but has much more
>> possibilities (overwriting distribution management things).
> Yes I would like to deploy cocoon jars to my own repo. I do not want to rely
> on snapshots held at cvs.apache.org because they might simply be deleted
> (they're snapshots after all). In order to do that I will have to modify main
> cocoon pom because these distributionManagement parameters may only be
> included in pom. From the link you pointed:
>
> <quote>Depending on where you choose to configure your profile, you will have
> access to varying POM configuration options. Profiles specified in external
> files (i.e in settings.xml or profiles.xml) are not portable in the strictest
> sense, because they externalize some of the build configuration from the only
> project metadata that is maintained on the remote repositories: the POM.
> Therefore, you will only be able to modify the repositories and
> pluginRepositories sections of the POM, plus an extra properties
> section.</quote>
>
> which means I cannot override distributionManagement config tag neither in
> settings.xml nor in profiles.xml
You're right. The distributionManagement is not in the scope of an
external profiles.xml. So, in your case you have to do what everybody is
doing: sync the remote repos.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDw3RHLNdJvZjjVZARAu9ZAKDdrqFoWa+N82XP/qe8OnkimZ5g2wCfQFBJ
OSxte7i/gkgHF9z6ACigDL8=
=t2eU
-----END PGP SIGNATURE-----
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> --- Leszek Gawron <lg...@mobilebox.pl> schrieb:
>
>>Yes I would like to deploy cocoon jars to my own
>>repo. I do not want to
>>rely on snapshots held at cvs.apache.org because
>>they might simply be
>>deleted (they're snapshots after all).
>
>
> Is it your intention not to use "mvn install"? This
> goal puts the project artifact into your local Maven
> repository.
Think of company with over a dozen programmers and 50+ cocoon based
project. You want your cocoon jars out of every project so you either
create a separate project and a build system (as I did) or you hope
maven will sort things out and create a company wide repository.
For example I am adding jx:atribute support to ctemplate. I build a
block snapshot and want to use it in production (most cocoon blocks are
stable enough to use them in snapshoted version). So now I not only want
the cocoon-template.jar residing in my local repo (which is trivial with
mvn install) but I also want to deploy it to company's repository so
every project may now reference it.
I do not like Giacomo's proposal: syncing snapshots from cvs.apache.org
does not give me control of what I am really holding in the repository.
If I build and deploy a snapshot myself after a year I have 5-10
snapshots all verified to be working. My cocoon newbie developers won't
make a mistake when choosing good binaries. If I just synced
cvs.apache.org I will have hundreds of snapshots not really knowing
which ones are working properly.
For me the best solution would be to provide my own repository in
setting.xml file and then when building cocoon do:
mvn -Dtake.precedence.for.deploy.configuration.from.settings.xml deploy
:)
same way I can have lots of OSS projects patched for my needs deploying
snapshots to company repo waiting for patches to get incorporated into
main sources and released.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Leszek Gawron <lg...@mobilebox.pl> schrieb:
> Yes I would like to deploy cocoon jars to my own
> repo. I do not want to
> rely on snapshots held at cvs.apache.org because
> they might simply be
> deleted (they're snapshots after all).
Is it your intention not to use "mvn install"? This
goal puts the project artifact into your local Maven
repository.
--
Reinhard
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 10 Jan 2006, Leszek Gawron wrote:
>
>> Date: Tue, 10 Jan 2006 01:45:33 +0100
>> From: Leszek Gawron <lg...@mobilebox.pl>
>> Reply-To: dev@cocoon.apache.org
>> To: dev@cocoon.apache.org
>> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
>> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar
>> core/mx4j-jmx-3.0.1.jar
>> jars.xml
>>
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron skrev:
>>>
>>> > Daniel Fagerstrom wrote:
>>>
>>> ...
>>>
>>> > > I would prefer removing the trunk/lib and Ant build system ASAP,
>>> and > > that everybody helps getting the parts they care for working
>>> with the > > Maven build.
>>> > > > Before taking such drastic moves we should probably have a
>>> full > replacement for current build system. Up till now we had
>>> quite a nice > solution [1]. If we are to drop it we should resolve
>>> following issues:
>>> > > 1. developers/more advanced users often use trunk snapshots even
>>> for > production (I have probably never used a released version :)).
>>> If so > there has to be a support in our build system to deploy
>>> artifacts not > only to apache repository but also to
>>> company's/individual's repository. > I am not talking here about
>>> simple 'mvn install' which only copies the > file on the same
>>> computer to local repo.
>>>
>>>
>>> The release plugin take care of this:
>>> http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
>>> overide where it reads from, I'm not shure about if there if you can
>>> override the release repository without changing the root POM.
>>
>>
>> The official documentation states the only way to do this is to change
>> cocoon's POM and that is not a solution I would advise to users.
>
>
> I do not really understand the issue you are talking about (what would
> you like to deploy to your own repo? Cocoon itself?) But maybe have a
> look at the profile concept of Maven at
>
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>
> A profile can be used similar to M1 build.properties but has much more
> possibilities (overwriting distribution management things).
Yes I would like to deploy cocoon jars to my own repo. I do not want to
rely on snapshots held at cvs.apache.org because they might simply be
deleted (they're snapshots after all). In order to do that I will have
to modify main cocoon pom because these distributionManagement
parameters may only be included in pom. From the link you pointed:
<quote>Depending on where you choose to configure your profile, you will
have access to varying POM configuration options. Profiles specified in
external files (i.e in settings.xml or profiles.xml) are not portable in
the strictest sense, because they externalize some of the build
configuration from the only project metadata that is maintained on the
remote repositories: the POM. Therefore, you will only be able to modify
the repositories and pluginRepositories sections of the POM, plus an
extra properties section.</quote>
which means I cannot override distributionManagement config tag neither
in settings.xml nor in profiles.xml
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 10 Jan 2006, Leszek Gawron wrote:
> Date: Tue, 10 Jan 2006 01:45:33 +0100
> From: Leszek Gawron <lg...@mobilebox.pl>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
> core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
> jars.xml
>
> Daniel Fagerstrom wrote:
>> Leszek Gawron skrev:
>>
>> > Daniel Fagerstrom wrote:
>>
>> ...
>>
>> > > I would prefer removing the trunk/lib and Ant build system ASAP, and
>> > > that everybody helps getting the parts they care for working with the
>> > > Maven build.
>> >
>> >
>> > Before taking such drastic moves we should probably have a full
>> > replacement for current build system. Up till now we had quite a nice
>> > solution [1]. If we are to drop it we should resolve following issues:
>> >
>> > 1. developers/more advanced users often use trunk snapshots even for
>> > production (I have probably never used a released version :)). If so
>> > there has to be a support in our build system to deploy artifacts not
>> > only to apache repository but also to company's/individual's repository.
>> > I am not talking here about simple 'mvn install' which only copies the
>> > file on the same computer to local repo.
>>
>>
>> The release plugin take care of this:
>> http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
>> overide where it reads from, I'm not shure about if there if you can
>> override the release repository without changing the root POM.
>
> The official documentation states the only way to do this is to change
> cocoon's POM and that is not a solution I would advise to users.
I do not really understand the issue you are talking about
(what would you like to deploy to your own repo? Cocoon itself?) But
maybe have a look at the profile concept of Maven at
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
A profile can be used similar to M1 build.properties but has much more
possibilities (overwriting distribution management things).
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDw1cYLNdJvZjjVZARAh6eAJ97YnUXjsiXXZ95KaU/GH6835LrhwCgwWub
yEkWk1EMmJgSYNN9kU+pXMU=
=QpIz
-----END PGP SIGNATURE-----
Re: Cocoon development using blocks
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Daniel Fagerstrom <da...@nada.kth.se> schrieb:
> That should allready work AFAIK.
great :-)
(I was only confused why somebody would want a
workaround for block specific properties.)
--
Reinhared
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Cocoon development using blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
>--- Daniel Fagerstrom <da...@nada.kth.se> schrieb:
>
>
>
>>Right now they don't. But if each block has a unique
>>namespace, we
>>probably could find some way to let the property
>>org.mydomain.myblock.foo set the block parameter
>>foo.
>>
>>
>
>This sounds like a workaround for now. Actually we
>want to use the properties from block.xml, right?
>
>
That works allready, the above was a possible complement.
>Another (related) question - see the XML below: Will
>this scenario of differently configured blocks be
>supported? (like in this example that blocks can use
>different database connections)
>
><wiring
>xmlns="http://apache.org/cocoon/blocks/wiring/1.0">
>
> <block id="core" location="core/"/>
>
> <block id="test1id" location="test1/">
> <mount path="/test1"/>
> <connections>
> <connection name="core" block="core"/>
> <connection name="test2" block="test2id"/>
> <connection name="test3" block="test3id"/>
> </connections>
> </block>
>
> <block id="test2id" location="test2/">
> <mount path="/test2"/>
> <properties>
> <property name="database-con" value="blahAAAA"/>
> </properties>
> </block>
>
> <block id="test3id" location="test2/">
> <mount path="/test3"/>
> <properties>
> <property name="database-con" value="blahBBBB"/>
> </properties>
> </block>
>
></wiring>
>
>
That should allready work AFAIK.
/Daniel
Re: Cocoon development using blocks
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Daniel Fagerstrom <da...@nada.kth.se> schrieb:
> Right now they don't. But if each block has a unique
> namespace, we
> probably could find some way to let the property
> org.mydomain.myblock.foo set the block parameter
> foo.
This sounds like a workaround for now. Actually we
want to use the properties from block.xml, right?
Another (related) question - see the XML below: Will
this scenario of differently configured blocks be
supported? (like in this example that blocks can use
different database connections)
<wiring
xmlns="http://apache.org/cocoon/blocks/wiring/1.0">
<block id="core" location="core/"/>
<block id="test1id" location="test1/">
<mount path="/test1"/>
<connections>
<connection name="core" block="core"/>
<connection name="test2" block="test2id"/>
<connection name="test3" block="test3id"/>
</connections>
</block>
<block id="test2id" location="test2/">
<mount path="/test2"/>
<properties>
<property name="database-con" value="blahAAAA"/>
</properties>
</block>
<block id="test3id" location="test2/">
<mount path="/test3"/>
<properties>
<property name="database-con" value="blahBBBB"/>
</properties>
</block>
</wiring>
--
Reinhard
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Cocoon development using blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron skrev:
>>
...
>>>> 3. How are we going to distribute .xconf files? As they are also
>>>> artifacts of some kind users shouldn't copy them into own project
>>>> and modify but rather xpatch them as it is performed now. I know we
>>>> have .xconf inclusion and multiple xconf files. Still there are
>>>> some things that inclusion does not solve.
>>>
>>> The .xconf files will be parametrized with the parts that users
>>> might be interested in changing, and a fixed .xconf will be included
>>> in the blocks jar.
>>
>> So how do I add my own cforms convertor? The only way to do it now is
>> xpatch.
>>
>> How do I parametrize continuations manager. It's current
>> configuration is rather incoherent:
>>
>> <continuations-manager logger="flow.manager" time-to-live="3600000"
>> session-bound-continuations="false">
>> <expirations-check type="periodic">
>> <offset>180000</offset>
>> <period>180000</period>
>> </expirations-check>
>> </continuations-manager>
>>
>> (BTW type="periodic" is not even parsed by the component :))
>>
>> We'll probably need to redesign the way some parts of our systems are
>> configured. I'd love to use Carsten's idea of property files to
>> parametrize components. After all almost every xml configuration can
>> be expressed with a set of properties.
>
> Blocks can be parameterized. I'm not sure how this will work together
> with Carsten's idea of property files.
Right now they don't. But if each block has a unique namespace, we
probably could find some way to let the property
org.mydomain.myblock.foo set the block parameter foo.
/Daniel
Cocoon development using blocks
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> Leszek Gawron skrev:
>>
>>> Daniel Fagerstrom wrote:
>>
>>
>> ...
>>
>>>> I would prefer removing the trunk/lib and Ant build system ASAP, and
>>>> that everybody helps getting the parts they care for working with
>>>> the Maven build.
>>>
>>>
>>>
>>> Before taking such drastic moves we should probably have a full
>>> replacement for current build system. Up till now we had quite a nice
>>> solution [1]. If we are to drop it we should resolve following issues:
>>>
>>> 1. developers/more advanced users often use trunk snapshots even for
>>> production (I have probably never used a released version :)). If so
>>> there has to be a support in our build system to deploy artifacts not
>>> only to apache repository but also to company's/individual's
>>> repository. I am not talking here about simple 'mvn install' which
>>> only copies the file on the same computer to local repo.
>>
>>
>>
>> The release plugin take care of this:
>> http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
>> overide where it reads from, I'm not shure about if there if you can
>> override the release repository without changing the root POM.
>
>
> The official documentation states the only way to do this is to change
> cocoon's POM and that is not a solution I would advise to users.
>
>>
>>> 2. Follow up for 1): jar names should include timestamps/revisions so
>>> one can have multiple production sites working on different cocoon
>>> versions.
>>
>>
>>
>> Take a look at
>> http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/
>>
>>
>> It is automatically generated by Continuum.
>>
>> Jorg have set up this.
>
> That is very nice. Still my own 'mvn install' should do the same.
> Imagine a contributor that creates some enhancement and wants to test it
> on it's own projects before submitting. He/she cannot use Jorg's
> snapshots.
Why not? If the user wants to use snapshots, he just points to the snapshot
repository at Apache. What's missing?
>
>>
>>> 2. cocoon is not only a set of jars. There is also a set of default
>>> resources (web.xml, main sitemap, stylesheets and so on). How do we
>>> ship that so users do not stay out of sync with jar versions?
>>
>>
>>
>> They will be included in the respectively blocks jar. And put in some
>> blocks unique package so that the framework can find them. Reinhard
>> work on this.
>
> To be sure: is it also the case for main sitemap.xmap?
There will be no main sitemap.xmap anymore, however one block can cover the "/"
URIs by mounting it to "/".
>>> 3. How are we going to distribute .xconf files? As they are also
>>> artifacts of some kind users shouldn't copy them into own project and
>>> modify but rather xpatch them as it is performed now. I know we have
>>> .xconf inclusion and multiple xconf files. Still there are some
>>> things that inclusion does not solve.
>>
>>
>>
>> The .xconf files will be parametrized with the parts that users might
>> be interested in changing, and a fixed .xconf will be included in the
>> blocks jar.
>
> So how do I add my own cforms convertor? The only way to do it now is
> xpatch.
>
> How do I parametrize continuations manager. It's current configuration
> is rather incoherent:
>
> <continuations-manager logger="flow.manager" time-to-live="3600000"
> session-bound-continuations="false">
> <expirations-check type="periodic">
> <offset>180000</offset>
> <period>180000</period>
> </expirations-check>
> </continuations-manager>
>
> (BTW type="periodic" is not even parsed by the component :))
>
> We'll probably need to redesign the way some parts of our systems are
> configured. I'd love to use Carsten's idea of property files to
> parametrize components. After all almost every xml configuration can be
> expressed with a set of properties.
Blocks can be parameterized. I'm not sure how this will work together with
Carsten's idea of property files.
I've started to write documentation about block usage and deployment and hope
that this will make things clearer (for me and for us). I will publish it at the
beginning of the next week as I don't want to confuse people with the current
state of the documents.
>>> I am working on lots of small cocoon based project. Because of the
>>> project count I found the [1] technique uniquely useful. I have
>>> created a ant based build system (similar to [2]) and isolated
>>> custom cocoon build into a subproject. This way my cocoon based
>>> projects do not contain any files copied over from cocoon distro.
>>> Everything stays in cocoon-build-system and with one simple
>>>
>>> ant -f cocoon.xml cocoon:get
>>>
>>> I update cocoon distro for every of my projects. I hope it will be
>>> that simple also with maven.
>>>
>>> [1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
>>> [2] http://javagen.com/jam/
>>
>>
>>
>> Maven also has the concept of archetypes, that make it possible to
>> generate different kinds of project templates. Jorg experimented with
>> that in the whiteboard.
>
> The problem is archetype is not good in cases when you manage lots of
> projects because it's merely a template. If you put web.xml into your
> archetype it will surely be outdated in a year. If you just xpatch the
> current version than you have no such problem. I resigned from copying
> any cocoon resource into my project because that brought a lot of
> problems. Gosh it was a nightmare to synchronize cforms resources before
> they were put into .jar file. In this case the solution was quite simple
> as the resources are easily extendable and they do not have to be
> changed. With other cocoon resources it is not that nice.
First, your Cocoon 2.2 projects will be blocks too. You will use the Cocoon
block archetype to create one. Then you will use the Cocoon webapp archetype
that only contains a description which blocks you want to use in your webapp
(war) and where you want to mount them. Additionally you will find there the
usual webapp stuff (web.xml, ...).
The rest will be done by the block deployer plugin and standard Maven plugins
like the webapp plugin. At least that's the plan.
--
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: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
> The problem is archetype is not good in cases when you manage lots of
> projects because it's merely a template. If you put web.xml into your
> archetype it will surely be outdated in a year. If you just xpatch the
> current version than you have no such problem. I resigned from copying
> any cocoon resource into my project because that brought a lot of
> problems. Gosh it was a nightmare to synchronize cforms resources before
> they were put into .jar file. In this case the solution was quite simple
> as the resources are easily extendable and they do not have to be
> changed. With other cocoon resources it is not that nice.
The archetype functionality we are seeing today is really only a useable
alpha version of what it eventually will become. If you'ld like to see
certain features added then we should either provide them ourselves or
ping the maven guys about it. I can imagine us extending the current
archetype with our own one that is able to xpatch xml files and update
an existing archetype with new files.
Jorg
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron skrev:
>
>> Daniel Fagerstrom wrote:
>
> ...
>
>>> I would prefer removing the trunk/lib and Ant build system ASAP, and
>>> that everybody helps getting the parts they care for working with the
>>> Maven build.
>>
>>
>> Before taking such drastic moves we should probably have a full
>> replacement for current build system. Up till now we had quite a nice
>> solution [1]. If we are to drop it we should resolve following issues:
>>
>> 1. developers/more advanced users often use trunk snapshots even for
>> production (I have probably never used a released version :)). If so
>> there has to be a support in our build system to deploy artifacts not
>> only to apache repository but also to company's/individual's
>> repository. I am not talking here about simple 'mvn install' which
>> only copies the file on the same computer to local repo.
>
>
> The release plugin take care of this:
> http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
> overide where it reads from, I'm not shure about if there if you can
> override the release repository without changing the root POM.
The official documentation states the only way to do this is to change
cocoon's POM and that is not a solution I would advise to users.
>
>> 2. Follow up for 1): jar names should include timestamps/revisions so
>> one can have multiple production sites working on different cocoon
>> versions.
>
>
> Take a look at
> http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/
>
>
> It is automatically generated by Continuum.
>
> Jorg have set up this.
That is very nice. Still my own 'mvn install' should do the same.
Imagine a contributor that creates some enhancement and wants to test it
on it's own projects before submitting. He/she cannot use Jorg's
snapshots.
>
>> 2. cocoon is not only a set of jars. There is also a set of default
>> resources (web.xml, main sitemap, stylesheets and so on). How do we
>> ship that so users do not stay out of sync with jar versions?
>
>
> They will be included in the respectively blocks jar. And put in some
> blocks unique package so that the framework can find them. Reinhard work
> on this.
To be sure: is it also the case for main sitemap.xmap?
>
>> 3. How are we going to distribute .xconf files? As they are also
>> artifacts of some kind users shouldn't copy them into own project and
>> modify but rather xpatch them as it is performed now. I know we have
>> .xconf inclusion and multiple xconf files. Still there are some things
>> that inclusion does not solve.
>
>
> The .xconf files will be parametrized with the parts that users might be
> interested in changing, and a fixed .xconf will be included in the
> blocks jar.
So how do I add my own cforms convertor? The only way to do it now is
xpatch.
How do I parametrize continuations manager. It's current configuration
is rather incoherent:
<continuations-manager logger="flow.manager" time-to-live="3600000"
session-bound-continuations="false">
<expirations-check type="periodic">
<offset>180000</offset>
<period>180000</period>
</expirations-check>
</continuations-manager>
(BTW type="periodic" is not even parsed by the component :))
We'll probably need to redesign the way some parts of our systems are
configured. I'd love to use Carsten's idea of property files to
parametrize components. After all almost every xml configuration can be
expressed with a set of properties.
>
>> I am working on lots of small cocoon based project. Because of the
>> project count I found the [1] technique uniquely useful. I have
>> created a ant based build system (similar to [2]) and isolated custom
>> cocoon build into a subproject. This way my cocoon based projects do
>> not contain any files copied over from cocoon distro. Everything stays
>> in cocoon-build-system and with one simple
>>
>> ant -f cocoon.xml cocoon:get
>>
>> I update cocoon distro for every of my projects. I hope it will be
>> that simple also with maven.
>>
>> [1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
>> [2] http://javagen.com/jam/
>
>
> Maven also has the concept of archetypes, that make it possible to
> generate different kinds of project templates. Jorg experimented with
> that in the whiteboard.
The problem is archetype is not good in cases when you manage lots of
projects because it's merely a template. If you put web.xml into your
archetype it will surely be outdated in a year. If you just xpatch the
current version than you have no such problem. I resigned from copying
any cocoon resource into my project because that brought a lot of
problems. Gosh it was a nightmare to synchronize cforms resources before
they were put into .jar file. In this case the solution was quite simple
as the resources are easily extendable and they do not have to be
changed. With other cocoon resources it is not that nice.
>
> In total Maven have a lot of functionality OOTB that help you with what
> you describe above. And with some customizing and own plugins we can
> make it even neater. Join the work and help make Cocoon builds as simple
> and powerful as possible :)
I am already resolving some issues with maven guys. I must say their
attitude towards helping a lame like me is impressive. Their IRC support
rocks.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:
>
> Take a look at
> http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/
>
>
> It is automatically generated by Continuum.
>
At the moment the snapshots are being generated by a shellscript [1].
Continuum will be setup again on the zone once trunk stabilizes.
Jorg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113294238131909&w=2
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron skrev:
> Daniel Fagerstrom wrote:
...
>> I would prefer removing the trunk/lib and Ant build system ASAP, and
>> that everybody helps getting the parts they care for working with the
>> Maven build.
>
> Before taking such drastic moves we should probably have a full
> replacement for current build system. Up till now we had quite a nice
> solution [1]. If we are to drop it we should resolve following issues:
>
> 1. developers/more advanced users often use trunk snapshots even for
> production (I have probably never used a released version :)). If so
> there has to be a support in our build system to deploy artifacts not
> only to apache repository but also to company's/individual's repository.
> I am not talking here about simple 'mvn install' which only copies the
> file on the same computer to local repo.
The release plugin take care of this:
http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
overide where it reads from, I'm not shure about if there if you can
override the release repository without changing the root POM.
> 2. Follow up for 1): jar names should include timestamps/revisions so
> one can have multiple production sites working on different cocoon
> versions.
Take a look at
http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/
It is automatically generated by Continuum.
Jorg have set up this.
> 2. cocoon is not only a set of jars. There is also a set of default
> resources (web.xml, main sitemap, stylesheets and so on). How do we ship
> that so users do not stay out of sync with jar versions?
They will be included in the respectively blocks jar. And put in some
blocks unique package so that the framework can find them. Reinhard work
on this.
> 3. How are we going to distribute .xconf files? As they are also
> artifacts of some kind users shouldn't copy them into own project and
> modify but rather xpatch them as it is performed now. I know we have
> .xconf inclusion and multiple xconf files. Still there are some things
> that inclusion does not solve.
The .xconf files will be parametrized with the parts that users might be
interested in changing, and a fixed .xconf will be included in the
blocks jar.
> I am working on lots of small cocoon based project. Because of the
> project count I found the [1] technique uniquely useful. I have created
> a ant based build system (similar to [2]) and isolated custom cocoon
> build into a subproject. This way my cocoon based projects do not
> contain any files copied over from cocoon distro. Everything stays in
> cocoon-build-system and with one simple
>
> ant -f cocoon.xml cocoon:get
>
> I update cocoon distro for every of my projects. I hope it will be that
> simple also with maven.
>
> [1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
> [2] http://javagen.com/jam/
Maven also has the concept of archetypes, that make it possible to
generate different kinds of project templates. Jorg experimented with
that in the whiteboard.
In total Maven have a lot of functionality OOTB that help you with what
you describe above. And with some customizing and own plugins we can
make it even neater. Join the work and help make Cocoon builds as simple
and powerful as possible :)
/Daniel
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jorg Heymans wrote:
> Leszek Gawron wrote:
>
>
>
>>1. developers/more advanced users often use trunk snapshots even for
>>production (I have probably never used a released version :)). If so
>>there has to be a support in our build system to deploy artifacts not
>>only to apache repository but also to company's/individual's repository.
>> I am not talking here about simple 'mvn install' which only copies the
>>file on the same computer to local repo.
>
>
> If you want to deploy your own project artifacts (say a custom block)
> then you would just mvn release this to your repo. Why would you need to
> modify cocoon's pom.xml ?
Maybe I'm missing something but how can you do that without modifying pom?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
> 1. developers/more advanced users often use trunk snapshots even for
> production (I have probably never used a released version :)). If so
> there has to be a support in our build system to deploy artifacts not
> only to apache repository but also to company's/individual's repository.
> I am not talking here about simple 'mvn install' which only copies the
> file on the same computer to local repo.
If you want to deploy your own project artifacts (say a custom block)
then you would just mvn release this to your repo. Why would you need to
modify cocoon's pom.xml ?
> 2. Follow up for 1): jar names should include timestamps/revisions so
> one can have multiple production sites working on different cocoon
> versions.
snapshots can be made with a timestamped name. The SVN revision is not
included at the moment IIRC, you might want to raise this with the maven
people. I remember maven1 has something that allows the svn revision to
be included in META-INF for example.
> I am working on lots of small cocoon based project. Because of the
> project count I found the [1] technique uniquely useful. I have created
> a ant based build system (similar to [2]) and isolated custom cocoon
> build into a subproject. This way my cocoon based projects do not
> contain any files copied over from cocoon distro. Everything stays in
> cocoon-build-system and with one simple
>
> ant -f cocoon.xml cocoon:get
>
> I update cocoon distro for every of my projects. I hope it will be that
> simple also with maven.
>
I reckon similar mechanisms will crystalize out of our build system once
more people get involved.
Jorg
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Jorg Heymans skrev:
>
>> giacomo@apache.org wrote:
>>
>>> Author: giacomo
>>> Date: Mon Jan 9 12:12:17 2006
>>> New Revision: 367382
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
>>> Log:
>>> try to fix issues with JMX but couldn't test it as current build.sh
>>> isn't working for a full build
>>
>>
>> build.sh is broken because of the repository flattening.
>>
>> I'm wondering actually how long we should still keep trunk/lib around.
>> It can confuse people into thinking that this way of building is
>> still/will still be supported.
>
>
> I would prefer removing the trunk/lib and Ant build system ASAP, and
> that everybody helps getting the parts they care for working with the
> Maven build.
Before taking such drastic moves we should probably have a full
replacement for current build system. Up till now we had quite a nice
solution [1]. If we are to drop it we should resolve following issues:
1. developers/more advanced users often use trunk snapshots even for
production (I have probably never used a released version :)). If so
there has to be a support in our build system to deploy artifacts not
only to apache repository but also to company's/individual's repository.
I am not talking here about simple 'mvn install' which only copies the
file on the same computer to local repo.
2. Follow up for 1): jar names should include timestamps/revisions so
one can have multiple production sites working on different cocoon versions.
2. cocoon is not only a set of jars. There is also a set of default
resources (web.xml, main sitemap, stylesheets and so on). How do we ship
that so users do not stay out of sync with jar versions?
3. How are we going to distribute .xconf files? As they are also
artifacts of some kind users shouldn't copy them into own project and
modify but rather xpatch them as it is performed now. I know we have
.xconf inclusion and multiple xconf files. Still there are some things
that inclusion does not solve.
I am working on lots of small cocoon based project. Because of the
project count I found the [1] technique uniquely useful. I have created
a ant based build system (similar to [2]) and isolated custom cocoon
build into a subproject. This way my cocoon based projects do not
contain any files copied over from cocoon distro. Everything stays in
cocoon-build-system and with one simple
ant -f cocoon.xml cocoon:get
I update cocoon distro for every of my projects. I hope it will be that
simple also with maven.
[1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
[2] http://javagen.com/jam/
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jorg Heymans skrev:
> giacomo@apache.org wrote:
>
>>Author: giacomo
>>Date: Mon Jan 9 12:12:17 2006
>>New Revision: 367382
>>
>>URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
>>Log:
>>try to fix issues with JMX but couldn't test it as current build.sh isn't working for a full build
>
> build.sh is broken because of the repository flattening.
>
> I'm wondering actually how long we should still keep trunk/lib around.
> It can confuse people into thinking that this way of building is
> still/will still be supported.
I would prefer removing the trunk/lib and Ant build system ASAP, and
that everybody helps getting the parts they care for working with the
Maven build.
/Daniel
Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar
core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Posted by Jorg Heymans <jh...@domek.be>.
giacomo@apache.org wrote:
> Author: giacomo
> Date: Mon Jan 9 12:12:17 2006
> New Revision: 367382
>
> URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
> Log:
> try to fix issues with JMX but couldn't test it as current build.sh isn't working for a full build
build.sh is broken because of the repository flattening.
I'm wondering actually how long we should still keep trunk/lib around.
It can confuse people into thinking that this way of building is
still/will still be supported.
Regards
Jorg