From: Greg P. <gre...@gm...> - 2011-02-02 23:13:29
|
Zend framework proved trivial to integrate since they are maven 'aware' anyway. PEAR is another matter. After being initially confused by the fact that there is a maven pear packaging plugin I eventually realised that someone else has ever so helpfully reused the acronym (Processing Engine ARchive) for their completely unrelated software. So my current thoughts are we have three options, and I can see good and bad things about all three: 1. Have a base level POM to wrap PEAR dependencies not kept in trunk, but built into a Maven artefact. This means checking in PEAR code to svn (even though not on trunk), but that VuFind developers (a basic install uses deployed code, not Maven) don't need to run PEAR installations, and the final deployed ZIP for end users will also have these bundled up in the appropriate spot. This is the simplest and most efficient solution, but I'm not a huge fan of subverting the otherwise perfectly acceptable PEAR install process. 2. Write a Maven plugin to recognise PEAR channels... or perhaps grab things from PEAR channels and bundle them as Maven dependencies. The most elegant solution, the most technically interesting to me, and probably the most useful to a wider community... but not fun and it has the potential to be a nightmare to maintain and support. 3. Ignore Maven and use Phing (which recognises PEAR channels). My reading suggests that this is more complicated to setup and use, and you will have to supplement it with additional software to make up for the drop in functionality from Maven... but it solves the PEAR issue. For what its worth I'm leaning towards option 1. If you take 'computer sciency' questions of the 'right' way to do things out of the picture it's the most practical. Otherwise I'd go option 3 and bring multiple tools together to make a more complicated, but 'correct' solution. Ta, Greg On 29 January 2011 00:36, Demian Katz <dem...@vi...> wrote: > Thanks for the update, Greg! > > > > As we discussed on the call, I agree that we shouldn’t be pressuring anyone > to work too hard on test-building for the current specific VuFind code… but > it is definitely worth investing time to continue gaining transferable > general knowledge on tools for testing PHP web apps in general, since we > will probably need that no matter how things evolve in the future. As for > my own ongoing code cleanup, it’s a low priority, but it’s a great way to > kill ten or fifteen minutes that would otherwise be wasted, not to mention > being a good excuse to review all of the existing code! > > > > I’m glad to hear that the initial Maven experiments are going well. Have > you looked into existing PHP/Maven support in the wild yet? For example, is > there an established public repository to handle dependencies on things like > the Zend framework or the PEAR libraries? > > > > For my part, I have just ordered a Zend book (yes, I still prefer paper for > learning new things). I figure that the most important first step is to get > a good understanding of how the framework behaves so that I can identify how > it might (or might not) address our needs. I also plan to do some reading > about Ruby on Rails since it’s such a popular PHP alternative – I have no > intention of switching languages (Ruby enthusiasts already have Blacklight, > so it’s silly to compete in that arena), but there may be design concepts > there that we can use to inform our work. With any luck, by our next call, > we’ll have quite a bit more to discuss! > > > > - Demian > > > > *From:* Greg Pendlebury [mailto:gre...@gm...] > *Sent:* Thursday, January 27, 2011 5:54 PM > *To:* Demian Katz > *Cc:* vuf...@li... > *Subject:* Re: [VuFind-Tech] Developers Call Minutes - 1/25/11 > > > > Hey All, > > "Greg expressed some mild concerns about spending too much time on test > development in light of forthcoming infrastructure changes but will > elaborate in an email to the mailing list." > > Yes, the point I was quite rambled in trying to make (sorry it was past 1am > here) was just that I didn't want any developers to feel pushed into > devoting a lot of time to this stuff . Just keep it light and investigatory > until we have some concrete decisions about any architectural changes we > want to make. The stuff that was being discussed like Selenium and > responding to Sonar identified code issues is pretty much in that category, > hence the 'mild' concern only. Probably wasn't even worth mentioning :) > > "Greg will start putting together proof-of-concept POMs." > > Last night I got two php maven projects up and running, one being a backend > library and the other being a frontend web app calling on the library > project as a dependency through maven. It all went pretty smoothly and in > line with how I'm used to seeing maven work for Java, so I'm more confident > that my assumptions will be correct. Tonight I'll try tieing in the Zend > framework and begin the skeleton of a real application. Demian's suggestion > in the meeting was that we would focus on a basic application framework to > support just searching initially and build out from there. > > At the point were we can search its probably worth sharing with others... > unless people are interested in the 'unformed' building blocks? > > Ta, > Greg > > > > On 26 January 2011 03:09, Demian Katz <dem...@vi...> wrote: > > The minutes from today’s developers call are available here: > > > > http://vufind.org/wiki/minutes_20110125 > > > > IMPORTANT: Note that the next developers call has been postponed from 2/8 > to 2/15 due to a schedule conflict with the code4lib conference. > > > > - Demian > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > > |