On 06/02/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Hi All,
Kenney hi,
First: Peter: great work!
Let me first state that I did *not* look at Peter's work yet - I'm
unfortunately too busy
atm.
Nevertheless, since I've worked on maven2 integration/conversion, I wanted
to bring up
some points that maybe not everybody is aware of. Do with this information
what you
want but I thought I should just bring this up for completeness.
I already converted cactus to maven2 about 15 months ago. See [1].
I must admit that I was aware with the branch on [1] when I started my work
but I think it didn't work.
Maybe I had made a mistake somewhere at the time... I don't know...
This was done with symlinks, as discussed as a possible option at the time,
to keep
the branch synchronized with the trunk without having to merge.
To fully apply that branch to trunk would require some moving of
directories/source folders
in trunk.
Yes I agree. When I started to work the first thing that impressed me most
was the complexity of
the ant build at that state. Although I tried to make as less modifications
on the source tree structure
as possible I couldn't do it with no moving of folders and files at all.
Build-wise it looks like I took a slightly different approach, using
profiles for
the various J2EE versions - nothing like uberjar. Also I had to move some
directories,
but it looks like Peter tried to keep the original structure intact (re.
the problem
with maven only supporting one source tree per project - but again, I
didn't look).
In fact I considered a few different approaches at first. One of the ugliest
was to use the maven ant plugin
so that to copy the sources that were needed by more than one source. After
discussing this approach with
Felipe we agreed that there should be no ant files in the build. I then
started making the
build with uberjars. When I got it working I had to do the integration with
cargo. In the cactus's samples
moduleI had to start and stop different kinds of containers. This was
acheived with profiles. At that
point I also got the idea of making the whole build with profiles, but I
gave up because this would have
made the build very complicated. We would have one profile for the container
against which you want to test (for
instance -P tomcat5x) and another one for the j2ee version you want to build
for( for instance -P j2ee14).
Also, about the maven2 plugin: I haven't looked at the code, but I'm the
original author
of the maven-antrun-plugin and the maven-ant project, which is meant to
easily integrate
ant tasks in maven 2 plugins. I used this approach to create the
maven-xdoclet-plugin,
by internally registering and creating the xdoclet ant tasks. The
<configuration>
tag would be filled with typical ant tasks for the xdoclet stuff.
I intended to take the same approach with the cactus plugin, which would
be the easiest
and simplest way to implement a maven2 plugin.
I don't know what the status is with the maven-cactus-plugin or wheter
your approach
is similar, but I just wanted to get you this info.
As a matter of fact I started the plugin like you did the
maven-antrun-plugin. In the mojo's execute
method I constructed the corresponding Ant task, and then used to call
execute on it. Although at that
point I didn't know about the AntProjectPopulator, which as I see isn't
released still. Anyway I did the plugin
that way, but considered it to be not a plugin, but a hack on an already
existent ant tasks. So I started making
the mojos "from scratch". The current state of the plugin is this: All of
the ant tasks have their corresponding
maven mojos, except for the CactusTask. I find it very difficult to extend
the maven's SurefirePlugin, because after
extending it - it seems that the variables that are instantiated with
annotations in the superclass(the SurefirePlugin)
never get initialized. I posted this on the maven list, where I was told
that that it is a known issue. So without being
able to extend the SurefirePlugin properly, I currently have two options:
rewrite the surefire plugin with a call of the
cargo's startServer and stopServer before and after the surefire executes
the tests. Or using the maven's antrun plugin
try to instantiate the CactusTask, initialize it, and then execute() it. I
am currently researching for other opportunities.
Hope any of this is useful.
Thanks,
Kenney
[1]
https://svn.apache.org/repos/asf/jakarta/cactus/branches/CACTUS_TRUNK_MAVEN2_BRANCH
Magnus Grimsell wrote:
> [snip]
>> Magnus hi,
>>
>> I submitted a patch about the cactus-m2 integration in the
>> jira, but it is
>> really outdated.
>>
>> Please consider checking out the latest from the sourceforge
>> repository:
>>
>> svn co
https://mamouth.svn.sourceforge.net/svnroot/mamouth/Cactuscactus-trunk
>>
>
> I checked out the following url:
> https://mamouth.svn.sourceforge.net/svnroot/mamouth/Cactus
>
>
>> I think that the Cargo-0.9-SNAPSHOT dependency is needed - as the
cactus-ant
>>
>> integration is refactored to use some of the cargo classes (like
WebXml.java,
>> EjbRef.java, etc).
>> But I spoke with the cargo guys, and they said that cargo would be
released
>> soon. So I think that
>> this won't be a big problem.
>
> The fact that you refactored Cactus to use Cargo 0.9 was the reason that
I used
> your code base for my patch. I've done some minor changes to Cargo that
I needed.
> So, once again. Great work :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards, Petar!
Karlovo, Bulgaria.
Public PGP Key at:
http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9
