Hi Harbs,
On a system that you can build with Ant all you should need to do, is to
download Maven in a recent version, unpack is somewhere and add the “bin”
directory to your systems path. I made sure that the one environment variable
the build requires is the same as for Ant.
Regarding the Feature branches: I have thought of adding “Jenkinsfile”s to the
other repos to allow only branching framework if your changes only affect
framework or framework and typedefs, if you want to do some new typedef stuff
(or all three, if you want to do changes in the compiler). Currently you would
need to setup branches in all 3 repos and only the branch in “compiler” would
trigger the job setup. I didn’t bother implementing the others as I noticed no
one had ever used this feature except me. In IntelliJ all I usually do is to
enable synchronized branches. So, whenever I create a new branch, this is done
for all repos and if I do a pull, commit and push this is done synchronously
for all 3 repos. So it’s actually no more work at all.
@yishayw I’m not explicitly referring to this instance … there have been
several occasions where a similar pattern had been pursued and I just wanted to
make everyone aware that It’s not just the build these changes might be
breaking, but also every build that relies on SNAPSHOTs.
Chris
Am 28.03.17, 12:04 schrieb "Harbs" <harbs.li...@gmail.com>:
I do think that development should be done almost exclusively on feature
branches.
If the build status for a feature branch can be verified on the server
(like you set it up) that’s ideal because it does not require using
specifically ant or maven locally.
> On Mar 28, 2017, at 12:59 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> I still have not managed to get maven setup correctly.
>
>> On Mar 28, 2017, at 12:46 PM, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
>>
>> Hi Harbs,
>> (this time replying to the right name ;-) )
>>
>> I usually simply make sure I update my repos and do the full maven build
with tests and examples locally before pushing … I guess this is sufficient
protection against most problems. In IntelliJ that’s two clicks and a cup of
coffee or whatever beverage you prefer.
>>
>> Chris
>>
>>
>> Am 28.03.17, 11:41 schrieb "Harbs" <harbs.li...@gmail.com>:
>>
>> +1.
>>
>> I think it’s OK to develop however we might be comfortable on a
feature branch, but we definitely want an approved procedure which must be done
before committing to the develop branch.
>>
>> Harbs
>>
>>> On Mar 28, 2017, at 12:29 PM, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
>>>
>>> Hi,
>>>
>>> For the last months, we have seen a huge increase in people working on
the FlexJS and people working on first applications using FlexJS. I think we
should discuss how we can make sure we don’t have interruptions like the
current one in the future.
>>>
>>> One point that has been causing pain in the past, was that some people
are using Ant and some are using Maven. Maven is quite a bit more restrictive
than Ant and it builds a lot more and tests a lot more. Just as an example in
contrast to the Ant build the Maven build builds all Examples and it also tests
some of them to be runnable in a browser. The Ant build only builds the
framework and most of the latest problems only pop up if you build an
application. It has occurred several times that Changed failed the Maven build
but didn’t fail the Ant build … just because the Ant build doesn’t build
everything. We could avoid this problem if people would not simply ignore build
failures reported by the ASF Jenkins, which is taking care of the Maven build.
It is currently setup to give feedback within an hour or so.
>>>
>>> Sometimes the “fix” was to exclude a module in Maven. This usually had
the side-effect of the RAT plugin failing after that because it now finds files
without Apache headers. A quick solution to that problem is to log-in to the
ASF Jenkins and to click on “wipe workspace” of that build. After that this
type of problem should go away immediately.
>>>
>>> Another point was that sometimes people work together on a larger
refactoring and check-in stuff to develop in order to share code. We should
start using feature branches for this. This has currently not been happening at
all. I have setup everything that if you create a branch IN ALL 3 REPOS with a
name “feature/{somename}” (but the same “somename” in all three ;-) ) the ASF
Jenkins will setup a Job for that which builds all parts in one go and give you
immediate feedback on the state of your branch. Feature branches that are not
“blue” should not be merged back to develop.
>>>
>>> One last pattern I have encountered was people reporting stuff like: “I
have been working on X and have almost finished ... I know it will break Y, but
I’ll push my changes and fix Y after that” … keep in mind: By breaking Y
everyone working on FlexJS is forced to stop working so I will probably veto
every suggestion I encounter on the list that has a similar pattern.
>>>
>>> FlexJS has matured and we are approaching a 1.0, but we also must
mature the way we develop or we will hurt early adopters and people willing to
help get FlexJS to shape. We want enterprise users to use our stuff, then we
must start working in an enterprise-acceptable way.
>>>
>>> Keep up the awesome work and lets just get a little more awesome ;-)
>>>
>>> Chris
>>>
>>>
>>>
>>
>>
>>
>
