Revision number of build
A couple of questions. Is there currently any way to get the svn revision number of a given fop or commons jar? This presumes that a given jar has been built from a single revision, of course. Tags seem to work differently in svn. It seem possible to create a tag/branch from components of many revisions and branches. Committing that tag creates a new revision that includes the tag, AFAICT. If that is the case, how do I tell that a particular build occurred against a given tag or branch, as opposed to the trunk? There seems to be no compact way, given a working directory set, whether that set is a reflection of a single revision. status -v appears to give me current revision number and last change revision number of every file. Is there a 'give me the revision number of this tree, if it is consistent' command? Peter
Re: Release coordination in XML Graphics (was: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
On Wed, 2006-04-12 at 14:07 +0200, Jeremias Maerki wrote: On 12.04.2006 13:55:44 Peter West wrote: snip/ Is there other than accidental co-ordination between commons, batik and fop? Accidental? ATM, no coordination is required for releasing Commons as Batik doesn't use it, yet. The plan for XML Graphics Commons on the Wiki is still valid and provides the base for work on Commons. FOP 0.92 will still use Batik 1.6 as we can redistribute only released JAR files. No snapshot JARs as in the past. Coordination as necessary between subprojects in XML Graphics happens on [EMAIL PROTECTED] What guidance will there be for users in co-ordinating versions of the three? I don't understand the question, sorry. I had drawn the conclusion, falsely it appears, that co-ordination of the three elements was in the offing. Hence the discussion of the stability of trunk code in fop, batik and commons. I don't see how you plan to work the extraction without such co-ordination. It is an aim that the batik guys be able to commit to the transcoders. That impacts on fop. There is a question on the wiki about builds. Individual builds or one über-build? Buzzing around at the back of that question is the larger one of co-ordinating the trees. The wiki mentions that the transcoders can be used in the batik context (and others) independently of fop. However, don't the transcoders get involved in the round-trip when embedded svg elements are rendered by fop to pdf or ps? I don't know, but if so, there's a nice chain of dependency from fop - batik - fop', where fop may not currently equal fop'. The current split of fop and commons has nothing to do with batik, it seems. I was working on the assumption that the creation of commons implied the three-way compatibility of trunk elements. ...a Batik release didn't involve a FOP release until now which is something that must change. At some time in the future. I'm working on a project that uses 0.20.5, batik 1.6 and, now, the fop and batik trunk code. It looks as though I may have to unwind the batik trunk code. It seems to me that the builds of the three trees must at least utilise common build file import elements. Building fop is going to depend upon the availability of particular trunk snapshots of commons and batik. Otherwise, how do you co-ordinate development on the batik and fop and commons trunks? There are users who want release versions only, and there are users who are building from the trunk, including, but not restricted to, the developers. For the latter users, the build process must be able to determine whether the tree of primary focus has access to compatible source trees or jars for the other trees. That seems to imply that each tree maintains a range of compatible versions. Changing fop, say, may then mean updating the build files for commons and batik to reflect the fact that dependencies somewhere have just changed. That, in turn, seems to imply that the build files for all trees are maintained in commons. Peter
Re: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta
Jeremias Maerki wrote: (no replies to fop-dev as usual, vote happens on [EMAIL PROTECTED]) I'd like to start a vote on releasing: Apache XML Graphics Commons 1.0 from the following branch: https://svn.apache.org/repos/asf/xmlgraphics/commons/branches/commons-1_0 and Apache FOP 0.92beta from the following branch: https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_92 Commons: The code is stable and does its job for Apache FOP. I cannot tell for Batik, yet, but that shoudn't be an issue right now as Batik doesn't use the code, yet. In order to release FOP we need to release Commons. There are no known IP problems with the code in Commons AFAICT. The build is properly set up including a distribution build. What's left to be done is some last-minute testing and optionally improving the website a little. I've set up a first version for a release checklist: http://wiki.apache.org/xmlgraphics/Commons/ReleaseChecklist FOP: It's high time we do this. The code is stable and the known issues are well documented. It's the first release that uses Commons and it has the finalized API. From my POV, the latter is the only reason for the beta tag. I think we need to make sure with another feedback cycle that our decisions there were good. Otherwise, I consider FOP production-worthy for PDF and PS output and for most use cases. IMO, the next release after 0.92beta should be a 1.0 but that's a discussion for later. AFAICT there are no known IP problems. All non-ALv2-licensed files are properly tagged. We've been very strict following the CLA rules. What's left is the usual batch of last-minute changes for the documentation plus replacing the xmlgraphics-commons-snapshot.jar with the released version as soon as it's done. That also means that Commons needs to be released first. Release checklist: http://xmlgraphics.apache.org/fop/dev/release.html Jeremias Maerki Is there other than accidental co-ordination between commons, batik and fop? What guidance will there be for users in co-ordinating versions of the three? Peter
Re: Building fop and batik
Jeremias Maerki wrote: The latest revision of FOP Trunk right before my next commit which will add Commons is 390222 (or date: everything before today). Thanks. Peter
Building fop and batik
I noticed some recent commits that mentioned an xmlgraphics commons module. What's the state of play with this? My basic question is, what fop and batik trunk versions give a stable and compatible build base? Is there a new subversion module? If so, will I need to add the commons module to satisfy my main requirement, or can it be done from before the split? Thanks Peter
Re: Building fop and batik
Jeremias Maerki wrote: On 04.04.2006 15:50:09 Peter West wrote: I noticed some recent commits that mentioned an xmlgraphics commons module. What's the state of play with this? Finally picking up speed. I got serious about migrating components from Batik and FOP over to the new subproject. It is work in progress but from now on always in a usable state. The build is working and I've just set up a Gump descriptor for Commons. The plan is still the same as before: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents My basic question is, what fop and batik trunk versions give a stable and compatible build base? All FOP, Batik and Commons Trunks are pretty stable right now. Is there a new subversion module? Yes: http://svn.apache.org/repos/asf/xmlgraphics/commons/trunk If so, will I need to add the commons module to satisfy my main requirement, The Commons module is not yet a prerequisite to build FOP but will be in a few minutes. But there will be a xmlgraphics-commons.jar in FOP's lib directory. OTOH, you will want to look at the sources of Commons because that's where the stuff interesting for your Folio will eventually end up. or can it be done from before the split? SVN can give you any revision/state from the past. Jeremias, What's a date or numbers from before the split that has equivalent functionality? I'm updating against an existing FOP/Batik installation and I want to minimise the initial disturbance, but I may just go with the new scheme. Peter
