You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by Murali Minnah <mm...@gmail.com> on 2017/04/10 14:27:44 UTC
Revert change to r.1768564
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 default, packageSource is not"
This changed prevents source code from being distributed using the
default apache release profile when running mvn
release:prepare/perform. In fact, it should be the opposite. At ASF,
binaries are only distributed as a convenience; source code should
always be distributed and binaries should be able to be built from
source. [1]
[1] http://www.apache.org/legal/release-policy.html#source-packages
Thanks,
Murali
Re: Revert change to r.1768564
Posted by James Masanz <ma...@gmail.com>.
I'm working on it now
On Mon, Apr 10, 2017 at 10:27 AM, Murali Minnah <mm...@gmail.com> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the
> default apache release profile when running mvn
> release:prepare/perform. In fact, it should be the opposite. At ASF,
> binaries are only distributed as a convenience; source code should
> always be distributed and binaries should be able to be built from
> source. [1]
>
> [1] http://www.apache.org/legal/release-policy.html#source-packages
>
> Thanks,
> Murali
>
Re: Revert change to r.1768564
Posted by Murali Minnah <mm...@gmail.com>.
Thanks James. Hopefully soon.
Best,
Murali
On Mon, Apr 10, 2017 at 11:04 AM, James Masanz <ma...@gmail.com>
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 test it and announce the release on the
> 18th?
> Thanks!
> -- James
>
>
>
> On Mon, Apr 10, 2017 at 10:27 AM, Murali Minnah <mm...@gmail.com> 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 default, packageSource is not"
> >
> >
> > This changed prevents source code from being distributed using the
> > default apache release profile when running mvn
> > release:prepare/perform. In fact, it should be the opposite. At ASF,
> > binaries are only distributed as a convenience; source code should
> > always be distributed and binaries should be able to be built from
> > source. [1]
> >
> > [1] http://www.apache.org/legal/release-policy.html#source-packages
> >
> > Thanks,
> > Murali
> >
>
Re: Revert change to r.1768564
Posted by James Masanz <ma...@gmail.com>.
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 Minnah <mm...@gmail.com> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the
> default apache release profile when running mvn
> release:prepare/perform. In fact, it should be the opposite. At ASF,
> binaries are only distributed as a convenience; source code should
> always be distributed and binaries should be able to be built from
> source. [1]
>
> [1] http://www.apache.org/legal/release-policy.html#source-packages
>
> Thanks,
> Murali
>
RE: Revert change to r.1768564
Posted by "Finan, Sean" <Se...@childrens.harvard.edu>.
Fair enough, I was starting to lean towards that same idea myself.
Thanks!
-----Original Message-----
From: James Masanz [mailto:masanz.james@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) 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.Finan@childrens.harvard.edu> wrote:
> 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.
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
> aven-2Drelease_maven-2Drelease-2Dplugin_&d=DwIBaQ&c=qS4goWBT7poplM69zy
> _3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTa
> o&m=goOar5URXk8tIVU9Mge1oy_Iv7P0g4T-JX4AJLsA-lM&s=XrCWy_9ZU1Pl2lA5bXka
> hly30h7PqgWHaFeKr9PsO0U&e=
> perform-mojo.html
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
> aven-2Drelease_maven-2Drelease-2Dplugin_&d=DwIBaQ&c=qS4goWBT7poplM69zy
> _3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTa
> o&m=goOar5URXk8tIVU9Mge1oy_Iv7P0g4T-JX4AJLsA-lM&s=XrCWy_9ZU1Pl2lA5bXka
> hly30h7PqgWHaFeKr9PsO0U&e=
> examples/perform-release.html
>
> We may want to move forward, not back. Thoughts?
>
> -----Original Message-----
> From: Murali Minnah [mailto:mminnah@gmail.com]
> Sent: Monday, April 10, 2017 10:28 AM
> To: dev@ctakes.apache.org
> Subject: Revert change to r.1768564
>
> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the
> default apache release profile when running mvn
> release:prepare/perform. In fact, it should be the opposite. At ASF,
> binaries are only distributed as a convenience; source code should
> always be distributed and binaries should be able to be built from
> source. [1]
>
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> apache.org_legal_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=
> qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=
> fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=
> TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBIV4u8VP_
> xJreK4AveCzl8eM0MlxI&e=
>
> Thanks,
> Murali
>
Re: Revert change to r.1768564
Posted by James Masanz <ma...@gmail.com>.
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.Finan@childrens.harvard.edu> wrote:
> 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-release-plugin/
> perform-mojo.html
>
> http://maven.apache.org/maven-release/maven-release-plugin/
> examples/perform-release.html
>
> We may want to move forward, not back. Thoughts?
>
> -----Original Message-----
> From: Murali Minnah [mailto:mminnah@gmail.com]
> Sent: Monday, April 10, 2017 10:28 AM
> To: dev@ctakes.apache.org
> Subject: Revert change to r.1768564
>
> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the default
> apache release profile when running mvn release:prepare/perform. In fact,
> it should be the opposite. At ASF, binaries are only distributed as a
> convenience; source code should always be distributed and binaries should
> be able to be built from source. [1]
>
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> apache.org_legal_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=
> qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=
> fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=
> TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBIV4u8VP_
> xJreK4AveCzl8eM0MlxI&e=
>
> Thanks,
> Murali
>
Re: Revert change to r.1768564
Posted by James Masanz <ma...@gmail.com>.
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
packageSource
profile would be used when it came time to do an announced release.
On Mon, Apr 10, 2017 at 3:50 PM, Pei Chen <ch...@apache.org> wrote:
> 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 distribute source code and convenience binaries
> together (source code being mandatory.) When the ctakes-distribution
> project was created, it's intention was to create the src and bin
> artifacts for distribution just as the name suggests. The spirit of
> NOT distributing source by default is not appropriate for any open
> source project. Sure, there are many ways to work around it, but I do
> not see it as a technical issue.
>
> On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean
> <Se...@childrens.harvard.edu> wrote:
> > 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-release-plugin/
> perform-mojo.html
> >
> > http://maven.apache.org/maven-release/maven-release-plugin/
> examples/perform-release.html
> >
> > We may want to move forward, not back. Thoughts?
> >
> > -----Original Message-----
> > From: Murali Minnah [mailto:mminnah@gmail.com]
> > Sent: Monday, April 10, 2017 10:28 AM
> > To: dev@ctakes.apache.org
> > Subject: Revert change to r.1768564
> >
> > 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 default, packageSource is not"
> >
> >
> > This changed prevents source code from being distributed using the
> default apache release profile when running mvn release:prepare/perform.
> In fact, it should be the opposite. At ASF, binaries are only distributed
> as a convenience; source code should always be distributed and binaries
> should be able to be built from source. [1]
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> apache.org_legal_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=
> qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=
> fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=
> TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBIV4u8VP_
> xJreK4AveCzl8eM0MlxI&e=
> >
> > Thanks,
> > Murali
>
RE: Revert change to r.1768564
Posted by "Finan, Sean" <Se...@childrens.harvard.edu>.
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:chenpei@apache.org]
Sent: Monday, April 10, 2017 5:15 PM
To: dev@ctakes.apache.org
Subject: Re: Revert change to r.1768564
A package without the source code is called a product and that isn't what the ASF does. Having to jump around hoops in order just to include the source while performing a release contradicts what an Open Source project does. If the rational is to save a few secs from zipping source code during package time, why not just create a special profile for binaryOnly which should be an exception rather than the norm for an ASF project?
On Mon, Apr 10, 2017 at 4:03 PM, Finan, Sean <Se...@childrens.harvard.edu> wrote:
>> As the apache doc ... states specifically "for release", not "for every package build"
>
> A package is not a release. The rationale is that people are building binaries of their own sandboxes to hand around the office. They don't want to double the time and build source that they already have. "The spirit" led me to make profiles, allowing more user control over what is going on.
>
> Perhaps the default should be zipping the universe, but allowing the user to disable one or the other (or certain system types). As I said in my previous email, 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:chenpei@apache.org]
> Sent: Monday, April 10, 2017 3:51 PM
> To: dev@ctakes.apache.org
> Subject: Re: Revert change to r.1768564
>
> 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 distribute source code and convenience binaries together (source code being mandatory.) When the ctakes-distribution project was created, it's intention was to create the src and bin artifacts for distribution just as the name suggests. The spirit of NOT distributing source by default is not appropriate for any open source project. Sure, there are many ways to work around it, but I do not see it as a technical issue.
>
> On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean <Se...@childrens.harvard.edu> wrote:
>> 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.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_
>> m
>> aven-2Drelease_maven-2Drelease-2Dplugin_perform-2Dmojo.html&d=DwIFaQ&
>> c
>> =qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYm
>> Q
>> CP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGYbnNTkG8IA&s=
>> V KIk2as8kChuuwI3LkL99t5XzkEjLYHiMkfQJL4gF4c&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_
>> m
>> aven-2Drelease_maven-2Drelease-2Dplugin_examples_perform-2Drelease.ht
>> m
>> l&d=DwIFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZs
>> t
>> TpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGY
>> b nNTkG8IA&s=fqq7gqZOTpzPlv1qGjXqvMmPheqT9M_VVrxMGGUWITg&e=
>>
>> We may want to move forward, not back. Thoughts?
>>
>> -----Original Message-----
>> From: Murali Minnah [mailto:mminnah@gmail.com]
>> Sent: Monday, April 10, 2017 10:28 AM
>> To: dev@ctakes.apache.org
>> Subject: Revert change to r.1768564
>>
>> 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 default, packageSource is not"
>>
>>
>> This changed prevents source code from being distributed using the
>> default apache release profile when running mvn
>> release:prepare/perform. In fact, it should be the opposite. At
>> ASF, binaries are only distributed as a convenience; source code
>> should always be distributed and binaries should be able to be built
>> from source. [1]
>>
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_le
>> g
>> al_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=qS4goWBT7popl
>> M
>> 69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7
>> d
>> 4gTao&m=TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDB
>> I
>> V4u8VP_xJreK4AveCzl8eM0MlxI&e=
>>
>> Thanks,
>> Murali
Re: Revert change to r.1768564
Posted by Pei Chen <ch...@apache.org>.
A package without the source code is called a product and that isn't
what the ASF does. Having to jump around hoops in order just to
include the source while performing a release contradicts what an Open
Source project does. If the rational is to save a few secs from
zipping source code during package time, why not just create a special
profile for binaryOnly which should be an exception rather than the
norm for an ASF project?
On Mon, Apr 10, 2017 at 4:03 PM, Finan, Sean
<Se...@childrens.harvard.edu> wrote:
>> As the apache doc ... states specifically "for release", not "for every package build"
>
> A package is not a release. The rationale is that people are building binaries of their own sandboxes to hand around the office. They don't want to double the time and build source that they already have. "The spirit" led me to make profiles, allowing more user control over what is going on.
>
> Perhaps the default should be zipping the universe, but allowing the user to disable one or the other (or certain system types). As I said in my previous email, 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:chenpei@apache.org]
> Sent: Monday, April 10, 2017 3:51 PM
> To: dev@ctakes.apache.org
> Subject: Re: Revert change to r.1768564
>
> 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 distribute source code and convenience binaries together (source code being mandatory.) When the ctakes-distribution project was created, it's intention was to create the src and bin artifacts for distribution just as the name suggests. The spirit of NOT distributing source by default is not appropriate for any open source project. Sure, there are many ways to work around it, but I do not see it as a technical issue.
>
> On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean <Se...@childrens.harvard.edu> wrote:
>> 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.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
>> aven-2Drelease_maven-2Drelease-2Dplugin_perform-2Dmojo.html&d=DwIFaQ&c
>> =qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQ
>> CP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGYbnNTkG8IA&s=V
>> KIk2as8kChuuwI3LkL99t5XzkEjLYHiMkfQJL4gF4c&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
>> aven-2Drelease_maven-2Drelease-2Dplugin_examples_perform-2Drelease.htm
>> l&d=DwIFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZst
>> TpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGYb
>> nNTkG8IA&s=fqq7gqZOTpzPlv1qGjXqvMmPheqT9M_VVrxMGGUWITg&e=
>>
>> We may want to move forward, not back. Thoughts?
>>
>> -----Original Message-----
>> From: Murali Minnah [mailto:mminnah@gmail.com]
>> Sent: Monday, April 10, 2017 10:28 AM
>> To: dev@ctakes.apache.org
>> Subject: Revert change to r.1768564
>>
>> 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 default, packageSource is not"
>>
>>
>> This changed prevents source code from being distributed using the
>> default apache release profile when running mvn
>> release:prepare/perform. In fact, it should be the opposite. At ASF,
>> binaries are only distributed as a convenience; source code should
>> always be distributed and binaries should be able to be built from
>> source. [1]
>>
>> [1]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_leg
>> al_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=qS4goWBT7poplM
>> 69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d
>> 4gTao&m=TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBI
>> V4u8VP_xJreK4AveCzl8eM0MlxI&e=
>>
>> Thanks,
>> Murali
RE: Revert change to r.1768564
Posted by "Finan, Sean" <Se...@childrens.harvard.edu>.
> As the apache doc ... states specifically "for release", not "for every package build"
A package is not a release. The rationale is that people are building binaries of their own sandboxes to hand around the office. They don't want to double the time and build source that they already have. "The spirit" led me to make profiles, allowing more user control over what is going on.
Perhaps the default should be zipping the universe, but allowing the user to disable one or the other (or certain system types). As I said in my previous email, 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:chenpei@apache.org]
Sent: Monday, April 10, 2017 3:51 PM
To: dev@ctakes.apache.org
Subject: Re: Revert change to r.1768564
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 distribute source code and convenience binaries together (source code being mandatory.) When the ctakes-distribution project was created, it's intention was to create the src and bin artifacts for distribution just as the name suggests. The spirit of NOT distributing source by default is not appropriate for any open source project. Sure, there are many ways to work around it, but I do not see it as a technical issue.
On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean <Se...@childrens.harvard.edu> wrote:
> 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.
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
> aven-2Drelease_maven-2Drelease-2Dplugin_perform-2Dmojo.html&d=DwIFaQ&c
> =qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQ
> CP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGYbnNTkG8IA&s=V
> KIk2as8kChuuwI3LkL99t5XzkEjLYHiMkfQJL4gF4c&e=
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_m
> aven-2Drelease_maven-2Drelease-2Dplugin_examples_perform-2Drelease.htm
> l&d=DwIFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZst
> TpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=1JGJMC89sA12H0FxEnBHl0K0Ea9w-zxWGYb
> nNTkG8IA&s=fqq7gqZOTpzPlv1qGjXqvMmPheqT9M_VVrxMGGUWITg&e=
>
> We may want to move forward, not back. Thoughts?
>
> -----Original Message-----
> From: Murali Minnah [mailto:mminnah@gmail.com]
> Sent: Monday, April 10, 2017 10:28 AM
> To: dev@ctakes.apache.org
> Subject: Revert change to r.1768564
>
> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the
> default apache release profile when running mvn
> release:prepare/perform. In fact, it should be the opposite. At ASF,
> binaries are only distributed as a convenience; source code should
> always be distributed and binaries should be able to be built from
> source. [1]
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_leg
> al_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=qS4goWBT7poplM
> 69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d
> 4gTao&m=TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBI
> V4u8VP_xJreK4AveCzl8eM0MlxI&e=
>
> Thanks,
> Murali
Re: Revert change to r.1768564
Posted by Pei Chen <ch...@apache.org>.
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 distribute source code and convenience binaries
together (source code being mandatory.) When the ctakes-distribution
project was created, it's intention was to create the src and bin
artifacts for distribution just as the name suggests. The spirit of
NOT distributing source by default is not appropriate for any open
source project. Sure, there are many ways to work around it, but I do
not see it as a technical issue.
On Mon, Apr 10, 2017 at 12:32 PM, Finan, Sean
<Se...@childrens.harvard.edu> wrote:
> 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-release-plugin/perform-mojo.html
>
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
>
> We may want to move forward, not back. Thoughts?
>
> -----Original Message-----
> From: Murali Minnah [mailto:mminnah@gmail.com]
> Sent: Monday, April 10, 2017 10:28 AM
> To: dev@ctakes.apache.org
> Subject: Revert change to r.1768564
>
> 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 default, packageSource is not"
>
>
> This changed prevents source code from being distributed using the default apache release profile when running mvn release:prepare/perform. In fact, it should be the opposite. At ASF, binaries are only distributed as a convenience; source code should always be distributed and binaries should be able to be built from source. [1]
>
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_legal_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBIV4u8VP_xJreK4AveCzl8eM0MlxI&e=
>
> Thanks,
> Murali
RE: Revert change to r.1768564
Posted by "Finan, Sean" <Se...@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-release-plugin/perform-mojo.html
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
We may want to move forward, not back. Thoughts?
-----Original Message-----
From: Murali Minnah [mailto:mminnah@gmail.com]
Sent: Monday, April 10, 2017 10:28 AM
To: dev@ctakes.apache.org
Subject: Revert change to r.1768564
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 default, packageSource is not"
This changed prevents source code from being distributed using the default apache release profile when running mvn release:prepare/perform. In fact, it should be the opposite. At ASF, binaries are only distributed as a convenience; source code should always be distributed and binaries should be able to be built from source. [1]
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_legal_release-2Dpolicy.html-23source-2Dpackages&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=TcreDrqDHWUkbuW2epBdEaFrwZNKbGPossM9FjA9jKM&s=rpoKRwFC5zDIVDBIV4u8VP_xJreK4AveCzl8eM0MlxI&e=
Thanks,
Murali