That was my guess.
Do you know if there is a JIRA to clean that up?
--jason
On Jul 3, 2006, at 12:39 PM, David Jencks wrote:
I think this might be an m1/m2 artifact. I believe the m1 build
uses the stuff in magicGball/src whereas the m2 build uses the
subdirectories and ignores the stuff
I think this might be an m1/m2 artifact. I believe the m1 build uses
the stuff in magicGball/src whereas the m2 build uses the
subdirectories and ignores the stuff used by m1.
Yet another reason to ditch m1 as soon as possible.
thanks
david jencks
On Jul 3, 2006, at 12:34 PM, Jason Dillon
Just have a peek at:
http://svn.apache.org/repos/asf/geronimo/trunk/applications/
magicGball/src/
and then peek at the modules, like:
http://svn.apache.org/repos/asf/geronimo/trunk/applications/
magicGball/magicGball-ejb/src/
NOTE: the pom.xml for applications/magicGball is pom packaging,
On 7/2/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Anyone know where there are duplicate srcs under magicGball?
Looks like this is to support m1 and m2 builds.
I don't understand what you're asking for. How do you know they exist
at all? An answer for the question might help me a bit understan
Anyone know where there are duplicate srcs under magicGball?
Looks like this is to support m1 and m2 builds.
I hope this is not the only reason. If it is, then I gotta say this
is one of the harmful things to a slow incremental overlapping m1 and
m2 build system. I still think that we shou
