[jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ https://issues.apache.org/jira/browse/COCOON-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niclas Hedhman updated COCOON-1301: --- Reporter: Niclas Hedhman (was: Niclas Hedhman) [Patch] Image Operation Reader -- Key: COCOON-1301 URL: https://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Inactive Cocoon committers and PMC members
On Wednesday 14 March 2007 16:51, Bertrand Delacretaz wrote: I agree with all parts. Perhaps with the exception that I am even less active on Cocoon, but follow it more for historical and emotional reasons... Cheers Niclas
Re: [vote] Jeroen Reijn as a new Cocoon committer
On Monday 05 March 2007 16:19, Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. +1. Welcome! Cheers Niclas
Re: [vote] Felix Knecht as a new Cocoon committer
On Tuesday 06 March 2007 03:38, Reinhard Poetz wrote: +1 Welcome Cheers Niclas
Re: SVN Source for Cocoon
On Monday 05 March 2007 17:49, Lars Trieloff wrote: Hi Reinhard, - SVN source: a source that reads a local subversion repository and provides the content, supports revisions etc. (read-only) http://www.mindquarry.org/repos/mindquarry-workspace/trunk/ mindquarry-dma-source/ how to you access SVN? Are you using a ASL-compatible base library? (http://people.apache.org/~cliffs/3party.html) We access SVN through the means of a Spring Bean. This Bean acts either as a wrapper to Subversion's native JavaHL API, which unfortunately requires native code or to SVNKit, which is not ASL- compatible. So while I see not much chances of integrating this into Cocoon, it sill might be interesting for projects using coocoon. How does Maven2 access SVN remote repositories?? Doesn't whatever they use be able to help out in this case? Cheers Niclas
Re: [graphics] Artwork for cocoon.apache.org - final4
On Friday 02 March 2007 16:50, Reinhard Poetz wrote: - Thien, your CLA was properly recorded by the ASF secretary. In order to make your contribution official, I would like to ask you to add the final layout to a JIRA issue. I'm sure that Niclas can help you with that, otherwise don't hesitate to contact my in private. Ok, will try to remember to get that done on Monday or Tuesday, when Thien says he is back at work (long honey moon ;o) ). Cheers Niclas
Re: [vote result] Grzegorz Kossakowski as a new Cocoon committer
On Friday 02 March 2007 23:13, Bertrand Delacretaz wrote: Besides the obvious reasons to rejoice about a new committer, Hip, hip, Hooray I'm particularly happy as a) It feels good to have people here who are not even half my age Ditto... Cheers Niclas
Re: [graphics] Artwork for cocoon.apache.org - new version
On Thursday 22 February 2007 19:16, Arje Cahn wrote: Many thanks to all of you who have pushed this forward, and please keep those good vibes going! Also give Thien some peace, as he is prepping up for his wedding shortly... (Sorry Thien, the world need to know.) Cheers Niclas
Re: [vote] Grzegorz Kossakowski as a new Cocoon committer
On Friday 23 February 2007 00:36, Daniel Fagerstrom wrote: I'd like to propose Grzegorz Kossakowski (aka Grek) as a new Cocoon committer. He has been around at the user list since 2003 and has been very active at the dev list the last months. He has provided a number of high quality patches and in depth design discussions in complicated areas. Please cast your votes. +1. Cheers Niclas
Re: Ideas for student projects
On Sunday 18 February 2007 17:32, Reinhard Poetz wrote: Michael Wechner wrote: Reinhard Poetz wrote: Google announced the 3rd summer of code and this year. The Austrian Computer society launched a similar project, the OSS Contest Austria 2007. We as Cocoon project can make proposals about possible student projects. If you have ideas for such projects, add them to http://wiki.apache.org/cocoon/StudentProjectIdeas2007. The more ideas we have, the better for us! the link http://osscontest.ocg.at/ doesn't seem to work. And idea what might be wrong? works for me :-/ Does a DNS lookup on osscontest.ocg.at work for you? Not here either... [EMAIL PROTECTED]:~$ dig osscontest.ocg.at ; DiG 9.3.2-P1 osscontest.ocg.at ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 11277 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;osscontest.ocg.at. IN A ;; AUTHORITY SECTION: ocg.at. 10800 IN SOA ocglx.ocg.or.at. resch.ocg.or.at. 172 10800 3600 604800 86400 ;; Query time: 592 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Tue Feb 20 14:59:31 2007 ;; MSG SIZE rcvd: 90
Re: [graphics] New version of masthead
On Monday 05 February 2007 04:40, hepabolu wrote: I don't want to bias you, but I like it a lot. ;-) Perhaps I am even more biased... but I like it as well. Cheers Niclas
Re: [graphics] New version of masthead
On Tuesday 06 February 2007 00:22, Peter Hunsberger wrote: Very nice. I'm with the camp that would like to see it shrink a little, not much but just a little. Also, I still find it a little on the pastel side, I'd like to see a version with bolder colors. And I realize that asking developers for opinion on style and good taste is like asking sheep farmers to comment on Versace's latest designs; They are in the supply chain, but hardly the target audience... ;o) Perhaps widening the audience to the user's lists is a good move. Cheers Niclas
Re: OSGi blocks development?
On Thursday 01 February 2007 04:16, Daniel Fagerstrom wrote: Also it was a quite large work to integrate Spring and OSGi. And when we saw that a project doing that started within the Spring community with some OSGi heavyweights involved, it seemed like a better idea to stop our own development in that area and either join them or being lazy and wait for them to deliver something ;) I just came back from the initial kick-off meeting of the Enterprise Expert Group in the OSGi Alliance. One of the interesting things are that Spring will get a central focus in OSGi Enterprise, and many of the Spring OSGi guys (Adrian Coyler for instance) is part of the EEG. I expect a strong convergence, so that not only will Spring become a first class citizen in OSGi, but also vice versa. So, from a Cocoon perspective, I think it is a wise choice to continue the Springification and just keep an eye on the features that the Spring OSGi team are introducing features from the OSGi side of the fence, such as dynamicity and peer-classloaders. End of the day, I don't think Cocoon will need to do a lot for full OSGi support. Cheers Niclas
Re: org.apache.cocoon:cocoon-maven-reports:jar:1.0 missing
On Friday 26 January 2007 00:26, Vadim Gritsenko wrote: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html My guess: he does not like Sun's whitespace policies :-P Code convention written by vi and emacs nerds of the 80s, with 80x24 character VT100 terminals, really sux... Saving screen real-estate is not a concern anymore. Readability is. But change in this field is like mass conversion of religious devotees... ;o) Cheers Niclas
Re: Artwork for cocoon.apache.org - next steps
On 1/23/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Isn't it possible to send in CCLA/ICLA documents as scanned documents either? I remember some disucussions some months ago but don't know what the outcome was. Does anybody know? Not sure, but this is about the legal system catching up with advances in technology... There are quite a lot of this type of paper work we have to sort out this week here at the office, so one more shouldn't be a problem. Cheers Niclas
Re: [graphics] Masthead artwork for cocoon.apache.org
On Friday 19 January 2007 20:35, hepabolu wrote: Let me first say, I think all are fabulously done and show off your skills. And thanks for putting them into context. I reviewed this stuff earlier, without the full page, and I must say that the perception changed a bit. My preference also lies in #2 or #3. Cheers Niclas
Re: [RT] Add schema validation for sitemap
On Friday 19 January 2007 07:24, Fred Vos wrote: I think it's a great idea to have a schema. A good schema is an excellent source of documentation. Especially when full of annotations, enumerations, limits, patterns et cetera. +1. Also think that some users of Cocoon are not programmers, but they are probably all fairly comfortable with XML at large. Providing a Scheme is great for these. Whether or not schema validation should be available/default is perhaps less important at this point. Cheers Niclas
Re: Artwork for cocoon.apache.org - next steps
On Monday 22 January 2007 19:06, Reinhard Poetz wrote: And, as it was discussed recently on the Apache legal list, a design is a copyrighted creation and if you haven't already provided, we need a license agreement so that we are allowed to use it. Thien, the best option for this would be getting an ICLA (http://apache.org/licenses/#clas) from you. Could you please go through the text and if you haven't any questions send a signed ICLA to the Apache Software Foundation? Otherwise just let us know what is unclear to you. I guess I need to sign off a CCLA as well. We will do this, although logistics are a bit troublesome (no fax), so it will probably be by snail mail. I'll see what I can do about it. Cheers Niclas
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Monday 18 December 2006 16:26, Ralph Goers wrote: So I would think trunk should be released as 3.0, if for no other reason than allow the next 2.1 release to be 2.2.0 without jdk 1.3 support. I agree (and with Helma's elaboration). Personally, I don't understand the intense resistence of bumping the numbers in Cocoon community. A change in 3 digit in Cocoon could mean anything from a tiny bug fix to loads of new functionality, and now potentially incompatible with running system... Let the numbers tick... Cheers Niclas
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tuesday 19 December 2006 00:14, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. Amen and/or Amin and/or your favourite holy blessing. Cheers Niclas
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tuesday 19 December 2006 03:13, Mark Lundquist wrote: On Dec 18, 2006, at 7:15 AM, Ralph Goers wrote: That is a valid concern. We kind of painted ourselves in a box by calling trunk 2.2 way before it was ready to be anything. Agreed, IMHO all future releases beyond 2.2 (will that actually be 2.2.0?) should use internal code names until right before we cut the release. Then we can have the numbering discussions and settle on the right thing without any historical encumbrance. Very good observation. What will Maven think of versionlycaenidae-SNAPSHOT/version?? Cheers Niclas [1] http://en.wikipedia.org/wiki/Lycaenidae
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Thursday 14 December 2006 07:55, Alfred Nathaniel wrote: I therefore propose to declare 2.1.10 the last release with JDK1.3 compatibility. Please cast your votes. As Antonio points out, a vote in this fashion ain't totally kosher. We are supposed to discuss the items and if a consensus is reached during the discussion the vote is superflous. discussion Personally, I don't care about the 1.3 compatibility, as I have moved all my involvement to Java 5, but that is IMHO not relevant. If we have made a prior commitment of keeping the 2.1.x compatible with JDK1.3, then that should stand. It should not be a matter of what a handful developers think. They are usually on the curring edge anyway, but what the user community are depending on. It is these type of inconcistencies that drives users away from a project, and by now Cocoon I feel Cocoon has a rather low reputation and considered a niche and novel project that one can't use in 'real' projects. If we find it hard to maintain, then let that be it and stop evolving it. Saying that we keep evolving 2.1.11+ in JDK1.4 (assumingly backporting stuff from 2.2.x) and on top of that maintain a 2.1.10.x line for bug fixes seems even more work to me. I would be voting -1 in behalf of unheard users. Cheers Niclas
Re: [graphics] Masthead artwork for cocoon.apache.org
On Thursday 07 December 2006 06:34, Jorg Heymans wrote: I've never heard about Cocoon requiring 100% SVG for its gfx. It sure sounds cool but IMO we should not dictate this - we'll most likely render the SVG to JPG or PNG anyway for the website. Not talking about requiring, but 1. SVG - PNG == no problems. 2. SVG scaling == no problems. 3. PNG scaling == big problems. 4. Thien normally works with Illustrator, and handing over SVG instead of rendered PNG is not a big deal. Cheers Niclas
Re: [RT] Improved matching selecting
On Monday 04 December 2006 06:02, Mark Lundquist wrote: I see that this would have to wait 'til C3, according to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1181.html And in a future C3, could it be possible that the entire sitemap is abstracted out, a. into a standalone component, b. with a stricter programmatic interface as its primary API, both for re-use in other projects as well as easier changes in the future? Anyway, I like your effort... Cheers Niclas
Re: [graphics] Masthead artwork for cocoon.apache.org
On Friday 01 December 2006 11:23, Thien wrote: Hello!! Cool, I will give this a try. Hope to show you some artworks soon. The information I have so far is good enough but if you have any ideas or suggestions, please do tell me. Thien: I would also like to point out that Cocoon is all about XML processing, and not sure if you know that SVG is XML, and the prefered (one might even say required) source format of any work produced. Cheers Niclas
Graphics Designer for Cocoon
Gang, I have just hired a Graphics Designer here at CodeDragons, and we don't think we will manage to fill his pipeline with commercial work from the start. I have previously promised that he will be available some of the time for work at Cocoon. He knows html and css a little bit, but it is not his main skill. He makes graphics. Icons, logos, photo assemblies and so forth. I have not hired him for Flash work, but I think he know a bit of that as well. His name is Thien Luh Tay, and will shortly start subscribing to this list, which is probably as alien as a Hortoculture mailing list would be to most of us. He is also not experienced in open source, nor doing work on distance. So, I am requesting a few things; 1. Any thread you start that you want him to read, put [graphics] in the subject. That would make it real easy for him to filter the scary noise. 2. Start thinking of what kind of stuff you want him to do. 3. Try to educate in a friendly manner, the principles of OSS collaboration. I am on the road and not reading my mail very often, so I won't be around to follow up how this goes until I am back in the office in 10-14 days. Cheers Niclas
Re: imageop-block in 2.2
On Tuesday 24 October 2006 15:55, Geert Josten wrote: Hi Niclas, 1. Rotation of images will not produce the expected result. I never managed to figure out how to make it work, and probably need to dig deeper into the Java2D stuff (not my ball game). I have been experimenting myself with making the image reading rotate images. I added this helper function, that does the tricky part. Note that I decided to do rotation in steps of 90 degrees to keep things simple.. ;-) The problems with the rotations are related to; a) clipping (can't remember if it happened for N * 90 rotations as well), b) 'black' and not 'transparent' in the areas the image no longer occupy. AffineTransform for rotating any angle is not the problem, but I think one need to prepare the space needed before the rotation is executed. I spent quite alot of time on it, but in the end we didn't need it so I dropped it altogether. Cheers Niclas
Re: imageop-block in 2.2
On Friday 20 October 2006 17:13, Lars Trieloff wrote: In cocoon 2.1 there is an imageop-block that allows more powerful image transformations then the standard image reader. It is based on a contribution https://issues.apache.org/jira/browse/COCOON-1301 but not yet ported to Cocoon 2.2. Since it was I who contributed it somehmmm... 2(?) years ago, I should actually do it myself now that I am a worthy committer ;o) Well... Just want you to know that there are outstanding issues with it. IIRC; 1. Rotation of images will not produce the expected result. I never managed to figure out how to make it work, and probably need to dig deeper into the Java2D stuff (not my ball game). 2. Certain types of TIFF encodings will result in incorrect colors when converted. It is not all TIFFs, and I have not even managed to figure out which does and which doesn't work. 3. Installation of Java Advanced Imaging must be done. Never bothered to figure out if it can be used ad-hoc, or must be installed into the JRE as we did in the project (easiest approach). But besides that, scaling and conversions of images are lightening fast, and we deployed a couple of 'thumb nail' style photo library sites (NO, not porn) and a product catalog for both web and print. I got feedback from Stefan Pietschmann, and it might be that he has additional info/changes available... Cheers Niclas
Re: [RANT] The Cocoon website: move on, nothing is happening here
On Wednesday 18 October 2006 03:51, Steven Noels wrote: What those Belgian guys however (in)frequently murmured amongst themselves was: why the stupid fixation with SVN as a required content repository for official ASF documentation sites? Why can't cocoon.apache.org simply be a proxy for http://cocoon.zones.apache.org/daisy/documentation/ ? I think it is related to the principles of primary resources; - mailing lists - subversion - ? which infrastructure works hard to make sure are operational, backed-up, fail-over, disaster planning et al. Wiki and other stuff is not considered primary, and doesn't enjoy the attention of the infrastructure folks. Cheers Niclas
Re: [Vote] Release 2.2M1
On Sunday 30 July 2006 17:12, Carsten Ziegeler wrote: Please cast your votes on the release of 2.2M1 on monday, 31st of August. The release consists of the core together with the required parent modules and tools to the maven repository. In addition we will release a demo webapp for easy download with some samples. Is milestone considered snapshot and development releases ?? Just wondering from a Maven Repository point of view. +0 (can't help) Cheers Niclas
Re: [Vote] Ard Schrijvers as a new Cocoon committer
On Friday 28 July 2006 13:44, Reinhard Poetz wrote: I want to propose Ard Schrijvers as a new Cocoon committer. +1 WELCOME. Cheers Niclas
Re: Choreographed releases (was [RANT] This Maven thing is killing us....)
On Wednesday 05 July 2006 18:29, Steve Loughran wrote: Now that Cocoon is using OSGi, does that change versioning rules? Because that lets components run different versions of things side-by-side, doesnt it? To some extent. Individual Java Packages can be versioned and one can declare a runtime dependency on a specific, ranged or 'later than' version of a package. But problems will still surface. A dependsOn B A dependsOn C ver1.0 (only) B dependsOn C ver1.1 (or later) In such case, the classes of C may clash and therefor OSGi will not be able to (reliably) resolve A (i.e. 'wire' the classloading) and therefor not attempt it. But in many cases it is possible to have scenarios working, which may not even be possible to build from Ant and Maven, hence the Eclipse insistence on having their own build system, which resolves OSGi packages according to the spec. Cheers Niclas
Re: [RANT] This Maven thing is killing us....
On Tuesday 04 July 2006 20:53, Carlos Sanchez wrote: If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Well, since Cocoon is going for OSGi, this does not need to be a problem per se. However, Maven currently doesn't support the CP resolution needed in complex OSGi builds (such as Eclipse itself). There are people investigating what would be needed, but no promises have been made so far. One main issue is that OSGi is not concerned over versioning of the jars, but versioning of the packages (normal Java packages for the uninitiated). More exactly, the jar is essentially just a delivery container of the packages, and the resulting classpath may be a subset of a jar and mixed in with packages from another version of the same jar. For the record; Ant is not capable of handling this perfectly either. Also; Very often it is not need for OSGi development. Cheers Niclas
Re: [RANT] This Maven thing is killing us....
On Saturday 01 July 2006 20:41, Bertrand Delacretaz wrote: -Use our own/ASF repository, managed in SVN Our own Stefano Mazzocchi has recently suggested this, and AFAICT work has been started. The idea is to have both release and snapshot repos operating on ASF infrastructure, and replicated to the download mirrors. Have not followed the progress on this though. Check the archive for [EMAIL PROTECTED] Cheers Niclas
Re: [RANT] This Maven thing is killing us....
On Monday 03 July 2006 01:29, Jorg Heymans wrote: I just spoke to Jason, he mentioned that ibiblio will go away soon. That statement actually worries me quite a lot. AFAIU, the central repo is going to Mergere (a VC funded company) sponsored host(s). And this/these host(s) have to me shown to be VERY fragile. Often requests fails, even with the standard browser. What happens *if* Mergere runs out of juice and flip the switch off? Cheers Niclas
Re: [Vote Result] New committers
On Wednesday 21 June 2006 05:00, Joerg Heinicke wrote: Congratulations Andreas, Peter and Jason. You all have been elected with 21 positive and no negative votes to become committers of the Cocoon project. Welcome! Great to see Cocoon project recognizing important work beyond patches. Guys, Welcome and enjoy. Cheers Niclas
Re: [2.2] Release?
On Monday 19 June 2006 14:40, Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: Regardless of the name, I think we should take a little bit more time and use the ApacheCon hackathon to prepare this first release and then release (or upload) right after the ApacheCon. Then let's release in the first week of July *whatever* we have by then. This should also be the starting signal for a time-based release cycle (see my other answer to this mail). :) Sorry to be a little pita here, but I will vote against a release in the first week of July *if* the situation with the samples is still the same. If this is fixed by then I'll be fine :) Could the compromise be that the 'release' == 'alpha/beta/grokmake' with the README listing '* Examples a,b,c not working,' ?? Striving for perfection before action, is a paradox as perfection can only be obtained by fine-tuning the action. I would +1 a improved release every week. Small steps. Little to consider. Fast Forward. Done, Next!, Done! ... Anybody still around from the Cocoon 1.0 times ?? Cheers Niclas
Re: [2.2] Release?
On Sunday 18 June 2006 12:10, Torsten Curdt wrote: /www/people.apache.org/maven-snapshot-repository (which is the same as the above) is the apache maven2 snaphot repository. Only releases(!!) may be deployed to /www/www.apache.org/dist/java-repository which is getting synchronized with ibiblio. But the problem is that /www/www.apache.org/dist/java-repository is a Maven1 (!) repository, and not Maven2... I asked about this a few days ago on repository@ but I think the mail drowned in the many commit mails presently being posted there. Cheers Niclas
Re: [2.2] Release?
On Sunday 18 June 2006 14:08, Niclas Hedhman wrote:
On Sunday 18 June 2006 12:10, Torsten Curdt wrote:
/www/people.apache.org/maven-snapshot-repository (which is the same as
the above) is the apache maven2 snaphot repository. Only releases(!!)
may be deployed to /www/www.apache.org/dist/java-repository which is
getting synchronized with ibiblio.
But the problem is that /www/www.apache.org/dist/java-repository is a
Maven1 (!) repository, and not Maven2...
Just found the answer on the [EMAIL PROTECTED] list.
/www/www.apache.org/dist/maven-repository/
I am pasting the README file from that directory;
-bash-2.05b$ cat /www/www.apache.org/dist/maven-repository/README.txt
http://www.apache.org/dist/maven-repository
This is a Maven 2.0+ repository for deployment of official Apache releases.
DO NOT INCLUDE THIS IN YOUR PROJECT REPOSITORY LIST - USE A MIRROR
Please follow these rules when deploying to this repository:
- only deploy releases voted on by the PMC
- sign all artifacts and POMs (currently, this is a manual step)
- never deploy snapshots or development releases to this repository
- ensure that if a release is deleted from /dist/, it is removed from here
completely also (excluding archiving)
- no artifacts are allowed from projects under incubation
- make sure you have your maven settings correctly set to make directories
group writeable.
This repository is not currently synced automatically to Ibiblio and the Maven
mirrors. Please request this at dev@maven.apache.org after deploying here.
This repository is archived to
http://archive.apache.org/dist/maven-repository/
and synced to iBiblio with a no-delete option, so things can be deleted from
apache and still available through ibiblio
IMPORTANT:
Permissions should be
775 for directories
644 for files
Which can be done in Maven 2 settings.xml with
server
idapache.releases/id
directoryPermissions775/directoryPermissions
filePermissions644/filePermissions
/server
server
idapache.snapshots/id
directoryPermissions775/directoryPermissions
filePermissions644/filePermissions
/server
Due to a bug in Maven (http://jira.codehaus.org/browse/MDEPLOY-28)
maven-metadata.* files need to have 664 permissions
Run these commands to fix the permissions of your files after deployment:
snapshots:
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 775 -type d -user
${USER} -exec chmod 775 {} \;
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 664 -iname
maven-metadata.xml* -user ${USER} -exec chmod 664 {} \;
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 644 ! -iname
maven-metadata.xml* -type f -user ${USER} -exec chmod 644 {} \;
releases:
find /www/www.apache.org/dist/maven-repository ! -perm 775 -type d -user
${USER} -exec chmod 775 {} \;
find /www/www.apache.org/dist/maven-repository ! -perm 664 -iname
maven-metadata.xml* -user ${USER} -exec chmod 664 {} \;
find /www/www.apache.org/dist/maven-repository ! -perm 644 ! -iname
maven-metadata.xml* -type f -user ${USER} -exec chmod 644 {} \;
Re: [2.2] Release?
On Thursday 15 June 2006 13:44, Jorg Heymans wrote: The poms are correctly configured for the release plugin AFAIK, you should just be able to run the goals and get something going. Ok, cool. Please note that we don't want to release all blocks, so you'll have to do a non-recursive release of the root pom first, then core, and then all other blocks separately in their normal dependency order. IMHO, that is not very clever, just creates a lot of work for nothing. If something is not official I normally remove the entry from the modules, and as things get ready, add them in. Cheers Niclas
Re: [2.2] Release?
On Thursday 15 June 2006 04:39, Jorg Heymans wrote: Carsten Ziegeler wrote: Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. core has a dependency on the licenses block, does that cover your legal requirements ? As to how to actually do the release, unsure. If it was me doing it next week i would do something like this for the maven part of things: 1. change the poms manually to reflect the correct version number of the core (eg 2.2.0M1 or whatever). Also change the version number of each module itself to be non-snapshot (eg 1.0-SNAPSHOT becomes 1.0). 2. tag 3. mvn source:jar javadoc:jar repository:bundle-create for each module we're releasing, don't forget the module poms 4. bump the version numbers for all modules, 1.0.0 becomes 1.0.1-SNAPSHOT or 1.1.0-SNAPSHOT etc. Reset the version number of core back to 2.2.0-SNAPSHOT. 4. create a jira issue for the jars to be uploaded, described here http://maven.apache.org/guides/mini/guide-ibiblio-upload.html I think that Maven's Release plugin is expected to handle all of that in one go. mvn release:prepare mvn release:perform However, the latest Release plugin (beta4) has regressed and in my cases working less well than the beta3 (which I would recommend). What is needed is that the POM(s) are properly configured for the Release process. At least distributionManagement, scm and the configuration for the release plugin must be correctly specified. Possibly a repository as well. I'll give it a go later today and see what is missing and try to figure out what should go in there... Cheers Niclas
Re: [Vote] New committers
1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Cheers Niclas
Re: [2.2] Release?
On Thursday 15 June 2006 12:33, Niclas Hedhman wrote: I think that Maven's Release plugin is expected to handle all of that in one go. Let me clarify that; Provided that there are no SNAPSHOT dependencies... Cheers Niclas
Re: [GT2006] Call for ideas part 1: summary
On Sunday 04 June 2006 23:41, Reinhard Poetz wrote: This could lower the barrier for people (like me) to prepare something as doing a one-hour talk needs a lot of preparation, a 5 to 10 minutes presentation is much simpler. You have not heard what a US President (JFK?) once answered when asked how long he needed to prepare a speech; If it is 5 minutes long, I need a few weeks. If it is 20 min I need a day, and if it is an hour or longer I can start right away... (or something along those lines). ;o) Cheers Niclas
Re: Automatic releases
On Monday 29 May 2006 16:24, Reinhard Poetz wrote: Having a -SNAPSHOT-dependency is not an option for several reasons (snapshots are changing, you can't release your own artifacts if you depend on snapshots). I agree myself that this is a common problem. So what are the possible solutions: a) Everybody learns to run the release plugin and produces artifacts himself and can deploy them to his own repositories. Question (to Jorg): Is this possible at all (IIUC the release plugin automatically tags your release in SVN)? And if yes, how difficult is it? I have also noticed (for instance for artifacts I need from Felix) that release:prepare will fail, unless you have commit access to the SVN. b) Find an automated way (note: I don't write automatic release) to produce unoffical artifacts like cocoon-core-2.2-r434343-NIGHTLY-BUILD.jar. I am curious to know how this is different from the changing snapshot that is a problem mentioned above. IIUIC, both are temporary and will disappear in due time, so the only difference would be the name itself. I don't have the answer how it should be dealt with. I think the closes you can do is that the Continuum build output is copied into an area, either on the cocoon zone or to cocoondev, which is not official and even some big disclaimers that it is not official. Please observe that Apache Legal@ may have some comment of this, still. I suggest that there is a check with legal-discuss@apache.org before going down this route. Cheers Niclas
Re: Blocks and packages
On Monday 29 May 2006 05:17, Daniel Fagerstrom wrote: Is it possible to have an OSGi bundle which exports classes of two jars? A bundle is packaged as a jar, so it is not possible for two separate jars. A bundle can contain internal jars that are added to the bundle internal classpath. There is no problems to export packages from the Jars that resides inside the bundle jar. ANd no problems that several jars are having the same packages inside, as these are then part of the same OSGi classloader. There is something called fragments in R4 where a fragment bundle can add optional things to another bundle. I haven't studied the details about them though. Fragments essentially works like this; A Fragment can say Hey, I should be part of bundle ABC, and then the classloader of ABC will append the packages that the Fragment provides. The Fragment will stay inside ABC until ABC is uninstalled, even if the fragment is stopped and uninstalled. Typical use case is Fragments adding Localization, simply by providing the properties files needed with the correct name. So, here is another case where the classloader have no problem of merging content from different jars. Now, for those interested; Check out what happens if you sign and seal a Jar in the standard JDK... Food for thought, and an issue for the security paranoid. Cheers Niclas
Re: Automatic releases
On Monday 29 May 2006 18:40, Reinhard Poetz wrote: Having my Cocoon PMC member hat on, I have another problem with Maven artifacts: They don't contain licensing information or a NOTICE file. As in the future, Maven artifacts will be our actual releases (everything else is just for demos), I'm not sure if this is legally correct. Does anybody know of some discussions? Usually I'm following [EMAIL PROTECTED] but can't recall of a thread dealing with this problem. IIRC, each project is required to declare the NOTICE file in the POM, so it will be included in the released artifact. But I can't remember the details of that. Furthermore, I think it is even somewhat more complex than that since I suspect there will be both artifact releases (jars) which nobody looks inside, as well as the more conventional tar.gz and zip releases that are exploded and NOTICE becomes a lot more visible... I'll make a quick check with repository@ and see if there is any input on that. Cheers Niclas
Re: Automatic releases
On Thursday 25 May 2006 04:06, Reinhard Poetz wrote: But basically you're right that we have to clarify the situation in general. How shall we proceed to get an answer to the question of unofficial artifact releases? Is the [EMAIL PROTECTED] in the position to decide such things itself our do we have to discuss this issue with [EMAIL PROTECTED] WDOT? Automatic releases are not a possibility, for two main reasons; 1. Resources ; Someone pointed out how many artifacts would be created (and in fact Maven will generate a bunch more, such as .pom, .sha1, .md5, .pom.md5, .pom.sha1. Someone else suggested that these would only exist until the next release. That is also not an option. Maven relies on the fact that any build will work 'forever', as old artifacts does not disappear. 2. Legal ; ALL releases from ASF MUST be under the oversight of the responsible PMC. That means active insight and control of what is put into the release, and vouching legally that this is a non-malicious artifact suitable for consumption under a set of constraints. Automatic releases bypasses such legal responsibility, and will be found unacceptable by the Board and legal counsel. The obvious solution to the problem is smaller components with independent release cycles, but we know that since *years*... Cheers Niclas
Re: [jira] Commented: (COCOON-1765) Logging
On Thursday 13 April 2006 22:58, Reinhard Poetz (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1765?page=comments#action_12374 349 ] Reinhard Poetz commented on COCOON-1765: Fortunatly one of our latest committers is working on an OSGi logging framework: http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging Pax Logging is about letting each thing use their preferred logging system, but having it routed into a Log4J driven backend. So far, it supports a native one, Log4J and Jakarta Commons Logging, and I am trying to figure out how to support JDK logging as well. Of course, I can add support for Avalon Logging API if there is interest. It should not be too hard. Please advice. Cheers Niclas
Re: cvs.a.o dependency reduction
On Thursday 06 April 2006 04:11, Jorg Heymans wrote: I think that the minimum requirement is to have the libs in a repo-compliant directory structure. No need. One could use systemPath/ instead. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html See section System Dependencies Niclas
Re: [vote] Simone Gianni as a new Cocoon committer
On Friday 24 March 2006 18:19, Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. Has anyone directed Simone to get the paperwork in order? Simone; You need to download, read, understand and if approve, sign and fax or postal mail the Contributor License Agreement to the ASF Secretary. Fax number and address is on the form. http://www.apache.org/licenses/#clas You should also read; http://www.apache.org/dev/new-committers-guide.html http://www.apache.org/dev/committers.html Once that is done, the Cocoon PMC needs to forward an account creation request to [EMAIL PROTECTED]; Details for that is found at; http://www.apache.org/dev/pmc.html#newcommitter Finally, the Cocoon PMC Chair (Sylvain) is expected to update the authorization for the subversion repository. Cheers Niclas.
Re: [vote] Niclas Hedhman as a new Cocoon committer
On Friday 24 March 2006 02:26, Daniel Fagerstrom wrote: Hi all! I'd like to propose Niclas Hedhman as a new Cocoon committer. He has been around at cocoon-dev since 2000, regularly delivering insight full comments about technical as well as community questions, high quality patches and strong opinions in various topics ;) He has been and is committer and active in several other Apache projects and have started some OS projects outside Apache. He is also an expert member of JSR 291 (OSGi), and earlier JSR-78 (RMI Custom Remote References). Please cast your votes. Thank you all. I have been around Cocoon since the first day, when Stefano dropped a note on this new cool way of delivery on the JServ mailing list, and asked if anyone thought it was a good idea to start a project around it. Those were the days when mailing lists were hosted on workingdogs, it was new, it was fresh, it was exciting and Cocoon offered a radical new approach on server side processing. The 1.x series exposed a lot of problems with the initial reactor design, and the ver 2 was started, several times. It was painful, but definately worth it. Ver 2 added Cocoon product after cool. Since these days, Cocoon has matured and grown bigger, some say grown too big. Too big for its own good. It is not modular enough. Blocks were invented to save the day. It helped some, but the real blocks concept eluded the grasp of community. Real blocks requires fundamental changes, and too many people remember the pain of the 1.x to 2.x transition and swear never again. Either small steps or no steps. I feel OSGi is last chance for Cocoon to revitalize itself, and enter a 3rd generation of exciting technology. The importance of OSGi is enormous (you will hear more in due time) and the Cocoon community must prepare itself for; * Binary, hot-pluggable binary blocks of functionality. * Binary, hot-pluggable extensions to the Cocoon framework. * GUI clients deploy in the Cocoon instance for management/monitoring tasks. * Multiple implementations of well-accepted services. * Multiple incompatible versions of the same feature co-existing in runtime. * Hot-pluggable content, sub-sites, portlets. * Quicker turn-around on releases. * Faster pace of development, and more non-disruptive experiments. * Flash, Java, XUL and whatever MS is up to as richer clients. * User workbenches. * real Rich Clients probably Eclipse-based applications. * and a lot more... Cocoon has for very long been a integration platform where all kinds of cool stuff works together. Even things that were never meant to work together has been implemented. Keeping this up will become ever more complicated, but with better modularity, binary pluggability, and a large and dedicated community, it will be possible. Now, with all that said; Ironically, I am no longer a Cocoon user. I found new toys, doing a lot less web and more RCP, embedded and mobile stuff. So, suddenly being voted into Cocoon as a committer is awkward... However, I will try to help Daniel, Reinhard and others with the OSGi side of things as much as I can. I urge everyone to try and get an understanding of what OSGi is, and what it means to Cocoon. Daniel have tried to explain it many times at different levels, but due to its enormous impact on everything, it is difficult for most developers here to see the light. I will try to find, or even make, some introductory material, and slowly associate each of the basics into how Daniel et al are applying that to Cocoon. Maybe I will even start using Cocoon again as a result of this :o) Cheers Niclas P.S. The introduction mentions strong opinions... :o) I am as blunt as beach ball and don't do well in political organizations, but the Avalon debacle taught me one thing; Relax, it is not important! and I feel much more relaxed nowadays. Or maybe that is because of my 2yr old son...
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Wednesday 22 March 2006 01:00, Jorg Heymans wrote: Niclas Hedhman wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. ... You can point your pom to use the cvs.a.o directly. What do you mean here? You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots available cross-ASF projects. I still maintain that checking in the libs to SVN are much more comfortable than a dependency on a temporary server. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Tuesday 21 March 2006 02:32, Jorg Heymans wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. This sounds like a really odd idea. You can point your pom to use the cvs.a.o directly. - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) If it is not on the central repo, it is a non-released version and questionable that anyone should depend on it. - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). Since you will need to manually clean this up here, perhaps sending the file over to the Maven peeps is collectively a better idea. - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) IMHO, a questionable practice. (see below) Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. Now think again; After you have done this, and decommissioned the temporary solution, you are in a position of a non-working slot in time for that source. This goes both for SNAPSHOTs (which are actively being removed from their temporary storage spaces) and temporary artifact hosts. If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. Cheers Niclas
Re: FYI: OSGi JSR
On Tuesday 28 February 2006 21:20, Stefano Mazzocchi wrote: These two JSRs are heading on a massive collision course. Not if the people involved don't want that to happen. The most important difference (as I see it) between the two is that JSR-291 is a fast track add-on for those who want it now (debatable how long that is, as you pointed out). And for people like me, who are not on an upgrade train to JDK5 yet(!), which has been out ~2years already, and unlikely to run JDK7 for the next 4-5 years, I think JSR-291 is providing a reasonable middle-ground. Should it be a JSR?? Why not? Most JSRs are formalizations of stuff that already exist... And IIRC, Stefano, you are in the camp rather something that works today, than the perfect system in a few years ;o) If JSR-277 will come up with something that surpasses every bit and corner of the JSR-291, then GREAT! Let me remind you of a good enough collection API way back in time, I think it was simply called JCL. It was available in 1997 (perhaps earlier) and solved me a great deal of work back then. When the official Collection API came out, its purpose was ending... No shame in that. :o) Cheers Niclas
Re: Extending the image reader
On Monday 30 January 2006 18:00, Upayavira wrote: Well, sounds like you're trying to achieve something similar to caching. I wonder if the caching system might be an alternative approach to achieving the same thing. There is an ImageOpReader sitting in JIRA[1] as a contribution, which didn't gain enough interest to be included in the main/block distro. I never got to complete the parts that I don't use, but essentially we generate any sized image (out of really high-res tiff images), including thumbs, for browsing, for computer view and print. I am surprised at how quick the Java2D libraries can be and the caching in Cocoon seems to work nicely (at least for our relatively low traffic sites). Cheers Niclas [1] http://issues.apache.org/jira/browse/COCOON-1301
Re: [RT] The Real Component Simplification
On Thursday 05 January 2006 23:37, Berin Loritsch wrote: I don't recall if we tested extending where the URLStreamHandlers are located using the |java.protocol.handler.pkgs system property. The general problem with the java.protocol.handler.pkgs is revolving around an obscure bug (which Sun will not fix) which gives the side effect that those protocol handlers MUST sit in system classloader (or higher), and that is somewhat troublesome for products like Cocoon. IMHO, a big pity, since one could have done so much funky stuff with URL handlers otherwise. The interesting thing around this is that the internal code that handles this probably been refactored so that an additional method call is introduced on the call stack. Reason, it looks at the callstack a couple of levels away and tries to determine the callee and use its classloader. But it is always seeing java.net.URL which classloader is null, so it calls ClassLoader.getSystemClassLoader(). I have been arguing over this since JDK1.2 came out, but Won't fix. is the categorical reply from Sun. Cheers Niclas
Re: [VOTE] preliminary wrap-up
On Friday 06 January 2006 02:26, Berin Loritsch wrote: Tag the trunk before you start, and then again afterwards. Tag == copy == backup, so it may sound a bit contradictory to Jorg. And although copy in SVN is very cheap, I am finding this CVS practice less important, since all commits are atomic and good commit messages can be reviewed and identifying when things happen. But maybe just me. Cheers Niclas
Re: [RT] Simplifying component handling
On Saturday 31 December 2005 11:47, Berin Loritsch wrote: Also note that Pico can work with setter injection as well as constructor injection So does Spring. Cheers Niclas
Re: [RT] Simplifying component handling
On Saturday 31 December 2005 02:09, Carsten Ziegeler wrote:
My final idea is to use even more magic (but it might be too much magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
Yipee, yet another thread on a new container architecture. Can't wait to see
the hours of debate leading up to no change...
Honestly guys, I'm starting to think that Cocoon won't manage to do the
separation from Avalon, purely due to the number of ways to do it exceeds the
number of strong-willed people in the community, and disagreements of what is
the best move.
Time for me to close the shop, and start with something more exciting.
Bye and Good Luck.
Niclas Hedhman
Re: Roadmap, Vision and everything
On Friday 16 December 2005 00:53, Jorg Heymans wrote: well it's not just the cocoon artifact i'm talking about. Various of our dependent libs aren't on ibiblio yet, so i uploaded them to cvs.apache.org. Ok. But even better if you coordinate with the Maven peeps, so that everyone else gets the benefit in the same breath. Perhaps I wasn't clear; There is a mirror from the ASF infrastructure to the Maven repository on ibiblio.org, so all ASF committers can publish to ibiblio.org, if only following some guidelines (sorry no link for these at this point in time). Cheers Niclas
Re: [RT] Ditching the environment abstraction
On Wednesday 14 December 2005 09:31, Sylvain Wallez wrote: Both make very much sense. Which means cleaning up the mess everywhere ;-);-) Granted. I just wanted to say that for me, improvemets in either is good. But that the discussion left out who is most important now, and if that is established, it becomes fairly obvious of what to do next, and avoiding the ping-ponging of whether this or that implementation detail will make Cocoon cleaner. Cheers Niclas
Re: Roadmap, Vision and everything
On Thursday 15 December 2005 03:52, Jorg Heymans wrote: - sign off repository usage of cvs.apache.org (will possible get hit by a *large* number of downloads once we do a release) or move dependencies to ibiblio With the use of M2 and the proper upload locations for Cocoon stuff, everything will end up on iBiblio, so don't worry too much about large number of downloads... Cheers Niclas
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. Two more releases this year, YEAH!!! That's a remarkable spirit ;o) Just kidding... I think Carsten is right, stablize and release 2.2 ASAP. Cheers Niclas
Re: [RT] Ditching the environment abstraction
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote: From a users perspective (= the average Cocoon developer), most of the messiness is hidden. She does not have to deal with how the tree processor works, or with implementing an own pipeline etc. All these interfaces and components should be well hidden to her. Apparently, you guys need to discuss who you are targetting, before agreeing on what to do about it; Daniel - talking Cocoon internals developer, hoping to extend the number of active participants in Cocoon core development. Carsten - talking about making things better for developers of Cocoon components. Both make very much sense. Cheers Niclas
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Thursday 08 December 2005 02:10, Daniel Fagerstrom wrote: With this I measn that you can use the parts of Cocoon that you like, in the way you like in your webapp, without having to buy a whole religion. Being a devout atheist, I must +1000 this one. Niclas
Re: [RF] Chainsaws and Seeds
On Friday 09 December 2005 02:21, Stefano Mazzocchi wrote: And in terms of moving the equi-cost point to the left, there are two fundmentally different variables to consider. for instance, if t y = a * b / x ` \/ total cost of ownership (y) ^ | o | o | | o | | o v | o \ 2. | o\ |o 1. +-- complexity (x) 1. Essential focus on lessening the threshold, i.e. lower a. 2. Increasing the power of the functionality that are required for really complex systems, i.e. increasing the root base. Often, these are also interlinked, and it is important that the lowering of a doesn't make ( b 1 )... I think everyone are at this point focusing on 1. The market talks about quick starters and Cocoon peeps wants to me too in that area. I don't give a flying fart about RubyOnRail as my gut says that it doesn't make it easier to become the next Rembrandt, only providing me with more cryons than the other kids. I think Stefano's RF is great. He challenges people's presence and motivations. If you want to do weblog apps - GO. If you want to DB record viewer app - GO. If you want JAWA (Just Another Web Application) - GO. GO - because there are 50 other frameworks out there, all of them with their strengths, weaknesses and hype. I am sure there is some that suits YOU, as well as me. JAWA is not why I keep my interest... The reason to stay, is not to compete with Struts, Tapestry, Wicket, RoR, PHP and every other JAWA framework out there. The orthogonality of Cocoon has died. Noone talks about views. Noone highlights the ability to serve same content to many user agents. Noone is interested in truly useful smaller components. Noone cares about the developer vs designer vs deployer roles. I am predicting that the next round of waves will not be around delivering HTML or XML to web browsers, AJAX or not. It will center around dedicated clients. And not _any_ client - but the Mobile clients. And this is a lot more interesting to Cocoon than one first realizes. 1. Cocoon is already equipped to serve mobile clients, both WML and binary formats. No change required. 2. The most important aspect is the ability to generate media for different device models. No change required. 3. Americans have no clue about what is about to happen. Europeans are better prepared, and Cocoon is apparently a very European project. So, all of you who wants JAWA, Cocoon may not be the best tool. I don't think we should even try to become the best. Cocoon is already great in many aspects. We should concentrate on this, and become the defacto standard for mobile backends. Finally, my take on what Cocoon Really Needs. Cocoon needs a New Vision Statement. One paragraph of what Cocoon is all about, that blows my (the user's) mind away. Cocoon needs better Marketing. Struts didn't become Struts by developers complimenting each other on how great they were. Grab the opportunity of becoming the mobile backend 'standard'. Cocoon needs new Architecture. Marc's to the point list of how to get that organized is a good starting point. Cocoon needs better Documentation. Yeah, yeah, I know the story ;o) My 2 cents. Niclas
Re: [RF] Chainsaws and Seeds
On Saturday 10 December 2005 19:20, Stefano Mazzocchi wrote: Niclas Hedhman wrote: The orthogonality of Cocoon has died. Noone talks about views. Noone highlights the ability to serve same content to many user agents. Noone is interested in truly useful smaller components. Noone cares about the developer vs designer vs deployer roles. Hmmm, interesting, didn't see it this way. I wonder if it's because the real life forces those role to hybridize over and over, if we didn't make the right choice in separating them or because really nobody cares. If nobody really cares, then I wonder what in hell are we still thinking in terms of SoC! I think that is purely a matter of who is in the studied group. When you started Cocoon, you had the vision to look beyond the developer, and saw that scalability is a problem and went out to create a solution. But, somehow Cocoon didn't manage to reach out to those where this was important, instead it became the geek tool, and that part of the vision eroded. I am predicting that the next round of waves will not be around delivering HTML or XML to web browsers, AJAX or not. It will center around dedicated clients. And not _any_ client - but the Mobile clients. I very strongly disagree. Mobiles are getting richer and richer, and the HTML browser software is becoming more and more commoditized. It might be easier for everybody to deliver XHTML with Ajax-retrieved CSS and content than to do it the other way around. Ok, we disagree. Time will show what the future holds. You think the client side will converge over the next 5 years, I say it will diverge a lot, fueled by the inadequacy of HTML and ever higher demanding users, with new set of challenges. But the important point is not that you can do it, it's all those borderline cases where you *can'* and, therefore, your complexity starts to increase dramatically. Agree. And this is a lot more interesting to Cocoon than one first realizes. 1. Cocoon is already equipped to serve mobile clients, both WML and binary formats. No change required. Sure, but that's really not that hard to achieve. Really? I take it you are not authoring too many mobile apps atm. The capabilities varies enormously from model to model. Look at the number of JSRs that each model support or not. And that is just the Java world. Then throw in a bunch of other platforms and the mess is complete. 2. The most important aspect is the ability to generate media for different device models. No change required. Pipelines are first class citizens in Cocoon land, but you are talking to one use of it, one that makes you happy. I'm happy if that happens, but there are others. The important part is to keep the pipeline machinery as first class, yet make it easier to use even in other usecases. See Sylvain's proposal for dynamic and scripted pipelines. Agree. 3. Americans have no clue about what is about to happen. Europeans are better prepared, and Cocoon is apparently a very European project. That's complete bullshit. It is true that multi-modal appeal appears more in Europe than in the US, A bit of a flame-bait, agreed. But face it, there is no mobile communication culture in the USA to speak of. Will it change? Yes, I am sure, but not over night. Developers also derives from expectations, so where the end-user demand is high, a larger set of development efforts will start. If you don't believe me, you need to go to Japan or Korea. As I said, cocoon is designed for situations where the number of people involved, the number of technologies involved, the number of existing legacy, the number of future complexity is so high that other technologies don't work. Mobile portals? sure, one of them. Banking data interchange? yup. Pharma and Avionic 1000-pages long manual creation and management? you got it. Intranets for fortune 500 companies? yup. These are all applications where Cocoon has shined. Do you see the pattern? I see the pattern that a very large crowd out there thinks Cocoon is not good at anything, perhaps with the exception of pure document publishing. Instead of being known as the framework of Good enough for everything it is more known as Not good enough for anything. The inertia between those two are minute, and all the fancy stuff now being discussed won't change much of that. I have been with Cocoon a long time and talking my head off to get others to use it. In a couple of cases, I succeeded, but most of the time not. I have now given up, and don't recommend it for any typical JAWA setup. I don't recommend it where it makes the most sense (large complex organic systems), since I don't feel the vision is there anymore, and don't want to be blamed for bringing in a framework that fell apart due to community entropy. Cocoon need less people that write email and don't write code, myself included. :o) Ok, I'll go to the same corner and shut up as well
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Wednesday 07 December 2005 23:56, Sylvain Wallez wrote: * No IDE support for JavaScript There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4] that does autocompletion of function and argument names, plus tooltips and all that stuff. Really?? How can it do code completion since the type is not known until runtime? In IDEA the completion only handles the DOM binding and some rare cases when the type can be derived. As for JS being easier for non-Java peeps, my take is; 1. To make JS useful the developers exposes useful object bindings. 2. There is no development environment to contend with. Align those and the JS vs Java argumentation becomes a different experience altogether. Adding to that is, the times when I have seen non-Java peeps making anything useful on JS-serverside is when they already know JS well from client development. So, the take is a lot about profiling the target before making hard-core decisions that JS is better for flow than Java. I, for one, can't stand JS, due to runtime hell. I very much agree with everything Berin have said in this thread. Cheers Niclas
Re: a new cocoon logo?
On Wednesday 02 November 2005 18:30, Jorg Heymans wrote: Agreed, but a new logo when we release 2.2 or 3.0 would be highly desirable from a marketing point of view. The current one is starting to show its age IMO. The reason that you drink Coca-Cola, smoke Marlboro, drive Mercedes and buy Sony camcorders, is decades of focused branding. Part of the branding are logotypes, which by coincidence doesn't change, just because the company feels it needs to re-invent itself or have a new model/product out. Logotype changes are rare and extremely expensive from a marketing point of view. Example; A company in Sweden changed name from LM Ericsson to Ericsson and did a logotype change, from the original 1800s something to a new one, in the 1980s, since they wanted to re-invent themselves to be more consumer oriented. Massive discontent among the swedish population, since the company was known there as EllEm. I think it took about 8-10years for that to settle in, and a massive bill of marketing to back it up. Software in general, and OSS in particular is perhaps too new to understand and harness these mechanisms, but we can see strong awareness from Microsoft, Intel and even Linux around these concerns. Don't throw away assets that can't easily be replaced. Cheers
Re: [RT] Rules for adding blocks and functionality?
On Monday 24 October 2005 02:20, Daniel Fagerstrom wrote: * We really need to get rid of obsolete stuff. Must really every single block go to 2.2? Are there some oneman shows that better could be returned to their creator and driven on source forge or Cocoon-dev? Agree, but to accommodate people who thinks elsewise, deprecate old stuff in 2.2, then in the 3.0 all the deprecated stuff is 'gone'. I would like to propose; 1. Make Apache Cocoon 3.0 into the slim down, no frills, no blocks, no nothing, thing that has been discussed recently. 2. Create subprojects in Apache Cocoon for heavily used blocks, which every user can't live without. Since blocks are bundles, something like the Oscar Bundle Repository would make it a piece of cake for users to install them. 3. Create a user friendly block exchange elsewhere (cocoon-dev), where developers can publish and categorize their creations even if they are not Cocoon committers. A kind of Wiki brought to Coding, which I find useful. The 'deprecated' stuff is moved here, for the sake of availability, and allowance to fix bugs et cetera. Rhymes well with Daniel's assertion that it becomes the user's reponsibility to maintain. As well as, Don't kill old stuff. and Respect the past expressed by others. IMHO, this stiffness around must have a functioning developer community is a bit irritating at times. E.g. given a choice of a chunk of code without community support that does what I need, versus writing the stuff myself... What do I choose ?? For massive codebases, platforms and hard-to-solve problem domains, the healthy community is important, but the closer to No other options, than I have to do it myself you get, the lesser sense such a stance make. And small blocks, IMO, falls into such category. Cheers Niclas
Re: [VOTE RESULTS] new committer: Max Pfingsthorn
On Friday 14 October 2005 17:20, Jean-Baptiste Quenot wrote: Congratulations for becoming a new Apache member and Cocoon committer. For the record; committer != ASF Member. Apache member is a bit ambigious, and is hopefully refering to a broader, friendlier term... :o) Cheers Niclas
Re: Roadmap for Cocoon Blocks
On Wednesday 12 October 2005 22:21, Daniel Fagerstrom wrote: Also Niclas Hedman have moved his post Merlin/Metro work to use context dependency injection and it is built uppon OSGi, maybe he can comment on it. Not much to report in this ContextIoC [1] area. I have been busy porting Merlin/Metro to a OSGi bundle, where the Merlin/Metro services are seen by other bundles, and the Merlin/Metro services can use the OSGi services. And some stuff around all to make this work. All needed as migration path for the project I am involved. Other than that, most important observation in the OSGi adventure is probably that bundles becomes just nice size (or maybe it is just my preference). Not too large that 100s of classes needs to interact with each other with heaps of GoF patterns required to hold everything together, and essentially I don't feel I need any component framework at all. A dozen or two classes is typical bundle size for me, and all bundles that provides a service generates two Jars, one with the API and one for the impl, so the API can be placed in dependent bundles, as originally intended. That allows me to fabricate the needed components or their factories in the Activator, pass it down the line with constructor injection, and pretty set to go. I.e. I am on the same page as Pier when it comes to I don't like complex solutions, and to me Spring is complex, Pico is complex, yes Merlin/Metro is complex. One gets sucked in slowly into these platforms, but end up fighting different kind of battles (XML hell) instead of coding Java. Anyway... With the Feature feature in OSGi R4, where sets of bundles are treated as mega-bundles, I think my small bundle approach makes very good sense, and a component-like organization is emerging. I still think that OSGi needs better implementations of many presecribed services, i.e Config, Prefs, Meta, User, Permission and so on services. I was hoping that Felix would become the place where those implementations flourished and could be shared across half a dozen projects at ASF alone. As for Cocoon to use OSGi, I am not familiar enough with the inner workings of Cocoon of today to have any clue of how hard that would be to remain compatible with previous versions. I guess that 100% compatibility is impossible, by the fact that there are no well-defined contracts, and any user could be using any internal bits that it happens to reach one way or the other. I hope the Cocooners can work all of this out, as the motivation for me to use Cocoon diminishes by the days, as it gets easier and easier to do stuff in competing platforms that only made sense in Cocoon previously. Cheers Niclas [1] http://www.theserverside.com/articles/article.tss?l=IOCandEJB
Re: FW: Malformed stream: Read timed out
On Wednesday 12 October 2005 22:18, Steven Noels wrote: I have very mysterious error while using forms with @enctype=multipart/form-data. _Some times_ while submiting the form I get org.apache.cocoon.servlet.multipart.MultipartException: Malformed stream: Read timed out error and have no idea what is the cause. I am sure that there can be several answer to this, let me run one very obscure that I came across last week. but only if size of form data being submited to a server is big enough (about 2000b). I sit on a PPP link for my broadband, and that link has a maximum packet size of 1400 something bytes, and not the typical 1500 bytes. I have noticed an increasing number of websites that I can no longer reach. And the problem is not even mine, it is described in Debian documentation with a note about criminally braindead network administrators. This is what happens; 1. The server sends the response to me. 2. Each packet (1500 bytes) is marked Do not fragment, which is becoming increasingly common. 3. When the packet comes to the router near me, it sees Ah. Too big. Ah. Don't fragment. so it sends back an ICMP packet saying Too big. 4. Some last-mile ISP or IT department has decided to block ICMP traffic. 5. The server never sees the Too Big message, and thinks the packet was lost. It retries. 6. A timeout happens sooner or later. And of course, pages that are small enough to fit into the 1400bytes packet, comes through without problems. In the cases where we control the server, we have two solutions for this; 1. Disable the PMTU detection, by setting 1 in the file below; echo 1 /proc/sys/net/ipv4/ip_no_pmtu_disc 2. Make the max MTU size smaller by modifying the ethernet interface. On Debian that is /etc/network/interfaces and adding MTU 1400 under the iface of the relevant interface, normally eth0. I think the above is so obscure that it may catch many software developers by surprise, since they are normally the one to blame, and we couldn't have a clue... I hope you can manage to rule this in or out, for your particular case. Cheers Niclas
Re: Roadmap for Cocoon Blocks
On Thursday 13 October 2005 01:19, Torsten Curdt wrote: I hope the Cocooners can work all of this out, as the motivation for me to use Cocoon diminishes by the days, as it gets easier and easier to do stuff in competing platforms that only made sense in Cocoon previously. ...like? Just curious... I hope I am not getting in to trouble for trying out other stuff ;o) A few weeks ago we started on a new internal back-burner project, and needed some forms, user auhorization, multiple LF depending on user, and PDF reports from JDO-backed database. A few months ago, I would not even think before throwing Cocoon at the problem. Due to need to learn Wicket for another external upcoming project, we gave it a go. It was scarily simple, and considering their use of plain and pure HTML as templating, typesafety all over the place, 1:1 checks for components in code vs components on page, no XML and easy to programmatically hook JasperReports straight into the reponse stream, I was indeed impressed. And that was from starting from scratch. Does it really scale upwards? How about endless support of UserAgents?? Performance under heavy load? Sorry - I don't know. Just saying the answers are no longer given, even if you know Cocoon pretty well. I am a Java programmer, and it is faster for me to hack up 100 lines of code than it is to get a combo of XML and JavaScripts operational. I love the compiler :o) Now, compare that with Cocoon anno 2001. Far ahead of its time. The orthogonality of concerns were remarkable for its time. The competition was essentially CGI, SSI, JSP and hard coded servlets. Cocoon rose with the external dependencies of Batik, FOP and many others over time, which made Cocoon a unique center-piece in content aggregation. Cheers Niclas
Re: Classloading in blocks [was; Binaries for next releases]
On Sunday 09 October 2005 19:33, Reinhard Poetz wrote: So the answer to your question: We need this classloading only to load classes from within 2.2 blocks. 3.0 will make this 2.2 classloading stuff obsolete (hehe, my favorite word these days). Ok. Cool. Got worried there for a while :o) Thanks Niclas
Re: Re-reading Jar files...
On Friday 07 October 2005 19:36, Vadim Gritsenko wrote: Niclas Hedhman wrote: Hi, We normally don't deal with Jar/zip files, but a case have come up where we need to read XML inside zip files, which are modified at times. The developer added a src=jar:http://our.server.com/cocoon-mountpoint/zips/abc.zip!file-in-que stion.xml using the standard filegenerator. Works... but doesn't reload. If a jar:file:/// URL is given, exceptions are thrown when the file is changed. Somehow I think the URLConnection is cached somewhere, which then dictates that the Jar file can not be modified, but I am unable to figure out 'where' or 'how'. I am not sure if it is the same as the http://issues.apache.org/bugzilla/show_bug.cgi?id=29365 issue. Anyone knows what is happening, and what we can do to overcome this? Try zip: protocol Thanks!!! Worked... Cheers Niclas
Re: SVN Address
On Saturday 08 October 2005 16:01, Geert Josten wrote: I want to add one remark though: following the procedure will consume at least 230Mb in size, but on my 20Gb Fat32 partition it occupied something near 840Mb of space! Any hints to slim this down, in advance preferably? Welcome to the hidden beauty of Svn. Svn has a fairly high overhead per directory, which means Java projects can explode fairly massively. AFAIK, there is nothing you can do about that. This is probably the 230MB you are talking about, the 840MB is rectified with a more modern filesystem. If you are stuck on Windows, NTFS is the only real choice I guess. Cheers Niclas
Re: Cocoon Fat Test
On Friday 07 October 2005 14:15, Carsten Ziegeler wrote: so I think you're trying to put words into my mouth. Maybe you hate him for that ;o) Ok, now let's get back to the technical discussion... Stefano Mazzocchi wrote: But even when size is not an issue, having smaller webapps helps in making users perceive what core functionality the cocoon framework gives them and what is add-on. Indeed. An easy-to-understand fairly simple system with 50 plug-ins looks like a better deal to a newcomer than a big monolith, which is hard to grasp. However, to me fatness in distribution is somewhat moot point nowadays. I have had some concerns over the runtime RAM footprint, but have no conclusive numbers, whether it is a leak problem, or just caching going nuts. Scheduled server restarts doesn't sound like a good solution, but at the moment it is the 'cheapest' thing to do. Cheers Niclas
Re-reading Jar files...
Hi, We normally don't deal with Jar/zip files, but a case have come up where we need to read XML inside zip files, which are modified at times. The developer added a src=jar:http://our.server.com/cocoon-mountpoint/zips/abc.zip!file-in-question.xml; using the standard filegenerator. Works... but doesn't reload. If a jar:file:/// URL is given, exceptions are thrown when the file is changed. Somehow I think the URLConnection is cached somewhere, which then dictates that the Jar file can not be modified, but I am unable to figure out 'where' or 'how'. I am not sure if it is the same as the http://issues.apache.org/bugzilla/show_bug.cgi?id=29365 issue. Anyone knows what is happening, and what we can do to overcome this? Cheers Niclas
Re: [RT] seven good reasons to close down users@cocoon.apache.org
On Tuesday 04 October 2005 15:51, Geert Josten wrote: 1. Rename the list support@ or some similarly positive term. 2. Route all support@ mails to dev@ with a [SUPPORT] subject marker. That keeps users who want to be protected from the RTs, wild dev discussions and so on. +1 to this idea. Though, where should answers go? The Reply-To goes to the support@/user@ list, and since it is forwarded to dev@ a local copy for the developers also is forwarded. Effectively, a crossposting of always from support@ to dev@, but not the other direction. Just a thought, not sure if infrastructure@ would be too happy about it either. Cheers Niclas
Re: Offerta di lavoro
On Tuesday 04 October 2005 21:53, Sylvain Wallez wrote: Wow! A Cocoon job offer for italians only Nah, that would be discrimination nowadays. A job where understanding italian is a pre-requisite, must be the term. Maybe it should have been listed under languages :o) Cheers Niclas
Re: [RT] seven good reasons to close down users@cocoon.apache.org
On Tuesday 04 October 2005 13:19, Bertrand Delacretaz wrote: Thanks for your comments, let's see what others think. I am also against user list. It has a degenerating tone to it, and the fact that many developers are not subscribed to user@ seems to promote that notion further. My suggestion; 1. Rename the list support@ or some similarly positive term. 2. Route all support@ mails to dev@ with a [SUPPORT] subject marker. That keeps users who want to be protected from the RTs, wild dev discussions and so on. Cheers Niclas
Re: [RT] Is Cocoon Obsolete?
On Monday 03 October 2005 04:11, Ross Gardler wrote: One other significant point to the many arguments as to why Cocoon is *not* obsolete is that a rich client requires higher bandwidth. I agree with Antonio that the above statement is not a fact, but a circumstance around the particular application. 1. Behaviour mobility - the application behaviour is moved to the client. How often, how large, and so on. 2. Algorithms - how much data is processed on the server prior to be moved to the client? 3. Data Intensity - Is the application data intense and need a lot of DB read/writes? 4. Many other factors... Whatever the case, the server runtime platform will remain, but less 'typical' (HTML) than in the past. Cheers Niclas
Re: OSGi Bundles, Re: svn commit: r292305
On Saturday 01 October 2005 20:11, Daniel Fagerstrom wrote: I am not sure what you mean by passing parameters into the block. I have an eirie feeling you are refering to management concerns about setting up the service from the outside, and not runtime concerns during the service call. Yes we talk about block deploy time parameters. These should IMO be handled with a OSGi configuration service. But that might be something that we implement later. Ok. Then a I agree with your conclusion. And this area is for me very important for non-Cocoon reasons. If you have any generic thoughts of how to for server apps, I am all ears. Have thought myself to go via a http/html interface, but that seems so hacky and would only do for a in-house solution. Cheers Niclas
Re: OSGi Bundles, Re: svn commit: r292305
On Sunday 02 October 2005 00:40, Daniel Fagerstrom wrote: The metatype service in R4 is schema driven like the Knopflerfish one, don't know if there are any open source implementations yet. Ok. Then I need to take a look at that. For server use it is impractical with interactive parameter modification. Here we could develop a configuration file driven configuration service implementation. That either use a large configuration file that configures everything in the app or a set of configuration snippets, for making configuration less monolithic. This is an area I am struggling with conviction at the moment. OSGi is built on the premise that a platform restart will bring back the last known state, including the Configuration set for a ManagedService. If I dared to make this a reality, the interactive config actually makes sense; 1. The ManagedService exposes its expected configuration in its registration, by publishing the defaults for everything. 2. The Config service manages the persistence. 3. One or many Config Admin services can be created to modify the configuration in runtime, and the Config service will track it correctly. I guess a Export functionality in the Config Admin service would be needed to allow to restore the configuration after a real cold start (removal of OSGi cache directories). I am just not comfortable at the moment to let OSGi start from 'previously known state'... Guess I don't have faith in my own bundles. :o) Cheers Niclas
Re: [RT] Is Cocoon Obsolete?
On Sunday 02 October 2005 09:41, Jaka Jaksic wrote: What I'd like to have is the ability to split sitemaps into several *files* (not subsitemaps!) and bind them together with simple include operations. That way you could split your sitemaps into smaller parts however you wished, and also share common stuff between different sitemaps. Maybe I am naive; Wouldn't that just be a matter of using a XInclude capable XML parser? Xerces supports it, right? Cheers Niclas
Re: OSGi Bundles, Re: svn commit: r292305
On Friday 30 September 2005 04:55, Vadim Gritsenko wrote: Also, I'm not convinced that blocks should be active (i.e. contain activator) at all. Without active participation it is no more than a shared library, and as such it is very difficult to swap out and replace with a new implementation without restarting the entire application. We should probably separate block's code from block's instance. It is especially important if you have an ability to pass parameters into the block. Two Cocoon Applications will not be able to share single instance of a block if its configuration differs - hence, block itself is passive and is instantiated by the application. I have a hard time following this discussion, as block is somewhat undefined in OSGi terms, and _I_ don't feel I understand with it is exactly. Now, that said, I have assumed that a block bundle consists of 0..n block services. In OSGi, it is very straight forward to hand different service instances to different client bundles. It is also possible to register the same service code with many instances, each different in its setup. One could! have a ROLE attribute in the registration that the client use for the lookup. And so on. I am not sure what you mean by passing parameters into the block. I have an eirie feeling you are refering to management concerns about setting up the service from the outside, and not runtime concerns during the service call. Cheers Niclas
Re: [RT] Is Cocoon Obsolete?
On Saturday 01 October 2005 05:57, Stefano Mazzocchi wrote: How do you feel about this? I think you have a few strong points, as do the others. When Cocoon first materialized, its concepts were fairly revolutionary and advanced for its time. IMHO, too much focus on Cocoon has been add this feature (webapp dev, forms, scripting, hundreds of transformers and serializers, et cetera) and not enough on modularization of the design. (Not the mentioning of 'What happened to the RDF promise in Cocoon??') This has slowed the Cocoon evolution down to a point where it has been overtaken by many competing technologies. I don't believe in Cocoon in its current shape at all, and the current OSGi effort is a do-or-die thingy. If successful, it may be possible to revitalize Cocoon into a modern tool in this new brave world of more client-side interactivity, which I am certain is needed. I am not sure Right now FireFox is a step ahead, but IE will catch up. They're not likely to regress anyway. as Leo put it. M$ is a always unpredictable and EEE capable (embrace, extend, extinguish). Not totally unlikely that a similar totally incompatible way will emerge in IE, so I would not bet my company on this at the moment. Strong server-side platforms will continue to be needed, but their shape, scope and nature will most certainly shift. So the question should instead be; Can Cocoon shift into the future? Cheers Niclas
Re: [RT] Smarter Use of Exceptions
On Thursday 29 September 2005 22:51, Berin Loritsch wrote: Before I dive into more detail here, I am not questioning the use of unchecked exceptions. I am challenging the use of _generic_ exceptions. +1, and good call not to get into the checked/unchecked debate. Cheers Niclas
Re: [RT] Flattening trunk
On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote: I think we should move the content of trunk/src/ to trunk/, and start considering them as separate projects (blocks). I would be really happy if a top-level build script (maven, ant, bash, perl, whatever) is maintained for us poor souls who wouldn't know what depends on what, and in which order stuff needs to be built. Doesn't need to support everything, just one sweep to compile/package each part. Also, in the long run, consider getting rid of the ttb structure, drop the heritage from CVS and make a more direct statement; /repos/asf/cocoon/ main/ legacy2.1/ releases/ experiments/ or something along those lines. Cheers Niclas
Re: Shall we switch to Jira?
On Wednesday 14 September 2005 10:32, Antonio Gallardo wrote: Being reading all the thread, I think there is also one important aspect: A lot of the projects used in cocoon as xalan, xerces et al. all of them already migrated to jira. Agree. Infrastructure would also be *really* happy if all projects converged on a single system, as it would reduce the load on them a bit. As for down-times vs we have used Jira for years and it is great; The ASF Jira has more hits than any other known Jira installation, and the Atlassian developers (some are Apache committers) are taking this seriously and doing whatever they can to have it sorted out. Perhaps a check with other Jira using projects would be in order, especially the ones who have migrated. Cheers Niclas
Re: svn line-endings config (Was: svn commit: r279905 - in /cocoon/site/site/link: livesites-2.1.html livesites-2.1.pdf)
On Sunday 11 September 2005 17:20, Jorg Heymans wrote: That is wierd though, I had noticed this and checked my svn config : *.html = svn:eol-style=native and auto-props enabled. I figured something else must have been in play so I didn't think much of it. Maybe my TortoiseSVN messed up, dunno. The auto props only applies to newly generated files, never to files already existing in the repository. Cheers Niclas
Re: cocoon maven repository
On Saturday 10 September 2005 23:33, Jorg Heymans wrote: Stefan Podkowinski wrote: The project will be hosted on sourceforge so I can't really setup my own repository for this. Another option would be to ship dependencies not available on public repos with my distribution. But I want do avoid this if possible to keep download size for updates as small as possible. Actually, i think we have created a small m2 cocoon repository somewhere on the Apache servers. I can't remember exactly where and how, but possibly we could provide an m1 style repository as well. There is a general avoid snapshots policy for ASF repositories, as they will not be guaranteed to be there 'forever' which may cause trouble to users, and a no snapshot policy for the repository that gets replicated to ibiblio.org. If special builds, snapshots and what not can't be avoided, the best practice is probably to ship those explicitly. Cheers Niclas
Re: Real blocks - current state and next steps
On Thursday 08 September 2005 06:47, Daniel Fagerstrom wrote: Maybe we could work within Felix to make it possible to use the OBR functionality on M2 repositories? Not sure if the M2 contains enough info, but otherwise I think it is a good idea. Currently, I have a live publish system, where you scp a bundle to a directory and a cron job extracts the manifest data and convert to xml snippet. A cgi script collates the snippets on requests to the expected format. Although this works, it is one more piece of software to maintain, and it doesn't work for client-side-only since it is an aggregated XML file. Don't expect a Felix Bundle Repository any time soon though... :o) Cheers Niclas
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. The --encoding argument applies to commit messages. Paths, URLs/URIs has additional encoding requirements. Cheers Niclas
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
On Monday 05 September 2005 23:52, Upayavira wrote: In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as o.a.c.transformation.*Generator. This would be enough for us to avoid having to rename packages. However, it would likely lead to some complex wildcard expressions, so I would propose that we ignore that functionality and use unique package names per block, as per R3. There is also the concern of sealed Jars of the JVM that should be taken into consideration. IMHO, separation is a GoodThing and should be carried out instead of hanging on to bad habits. Cheers Niclas
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
On Monday 05 September 2005 09:52, Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Yes, you are (reservation below). And I find it amazing how difficult this topic is to understand for most people, some of them pretty clever. Now, the confusion adds to the matter as the JLS initially specified that java source files had to have ISO-8859-1 (IIRC) encoding, later interoduced the -encoding argument to the compiler, and AFAIU in Java 5 changed the default. Pier seems to suggest that the platform settings also play a role in which encoding the compiler chooses. This I am not aware of. The only proper way is that Cocoon declare an encoding for source files to use, and that this setting is explicitly given in the javac argument, and any deviations are bugs. Cheers Niclas
Re: Using Maven to build Cocoon
On Tuesday 30 August 2005 17:59, Carsten Ziegeler wrote: First you have to install m2 latest from SVN, the alpha-3 does NOT work for us! H You realize that you now forces some people to stop building Cocoon HEAD, due to overly high requirements of getting Maven2 installed. Many people (myself for instance) will not bother to build M2 from sources, and possibly not install it at all until a final release is made. I hope considerations are made that a Maven 2.0 Final is released prior to making any breaking of the current Ant build. Hopefully that will be in a couple of weeks. Worst-case scenario, remember Maven 1. Cheers Niclas
Re: [2.2] Past, present and future of the maven build
On Wednesday 31 August 2005 05:00, Joerg Heinicke wrote: Did I mention that I hate tools needing changes in the subject they should work on to make them work? The above scenario and the other mentioned necessary restructurings were the reason why I ever were against a change of the build system to Maven. As Ralph mentions, this is not a Maven issue. If you break up the codebase (as intended indepently of the Maven migration) you will need this kind of approach. Same thing goes for an Ant-based build system of components. Cheers Niclas
