On 4 September 2015 at 16:30, Gilles <gil...@harfang.homelinux.org> wrote: > On Fri, 4 Sep 2015 16:26:16 +0100, sebb wrote: >> >> On 4 September 2015 at 15:42, Gilles <gil...@harfang.homelinux.org> wrote: >>> >>> Hi. >>> >>> >>> On Fri, 4 Sep 2015 15:30:57 +0100, sebb wrote: >>>> >>>> >>>> On 4 September 2015 at 14:08, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>>> >>>>> >>>>> Hello. >>>>> >>>>> There are two branches for Commons Math. >>>>> >>>>> For one, the top-level Java package is >>>>> org.apache.commons.math4 >>>>> For the other, it is >>>>> org.apache.commons.math3 >>>>> >>>>> Unless I'm mistaken, this should imply that maven tries to compile >>>>> only files under either >>>>> src/main/java/org/apache/commons/math4 >>>>> src/test/java/org/apache/commons/math4 >>>>> or >>>>> src/main/java/org/apache/commons/math3 >>>>> src/test/java/org/apache/commons/math3 >>>> >>>> >>>> >>>> No, Maven compiles everything under src/[main|test]/java by default. >>>> >>>> You could change that to >>>> >>>> src/main/java/org/apache/commons/math4 >>>> >>>> but then the compiler would complain about mismatched package names >>>> >>>>> But it happens that I have currently files in "math3" not currently >>>>> checked in into git: those are new files which git does not remove >>>>> when switching branches. >>>> >>>> >>>> >>>> That's the problem - spurious files in the workspace. >>>> >>>>> Then when starting a compilation in "master" (where the top-level >>>>> is "math4"), lots of compilation errors occur. >>>>> >>>>> The "source" top-level directories do not seem to be specified >>>>> in the project's POM. >>>> >>>> >>>> >>>> No, because Maven defaults to the standard directory layout. >>>> >>>>> Can the parent be changed in order to produce the desired behaviour? >>>> >>>> >>>> >>>> Well, you might be able to exclude all files under math3/math4 but it >>>> will be tricky to do and non-standard. >>> >>> >>> >>> But it is standard: source files must belong to the "top-level" package >>> of the project. >> >> >> No, that's not always the case. >> Some components have examples etc that are in a different package >> entirely. >> >>> We don't change the top of the package hierarchy, just filter out the >>> files that do not belong to the project (as per the policy). >> >> >> What policy? > > > Do you that it's OK to have an Apache project publish files that are not > under the project's top-level package?
Yes, if they are example files that are not part of the component. >> Note that although the the Maven coordinates must change when >> top-level package names change there is no requirement for them to use >> the same naming convention. >> In fact they don't - the group id is commons-math3, not math3 >> >>>> >>>>> Or is there a workaround? >>>> >>>> >>>> >>>> Remove the spurious files ... >>> >>> >>> >>> They are not "spurious". >>> They just happen to end with ".java". >> >> >> Yes, they are spurious because they don't belong in the workspace. >> >> It's not just java files that may cause problems. >> Unless the build workspace is "clean", various issues may occur. > > > I just want that maven does not to compile things under a "math3" > when the project is "math4" (and vice-versa). > > That seems pretty reasonable. So should Ant behave the same? And Gradle Etc? I think it would be very confusing if Maven failed to build source files that happened to be in the wrong part of the source tree. > Gilles > > > >>>>> Is there a better way to handle the situation (short of manually >>>>> moving the source files back and forth)? >>>> >>>> >>>> >>>> Why not use two checkouts and switch between them instead of switching >>>> the contents of a single checkout? >>> >>> >>> >>> I might have to resort to that. >>> But it does not look nice (IOW why having branches if not to switch >>> between >>> them?). >>> >>> >>> Thanks, >>> Gilles > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
