> On 2015-May-06, at 12:34 PM, Ramsey Gurley <rgur...@smarthealth.com> wrote: > > Two questions (at the moment). > > In [3] it seems bundles are required. Does using maven preclude using > bundleless builds? That would be a real downer.
In my experience, yes, bundles are required. I have never been successful running with bundle-less builds. If I were to venture a guess, it would be that bundle-less builds depend on the Fluffy Bunny layout, whereas the standard Maven layout is different. > Is it possible to have maven use local changes to Wonder in the workspace? > Like, I find a bug in ERXExtensions, I fix that bug locally, then run my > application dependent on ERXExtensions to test that the bug is indeed fixed > before pushing it to the main wonder repo. Yes, this is possible. I don’t have Wonder in my workspace, but I do have other frameworks in there that are dependencies for other apps in the same workspace. I am able to edit a framework within Eclipse and run an app against those changes without having to deploy to my local maven repo first. I’m not entirely clear on the mechanism, but I believe that the incremental builder is used while in Eclipse and dependencies are resolved from the workspace before the local maven repo (there is a setting in a project’s properties where you can toggle this behavior; I believe it defaults to workspace resolution). F -- Faizel Dakri list...@dakri.com > > On May 6, 2015, at 12:47 AM, Faizel Dakri <list...@dakri.com > <mailto:list...@dakri.com>> wrote: > >> Accidentally hit send too soon… >> >> In defense of Maven, I don’t think you have to be an expert, but you do have >> to be willing to give in to the maven way of doing things and go the whole >> hog (for me, that also meant abandoning Fluffy Bunny and adopting the maven >> layout, something I actually had no problem with). I currently have a >> development environment built on maven that I’m happy with. It took a little >> while to get my head around maven and lots of reading and re-reading the >> wiki and the Wonder POMs (thanks to all that contributed), but it is now a >> relatively predictable environment. I don’t know if what I’m doing is the >> ideal way of doing things, but it does work well for me. There are a couple >> of idiosyncrasies to deal with, but nothing serious. Granted, I haven’t yet >> had to deal with the maven deployment end of things (e.g. incrementing >> version numbers) for a production rollout, but I’m pretty confident that >> I’ll be able to jump that hurdle when the time comes. >> >> What I like: >> >> - quickly adding a new library by adding a dependency to a POM file >> - overriding a Wonder dependency in a local POM file >> - building a true war that I can test with “mvn jetty:run-war” >> - creating a fully contained war file with static resources bundled (via >> a custom assembly) >> >> >> Stumbling blocks I encountered: >> >> - initial setup >> - creating projects using the m2e plugin >> - launching from within Eclipse >> - embedding all resources in the final product >> >> For the initial setup, once I got the right settings.xml [1] and >> archetype-catalog.xml [2] installed in my local repo things ran much more >> smoothly. I also ended up installing Maven 3, although I initially started >> with Maven 2. For the archetype-catalog.xml, I pruned it so that it only had >> the version 2.1 archetypes. After that, I setup a launch configuration >> following the wiki instructions [3]. For my project repo, I ended up with >> the following structure (I follow the Wonder style where my repo contains >> many frameworks and apps): >> >> project_root/ >> pom.xml >> frameworks/ >> pom.xml >> framework1/ >> pom.xml >> framework2/ >> pom.xml >> applications >> pom.xml >> app1/ >> pom.xml >> app2/ >> pom.xml >> >> In this layout, dependencies are declared in the root POM, including version >> info (this allows me to control which versions of which libraries are used), >> along with any properties that are to be pushed to child POMs. All >> lower-level POMs are descendants of the root POM (in a parent-child >> hierarchy). This is directly inspired by the way the Wonder POMs are >> structured. Most of the complexity is in the root POM and in the >> frameworks/pom.xml and applications/pom.xml (through pluginManagement and >> dependencyManagement sections). The individual app and framework POMs are >> pretty simple and are basically just dependency declarations (versions are >> inherited from the root POM by default) plus some workarounds for flattening >> resources, which is one of the idiosyncrasies I was referring to. Using this >> setup, it has become trivial to try out new libraries by declaring the full >> dependency coordinate in the root POM and then just referring to it in the >> specific project that needs it. >> >> I still do my development in Eclipse/WOLips running with direct connect and >> then deploy to Tomcat (running behind Apache) when I’m ready to test by just >> copying over a single war file. Again, this is just in my development >> environment—I haven’t yet attempted a full production install—and there is >> some runtime hackery going on to use the appropriate context class depending >> on whether or not we’re running in a servlet. One of the shortcomings that >> I’ve encountered is that I do have to do some setup for my launch >> configurations to set up the build path when running in Eclipse, but this is >> a one-time thing and is addressed in the wiki [3]. >> >> To package the war file for Tomcat, I use a custom assembly that takes >> static resources and adds them to the war file, but this was pretty trivial >> to create (basically just some xml files, packaged as a maven project), >> however the assembly does make some assumptions about which Wonder >> frameworks have static resources that are to be bundled (more for my >> convenience) and does require me to declare which of my frameworks need to >> have their static resource dependencies bundled. I would like to improve on >> the assembly by expanding the resources before the war file is created, but >> for now it involves manipulating the war file after the fact, which does >> take a non-trivial amount of time. However, it does work and it is extremely >> satisfying to see a single file with all of my classes, dynamic and static >> resources (static resources are served by Tomcat, not Apache). >> >> F >> >> [1] >> https://wiki.wocommunity.org/download/attachments/2623477/settings.xml?version=2&modificationDate=1239236585000&api=v2 >> >> <https://wiki.wocommunity.org/download/attachments/2623477/settings.xml?version=2&modificationDate=1239236585000&api=v2> >> [2] http://maven.wocommunity.org/content/groups/public/archetype-catalog.xml >> <http://maven.wocommunity.org/content/groups/public/archetype-catalog.xml> >> [3] >> https://wiki.wocommunity.org/display/documentation/Maven+Running+or+Debugging+as+WO+Application >> >> <https://wiki.wocommunity.org/display/documentation/Maven+Running+or+Debugging+as+WO+Application> >> >> >> -- >> Faizel Dakri >> list...@dakri.com <mailto:list...@dakri.com> >> >> >> >>> On 2015-May-04, at 11:43 AM, Chuck Hill <ch...@gevityinc.com >>> <mailto:ch...@gevityinc.com>> wrote: >>> >>> I think that “Maven expert” is the key here. This is not a trivial thing >>> to setup correctly and maintain. It is trivial to setup and use >>> incorrectly and I have seen the pain resulting from that. To benefit from >>> Maven you need to really deeply understand Maven and its approach to >>> dependancy management. And you need to ensure that the whole team plays by >>> The Maven Rules, even if it makes more work short term and a bit of >>> cheating does not seem that bad at the moment. >>> >>> Chuck >>> >>> >>> >>> On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote: >>> >>> At my previous workplace, we did the switch to Maven. Luckily we had a >>> real maven expert to drive the move. >>> We started with around 50+ projects, all ant based, using the ‘standard’ >>> fluffy-bunny layout. He added pom.xml here and there, and everything just >>> started working with maven. We had choice to build/run with maven and/or >>> ant and it was (almost) transparent. The only exception was that if you >>> decided to use in maven, you had to change the class path to remove >>> everything but the maven and java dependencies (2 lines left), a simple >>> .classpath that was standard and could be copied from one project to the >>> other. >>> The maven build was then integrated with Jenkins (CI) and SonarQube (so >>> that future ‘JF’ is happy with old ‘JF’, and all the team's work are >>> standardized a bit) with ease. >>> >>> From my experience, the team was happy with the Maven switch, none of us >>> had to become an expert (because we had one already). >>> Maven help a lot on easing the dependency management of your apps (a >>> building block only declare his direct dependency). Once you remove the >>> noise of declaring dependencies, you will be left with a clear graph of >>> dependent block. You will then have to tackle the real problem of >>> incompatible dependencies (A need B and Xv1, but B need Xv2). Maven will >>> make the graph simple and clear, it will try to provide helper but can’t >>> really help much after that. >>> >>> jfv >>> >>> >>>> On May 4, 2015, at 5:09 AM, David Avendasora <webobje...@avendasora.com >>>> <mailto:webobje...@avendasora.com>> wrote: >>>> >>>>> On May 1, 2015, at 6:35 PM, Chuck Hill <ch...@gevityinc.com >>>>> <mailto:ch...@gevityinc.com>> wrote: >>>>> >>>>> Maven seems like a better thought out and implemented solution. >>>> >>>> … >>>> >>>> Have you ever had one of those moments where things just seem so >>>> off-kilter you’re sure you’re having a dream, but no matter how many times >>>> you cry out for mommy you are left sitting there slowly realizing that >>>> there’s been some fundamental shift in the universe that you missed out >>>> on. (And your wife is slowly picking up her phone and dialing your >>>> therapist. Again.) >>>> >>>> ————————————————————————————— >>>> WebObjects - so easy that even Dave Avendasora can do it!™ >>>> ————————————————————————————— >>>> David Avendasora >>>> Senior Software Abuser >>>> Nekesto, Inc. >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com >>> <https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com> >>> >>> This email sent to list...@dakri.com <mailto:list...@dakri.com> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> <https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com> >> >> This email sent to rgur...@smarthealth.com <mailto:rgur...@smarthealth.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
