On Fri, 4 Sep 2015 18:30:45 +0100, sebb wrote:
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 don't think I implied that the tool(s) should be changed, just
that they might be configured such that they would not try to
compile "spurious" files.
That *is* possible, as per Ole's suggestion.
Are there any drawbacks to enforce that policy (at least for CM where
there are no legitimate files above the projects top-level directory)?
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.
I don't understand.
My problem is precisely that those files cannot be compiled, because
their dependencies have been hidden away by "git" (files that belong
to the "math3" branch "disappear" when switching to the "math4"
branch). New files, not yet managed by "git", stay there (and cannot
be compiled).
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org