commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yahoo! <HotFusion...@Yahoo.com.INVALID>
Subject Re: [Math] Compile only top-level package and below
Date Sun, 13 Sep 2015 04:50:40 GMT

> On Sep 4, 2015, at 18:55, Gilles <gilles@harfang.homelinux.org> wrote:
> 
>> On Fri, 4 Sep 2015 20:38:36 -0500, Ole Ersoy wrote:
>>> On 09/04/2015 08:14 PM, sebb wrote:
>>>> On 5 September 2015 at 01:13, Gilles <gilles@harfang.homelinux.org>
wrote:
>>>>> On Sat, 5 Sep 2015 00:56:54 +0100, sebb wrote:
>>>>>> On 5 September 2015 at 00:55, Ole Ersoy <ole.ersoy@gmail.com>
wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 09/04/2015 06:06 PM, Gilles wrote:
>>>>>>> 
>>>>>>>> On Fri, 4 Sep 2015 11:03:08 -0500, Ole Ersoy wrote:
>>>>>>>> 
>>>>>>>>> On 09/04/2015 10:26 AM, Gilles wrote:
>>>>>>>>> 
>>>>>>>>>> On Fri, 4 Sep 2015 10:11:04 -0500, Ole Ersoy wrote:
>>>>>>>>>> 
>>>>>>>>>> You have left over files in `target` after switching
between the
>>>>>>>>>> branches.  For example check out `math4`.  Build
it.  Switch to the
>>>>>>>>>> `math3` branch.  Build it.  Now `target` will contain
both classes
>>>>>>>>>> from the math3 branch and the math4 branch.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> No it's not the problem.
>>>>>>>>> They are _source_ files.
>>>>>>>> 
>>>>>>>> Ahh - OK - Not sure if this will help, but you can for example
>>>>>>>> exclude the math3 package files from compilation like this:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> |<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>2.0.2</version><configuration><source>1.6</source><target>1.6</target><includes><include>org/apace/commons/math4/*.java</include>
>>>>>>>> </includes> </configuration> </plugin>
</plugins>|
>>>>>>> That works fine!
>>>>>>> 
>>>>>>> Thus it's not that maven _has_ to compile everything under "src/main";
>>>>>>> it can be told otherwise.
>>>>>>> Perhaps there are nasty side effects to that selection (?).
>>>>>> 
>>>>>> If someone clones the master off of github in order to experiment
and
>>>>>> they
>>>>>> are used to being able to compile everything under `src/main/java`
then
>>>>>> they
>>>>>> may be in for a surprise.
>>>>>> 
>>>>>>> Otherwise, I still don't understand why it cannot be included
in the
>>>>>>> POM file...
>>>>>> 
>>>>>> 
>>>>>> You could create two new branches that you have your own POM
>>>>>> modifications
>>>>>> in:
>>>>>> 
>>>>>> - math3-gilles
>>>>>> - math4-gilles
>>>> 
>>>> IIUC, that would exchange "stash" for "merge".
>>>> I fail to see the gain. :-{
>> These would be 2 temporary branches for your local environment only.
>> Once the changes are made and merged back into the original branches,
>> these can be thrown away.  IIUC you just want a temporary place to do
>> experiments with regressions, etc.  Personally I just like to have a
>> sandbox branch to experiment with changes in case I mess something up
>> ... OK fine when I mess something up :).
> 
> OK, I imagine that this is the right way: systematically create a branch
> even when I thinks that it's not going to be worth it. More often than not,
> it will be worth it in the end... (As in avoiding to disturb our Grand
> Master Maven).
> 
> Thanks for the nudge,
> Gilles

Yes. Git branches are almost cost-free, so  http://nvie.com/posts/a-successful-git-branching-model/
has become a common, if not standard, workflow for Git, and there are tools for making this
workflow easy to follow.  I personally use interactive rebasing in my personal branches almost
every day.  Other tools such as GitUp and Atlassian's SourceTree make useful but more advanced
techniques mentioned in the above article (e.g., composing commits by selecting certain lines
from what has changed relative to the most recent commit) easy.

Al
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message