On Fri, 04 Sep 2015 18:19:42 +0200, Luc Maisonobe wrote:
Hi Gilles,
Le 04/09/2015 17:30, Gilles a écrit :
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?
No, hence there should not be source files that do not belong to the
top level package in the source folder.
The fact is maven is used in many different situations, not only in
Apache Commons. In order to streamline everything, the maven project
has decided to stick with "conventions over configuration", which
means one should really obey the conventions. This explains why it
is so difficult to do otherwise. If you attempt to not follow the
maven imposed conventions, you are going to suffer a lot fighting
agains maven ... and at the end maven wins as you throw in the towel.
So the convention imposed by maven is really to compile everything
under src/main/language-name and src/test/language-name. It does not
care about the top-level package and I don't even think it has a
notion of top-level package (though many plugins may be aware of
packages names).
But it can told to compile only specific files (cf. Ole's suggestion).
What I don't get is why you need these files to be precisely at
this place while not compiling them. If you don't want to compile
them and typically use them only as reference couldn't these files
be only a few folders away? Then, you could have two development
trees, one for math3 and one for math4, always available together
but not mixed in a single folder. As even the pom file is above
src/, with separate folders you could even have both pom files
available if you need to do some comparisons or parallel compilations
and tests runs.
Well, I started to use git branching which suggests that one should
download the various branches onto the same repository and switch
between
them.
Then I happened to want to create a few files (for testing a potential
new feature before proposing it for inclusion). [And I do want to have
them compiled; just not within the "wrong" project!]
I'm not so happy having to repeatedly "stash" just to be able to switch
to
the other branch for almost trivial copy/paste (of backported code).
It
looked more interesting to delay the "git add"...
So it seems that the alternatives are:
1. Have separate repositories for each branch
2. Modify the POM
3. "git add" new source files and stash, stash, stash
From the discussion here, none seems particularly appealing.
Best,
Gilles
best regards,
Luc
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
