As I said:
> Perhaps the default should be zipping the universe, but allowing the user to
> disable one or the other
-Original Message-
From: Pei Chen [mailto:chen...@apache.org]
Sent: Monday, April 10, 2017 5:15 PM
To: dev@ctakes.apache.org
Subject: Re: Revert change to r.1768
I am not being
> defensive or aggressive about my code, I am simply offering a possible next
> step.
>
> Sean
>
> -Original Message-
> From: Pei Chen [mailto:chen...@apache.org]
> Sent: Monday, April 10, 2017 3:51 PM
> To: dev@ctakes.apache.org
> Subje
I am open to opinions on a future course of action. I am not being
defensive or aggressive about my code, I am simply offering a possible next
step.
Sean
-Original Message-
From: Pei Chen [mailto:chen...@apache.org]
Sent: Monday, April 10, 2017 3:51 PM
To: dev@ctakes.apache.org
Subject
Sean can correct me if I'm wrong but as he explained it to me earlier
today, he was thinking that the nightly jenkins build and developers who do
builds on their own systems, both being more frequent than builds for
announced releases, could default to not zipping the source, while the
packageSourc
What is the rational for the code change (r.1768564) of defaulting the
distribution to NOT release source code and distribute only binaries?
It goes the against the fundamentals of a ASF release and the spirit
of the release policy. Just like every other ASF project, the default
has always been to
Fair enough, I was starting to lean towards that same idea myself.
Thanks!
-Original Message-
From: James Masanz [mailto:masanz.ja...@gmail.com]
Sent: Monday, April 10, 2017 12:55 PM
To: dev@ctakes.apache.org
Subject: Re: Revert change to r.1768564
why don't we do that (right) afte
why don't we do that (right) after 4.0 is released. the build process will
be fresh in people's minds and we can set it up and include it in the
cTAKES release manager documentation so it is completely ready for 4.1.
On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean <
sean.fi...@childrens.harvard.edu>
For what it is worth, I don't think that reversion is the best course of
action. As the apache doc that you linked states specifically "for release",
not "for every package build" ... The correct way to handle this is by adding
a releaseProfile.
http://maven.apache.org/maven-release/maven-r
Thanks James. Hopefully soon.
Best,
Murali
On Mon, Apr 10, 2017 at 11:04 AM, James Masanz
wrote:
> Hi Murali,
> I checked into trunk changes that undid what had been done in r1768564.
> Do you think we'll be able to have a release candidate by tomorrow so we
> can give the community time to tes
Hi Murali,
I checked into trunk changes that undid what had been done in r1768564.
Do you think we'll be able to have a release candidate by tomorrow so we
can give the community time to test it and announce the release on the 18th?
Thanks!
-- James
On Mon, Apr 10, 2017 at 10:27 AM, Murali Minna
I'm working on it now
On Mon, Apr 10, 2017 at 10:27 AM, Murali Minnah wrote:
> Hello fellow cTAKERs
>
> Can someone please help revert this change?
>
> r.1768564
> ctakes-distribution/pom.xml
> "Separated build into 2 profiles: packageBinary and packageSource
> packageBinary is enabled by defaul
11 matches
Mail list logo
