Hi Daryl,
Thank you for sharing this information with us. I really appreciate
that. I will comment as soon as I can. Anyway, I am very happy with
what I have read.
Cheers,
Henrique
On Fri, Jun 13, 2008 at 10:31 AM, Daryl Lee <dle..pple.com> wrote:
> Hi Henrique,
>
> On Jun 12, 2008, at 4:35 PM, Henrique Prange wrote:
>
>> Hi Daryl,
>>
>> On Thu, Jun 12, 2008 at 6:28 PM, Daryl Lee <dle..pple.com> wrote:
>>>>
>>>> 1) Why a new maven-apple-plugin? What is wrong with
>>>> maven-wolifecycle-plugin?
>>>
>>> - add new wizards/templates for creating a suggested WO Maven project
>>> - add some UI guidance to to the relevant properties that will need to be
>>> configured for the Apple provided nightly builds
>>> - present a warning that these are currently NIGHTLY builds and are under
>>> the ADC usage terms
>>
>> It is very cool. But my concern is about the Maven plug-in, not the
>> Eclipse plug-in.
>>
>>> - add some plugins (mojos) that will work well with our suggested file
>>> system layout
>>
>> As far as I know, the suggested file system layout is similar to this
>> one [1] (I can't affirm it is equal). There is a plug-in called
>> maven-wolifecycle-plugin [2] that works well with this file system. It
>> already creates WOAs (as tar.gz) and WOFs (as jars). So, the question
>> is: Why not use/improve this plug-in instead of creating a new one?
>
> When I first looked at the WOLips Maven plugins a year ago, it was unclear
> what kind of state they were in and how extensively they were being used.
> Especially since the doc wasn't complete at the time. Honestly, when I
> tried out the WOLips Maven examples at the time, I couldn't get them working
> (I was more of a newbie to Maven at the time). When I looked at the code
> there were also things going on with classpath/dependency manipulation (I
> think it was the bootstrapper plugin?) that I wasn't interested in. Some of
> the stuff didn't seem necessary if WO was distributed as a regular Maven
> repository. Feel free to correct me if I'm wrong on this.
>
> Short answer, I didn't want to break anyone using WOLips maven plugins
> because felt like I would strip out a bunch of stuff for my own purposes. I
> looked at the Maven plugin API and decided it wouldn't be too hard to build
> a plugin for the team.
>
> That said, I'm not against taking another look at the wolifecycle plugins
> again.
>
>> Is
>> it so badly coded?
>
> No, I think the code is fine.
>
>> Is the purpose of this maven-apple-plugin to create
>> a different approach to solve the same problem?
>
> Slightly different approach but same result. For Apple's internal purposes,
> we wanted leverage standard Maven community provided plugins as possible.
> Thus the decision to use the assembly plugin to configure the split
> deployment install instead of expressing this in custom plugin code. It's a
> question of brevity vs flexibilty. I do agree that ticking on a simple
> property in the pom configuration is compelling which it sounds like the
> current wolifecycle plugin supports. But I also think that the Maven
> Assembly plugin guys are probably more actively enhancing it and that it
> wasn't hard to figure out how to customize it to do what I wanted. All I
> had to do was drop that deploy.xml file in the assembly directory and
> everything just works. I think a similar approach should be taken for war
> bundling.
>
>
>>
>>
>>>
>>>>
>>>>
>>>> 2) Why so much configuration in the pom (assembly-plugin and etc.)?
>>>> Again, what is wrong with the way maven-wolifecycle-plugin package
>>>> projects? (The final packages generated with both are similar, but
>>>> with maven-wolifecycle-plugin you have to configure only a few lines
>>>> in your pom)
>>>
>>> I wanted to give Maven newbies a window into possible extensions in the
>>> pom
>>> and how easy it is to integrate new features into your build processes.
>>> I
>>> used the assembly plugin in order to give people an idea about how to
>>> create
>>> split installs using standard maven components. The deploy.xml is
>>> relatively transparent in what it's doing. I threw in other things such
>>> as
>>> javadoc generation, unit test reporting, etc. I could have made it a
>>> bare
>>> bones pom.xml but this was more about guidance.
>>
>> Maybe I'm wrong, but when I start using a new tool, I prefer to begin
>> with basic stuff and add complex things after. In the beginning, less
>> is more. On the other hand, after I have learned and configured my
>> environment, I want to use things that are the least intrusive. In my
>> case, I will have to remove a lot of things using this template. I
>> prefer to use woapplication-plugin [1] with the m2eclipse wizards (I
>> have to write this tutorial*). It is simple and creates projects
>> supporting Wonder (if I want) and deployment as true WAR (if I want)
>> with few clicks.
>>
>>
>> I'm not saying the idea of a special wizard to create WO applications
>> is bad. I really liked it. I didn't like the template.
>>
>> So, IMHO, these generated resources are too much for beginners and
>> useless for skilled developers. I think we could provide this guidance
>> by other means.
>
> My thinking was slightly different on this. For years I dealt with
> complaints of people who had Xcode projects and had no clue how to turn on
> or access expected workflow features in the build system. (yeah, I can hear
> the Xcode-Java-WO-build-system-sucks comments coming....) I just think the
> template should shortcircuit a lot of these questions out of the box. Why
> not create a split install, war bundle, etc out of the box and let people
> discover how to turn off the features. Usually they only have to remove a
> couple of lines in their pom. Advanced users know what to do and it'll take
> them a couple seconds to strip this stuff out.
>
> I'm not against creating more options in the current template wizard to just
> create a bare bones project.
>
>>
>> *Should I write this tutorial?
>
> Go ahead. See my comments later.
>
>>
>>
>>>
>>>> 3) I know you will not answer that, but is Apple planning to make a
>>>> proprietary version of Maven plug-in?
>>>
>>> I don't think we are going to create a commercial plugin if that's what
>>> you're getting at.
>>
>> No. I just want to know if I will have access to source code.
>> WebObjects is free, but I don't have access to source code. WOLips is
>> free and I have access to source code. That is my doubt.
>>
>>>
>>>> I understand the lack of transparency of Apple about internal
>>>> business. I just want to know if I should continue developing things
>>>> for Maven in WOLips (and writing tutorials) or if it will be waste of
>>>> my time.
>>>
>>> The nightly builds will be released in Maven repository form. I don't
>>> see
>>> any other simple mechanism to easily deliver this. Maven does this so
>>> cleanly.
>>>
>>
>> Sure. I really like it. I use Maven to manage all my projects. I'm
>> really happy with this. I want to know if I should finish the tests on
>> maven-wolifecycle-plugin and release this new version (2.0.15) or am I
>> wasting time?
>
> It's not a waste of time. The wolifecycle plugin has it's place. It looks
> like the plugin can reduce the amount of configuration xml you might have to
> write.
>
>>
>>
>> [1]
>> http://wiki.objectstyle.org/confluence/display/WOL/woapplication-archetype
>> [2]
>> http://wiki.objectstyle.org/confluence/display/WOL/maven-wolifecycle-plugin
>
> Good stuff. I don't think any of this doc was there that last time I looked
> at the maven plugins.
>
>>>
>
>
This archive was generated by hypermail 2.0.0 : Fri Jun 13 2008 - 10:07:56 EDT