On Thu, 25 Aug 2005, Vincent Massol wrote:
Hi Vincent,
> Hey, welcome aboard!
Hey, thanks! I totally forgot about sending an introduction mail to
express my thanks for including me in the team! So, thanks! You've al read
my introduction in the voting mail, so I'll leave it at that..
> > I've been looking at the current build system used, and OMG,
>
> OMG?
'oh-my-...' ;)
>
> > it's ant-hell! :)
>
> Come on! It's not that bad :-)
... ;) Nah, it's ok, I'm just not used to it anymore since m2.. ;)
[snip]
> > To the point: I'd like to move some directories around. Is it ok
> > if I create a branch containing the new directory structure + pom.xml
> > files, possibly using symlinks (yes you can version those
> > too nowadays, I believe) to point to the real source directories?
>
> Here's the issue I see with this approach: Cactus developers and users are
> not going to use the Maven2 build system before it is fully functional and
> before it allows to fully build Cactus. This won't happen overnight
> either... :-)
Indeed. That's why I suggested a branch, so I can incrementally 'save' my
work and let you guys check it out, while in the mean time you can
continue working.
> So I think working on branch till the full m2 build is usable is going to be
> hard and I would be more comfortable if we were doing it step by step.
Well, that's what branches are for..
> For example:
>
> Step 1:
> -------
>
> * Refactor the framework/ project into 5 modules (share-12-13-14,
> share-13-14, j2ee-12, j2ee-13 and j2ee-14). BTW if you have a better idea
> for naming and organization I'm all ears!
not yet, but I might come up with one or two suggestions ;)
> * Modify the Ant build so that it can build those 5 new projects
>
> * Check in the Maven2 build for those 5 modules
>
> * Note: We do not want to release those module jars separately. I guess
> we'll need to use the assembly plugin to aggregate them.
Yes, that's going to be hard. Your release scenario will be a little more
complicated..
> Step N:
> -------
>
> Handle the documentation/ subproject by breaking it into the different
> existing modules (framework doc, integration/ant doc, etc). Top level
> documentation would stay in the top level directory.
Ok, exactly my idea.
> WDYT? It's a bit more work provided that we want to drop support for Ant but
> I think it's going to be too hard to merge a long-running branch. You'd need
> to merge all the changes done on the main trunk.
Well, not necessarily. As far as i can see now I only need your
source/resource directories. I won't be editing them. I won't copy the
ant build scripts and config, but instead create maven2 files.
I could create symlinks to the original source directories (stored in
svn, or in maven2 in the initialization phase, for now), so all
that's in the branch is some pom.xml files, some empty dirs and some
symlinks (won't work on windows though..)
This was my idea of not getting in your way, preparing stuff until it all
worked and then merge+switch to trunk.
> > Btw, if a new directory structure is made, the ant build system will
> > need modification ofcourse, if we want to support the two side by side
> > (but only after the branch with the new system has made it into trunk!)
>
> I think we have a slightly different POV but I'm all ears... Let me know
> what you prefer.
Summary:
Working in trunk:
------------------
Pro: staying up to date, no merge issues
Con: it'll probably break some builds as I'm not too familiar with the
codebase yet and it might not run tests or something..
Con: I'll probably make it harder for the people who have outstanding
commits, and for myself, when I move directories around. Depends on
the work-commit rate/interval.
Con: (for me) initially more work because i'd have to update the
ant buildsystem first
Pro: while updating the ant build system I learn how it works and know
what needs to be done in m2.
Working in a branch:
--------------------
the opposite of the above.. :)
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
