Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. In the Maven issue (http://jira.codehaus.org/browse/MNG-624) the suggestion was made to use a variable. I'm not a big fan of that if it requires the variable always be set via -D or in the users settings.xml. Too much room to get it wrong. Using the version in the pom at the relative path you are sure to always get it right. The way my patch is right now if you specified MavenParentVersion as the version and it couldn't find the parent pom an exception would get thrown more or less as if a version wasn't specified. I suppose instead of throwing the exception it could try to find the pom some other way, but what? I have a feeling that if the way Cocoon's blocks parent pom was changed than what I'm suggesting would be easy. If the parent pom was in cocoon-blocks-parent instead of being the aggregation pom this would be a lot easier to deal with as you would only need the Cocoon parent project and the block parent project to create your block. Ralph
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [vote] Java 1.5 as minimal requirement for trunk
On Aug 5, 2008, at 9:07 AM, Grzegorz Kossakowski wrote: As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are more and more problems with keeping Java 1.4 compatibility in trunk. After a while it turned out that everybody agrees on the need for dropping Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal required version seems to be the best solution. In order to do that, we need a formal vote that I'm calling now. Please cast your votes: +1 Vadim
Re: [vote] Cocoon 3.0
On Aug 6, 2008, at 7:19 AM, Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. +1 Vadim
Re: Webdav and link-rewrite
On Aug 6, 2008, at 5:17 AM, Reinhard Pötz wrote: Reinhard Pötz wrote: I agree with you that we shouldn't support such stuff but what features do we want to see in a new LinkRewriteTransformer? (... hence my suggestion that we start with a ServletLinkRewriteTransformer because we know that we need it.) Any comments, otherwise I still believe that we only need a ServletLinkRewriteTransformer and will advise Lukas to go towards this direction. I'd suggest to start with ServletLinkRewriteTransformer. When/if needs for other features become clear, it should be possible to implement full version by extending from the basic ServletLinkRewriteTransformer version. Vadim
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Carsten Ziegeler wrote: Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. I'm not sure if there is an existing way of doing that. Even if there is, I'm not sure if that is a great idea. What if what is in your local repo is really old? Ralph
Re: [vote] David Legg as new Cocoon committer
On Mon, Aug 4, 2008 at 1:46 PM, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: ...I would like to propose David Legg as a new Cocoon committer and PMC Member +1 -Bertrand
How do I enable the reloading classloader in core/cocoon-webapp?
The subject says it all :-) Thx-in-advance, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: How do I enable the reloading classloader in core/cocoon-webapp?
Mark Lundquist wrote:
The subject says it all :-)
Thx-in-advance,
—ml—
The reloading classloader is only integrated with the prepare goal of
the Cocoon Maven plugin. And the prepare goal creates a simple wrapper
web application for a block.
In regard of your question this means that there is no way to use it
together with the cocoon-webapp module.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: How do I enable the reloading classloader in core/cocoon-webapp?
On Aug 7, 2008, at 10:13 AM, Reinhard Pötz wrote: Mark Lundquist wrote: The subject says it all :-) Thx-in-advance, —ml— The reloading classloader is only integrated with the prepare goal of the Cocoon Maven plugin. And the prepare goal creates a simple wrapper web application for a block. In regard of your question this means that there is no way to use it together with the cocoon-webapp module. All right then — well, how would I make a Cocoon webapp that can serve the samples blocks, and which uses the reloading classloader? —ml— smime.p7s Description: S/MIME cryptographic signature
Re: How do I enable the reloading classloader in core/cocoon-webapp?
On Aug 7, 2008, at 10:29 AM, Mark Lundquist wrote: All right then — well, how would I make a Cocoon webapp that can serve the samples blocks, and which uses the reloading classloader? Don't answer that, I'm gonna try to figure it out on my own. I'll ask again if I get stuck :-) cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. I'm not sure if there is an existing way of doing that. Even if there is, I'm not sure if that is a great idea. What if what is in your local repo is really old? I thought about this some more. How about if a) to enable this feature you put a variable as the version, b) the variable is replaced by its definition c) if it isn't defined then go to the relativePath and get the version from there, c) if this fails throw an exception. I believe this won't cause any problems since variables aren't currently supported. It is also what people have asked for in the Jira issue. Ralph
people.a.o m2-snapshot-repository
Reinhard P?tz wrote: Grzegorz Kossakowski wrote: I believe that this dependency was stored on our snapshots repository, but now it seems to be empty, see: http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/javaflow/ More interesting thing is that, it seems to be empty for any other artifact. Does anybody know what happened there? According to a mail from today on the [EMAIL PROTECTED], all snapshots older than 30 days were deleted in order to increase the free disk space. It concerns far more than that. Some projects are not following ASF legal procedures, and are using the snapshot repository instead of doing proper release procedures. See that thread on the infrastructure@ list. -David
Re: [vote] Java 1.5 as minimal requirement for trunk
Grzegorz Kossakowski wrote: Please cast your votes: +1 -David
