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 - 09:32:18 EDT