commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Compile only top-level package and below
Date Fri, 04 Sep 2015 23:31:10 GMT
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 <>
>>> wrote:
>>>> Hi.
>>>> On Fri, 4 Sep 2015 15:30:57 +0100, sebb wrote:
>>>>> On 4 September 2015 at 14:08, Gilles 
>>>>> <>
>>>>> 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 
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 
the other branch for  almost trivial copy/paste (of backported code).  
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 regards,
> Luc
>> [...]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message