[ALL] SHA256/512 hashes

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ALL] SHA256/512 hashes

sebb-2-2
As noted in another thread, I don't think the recent change to the
Apache parent pom is of any use to  Commons.

However it does provide an example of how to use the checksum plugin.

This has been used to create a sample profile that could be added to CP.

See COMMONSSITE-121

Or for local testing, it can be added to a component POM.

It works for me with NET, also tried LANG.

(Using Maven 3.5.4)

There's probably still some work to get the files uploaded to the correct place.

S.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

garydgregory
Our release plugin already creates SHA256 and SHA512 files and saves those
to Apache's dev/dist for an RC as part of creating an RC, pushing it to
Nexus and dist/dev.

Is what you are referring to for a different purpose?

Gary

On Fri, Aug 24, 2018 at 6:03 PM sebb <[hidden email]> wrote:

> As noted in another thread, I don't think the recent change to the
> Apache parent pom is of any use to  Commons.
>
> However it does provide an example of how to use the checksum plugin.
>
> This has been used to create a sample profile that could be added to CP.
>
> See COMMONSSITE-121
>
> Or for local testing, it can be added to a component POM.
>
> It works for me with NET, also tried LANG.
>
> (Using Maven 3.5.4)
>
> There's probably still some work to get the files uploaded to the correct
> place.
>
> S.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Stefan Bodewig
On 2018-08-25, Gary Gregory wrote:

> Our release plugin already creates SHA256 and SHA512 files and saves those
> to Apache's dev/dist for an RC as part of creating an RC, pushing it to
> Nexus and dist/dev.

> Is what you are referring to for a different purpose?

Probably for those who don't want to use the release plugin :-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

sebb-2-2
On 25 August 2018 at 09:48, Stefan Bodewig <[hidden email]> wrote:
> On 2018-08-25, Gary Gregory wrote:
>
>> Our release plugin already creates SHA256 and SHA512 files and saves those
>> to Apache's dev/dist for an RC as part of creating an RC, pushing it to
>> Nexus and dist/dev.

Ah, I've not looked at that yet.

>> Is what you are referring to for a different purpose?
>
> Probably for those who don't want to use the release plugin :-)

I was mainly following up on the thread about updating CP to AP 21 [1]

But yes, it could be used as an alternative hashing method.
In which case, if it is going to be put in CP rather than individual
POMs, it should be in its own profile.
(Or possibly two, one for SHA256 and one for SHA512?)

[1] https://lists.apache.org/thread.html/a130864e39cc4ffb15c4018dc05142a405861b523fd14573010ea3e0@%3Cdev.commons.apache.org%3E

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Gilles Sadowski
On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:

> On 25 August 2018 at 09:48, Stefan Bodewig <[hidden email]>
> wrote:
>> On 2018-08-25, Gary Gregory wrote:
>>
>>> Our release plugin already creates SHA256 and SHA512 files and
>>> saves those
>>> to Apache's dev/dist for an RC as part of creating an RC, pushing
>>> it to
>>> Nexus and dist/dev.
>
> Ah, I've not looked at that yet.
>
>>> Is what you are referring to for a different purpose?
>>
>> Probably for those who don't want to use the release plugin :-)
>
> I was mainly following up on the thread about updating CP to AP 21
> [1]
>
> But yes, it could be used as an alternative hashing method.

I thought that the release plugin was intended for all
components to converge on the same release "recipe"...

> In which case, if it is going to be put in CP rather than individual
> POMs, it should be in its own profile.
> (Or possibly two, one for SHA256 and one for SHA512?)

+1 for *one* profile that leaves no room for working around
global policy (thus simplifying release review work).
Couldn't CP use a "property" from AP to ensure that the
required hash is generated or the build will fail?

Gilles

>
> [1]
>
> https://lists.apache.org/thread.html/a130864e39cc4ffb15c4018dc05142a405861b523fd14573010ea3e0@%3Cdev.commons.apache.org%3E
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Stefan Bodewig
On 2018-08-25, Gilles wrote:

> On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:
>> On 25 August 2018 at 09:48, Stefan Bodewig <[hidden email]>
>> wrote:
>>> On 2018-08-25, Gary Gregory wrote:

>>>> Is what you are referring to for a different purpose?

>>> Probably for those who don't want to use the release plugin :-)

>> But yes, it could be used as an alternative hashing method.

> I thought that the release plugin was intended for all
> components to converge on the same release "recipe"...

That's not my understanding. We vote on the release artifacts; how these
are created is up to the release manager. The release plugin offers a
way to make releases easier but it is never going to become the only
permitted way of cutting releases.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Gilles Sadowski
On Sat, 25 Aug 2018 19:05:55 +0200, Stefan Bodewig wrote:

> On 2018-08-25, Gilles wrote:
>
>> On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:
>>> On 25 August 2018 at 09:48, Stefan Bodewig <[hidden email]>
>>> wrote:
>>>> On 2018-08-25, Gary Gregory wrote:
>
>>>>> Is what you are referring to for a different purpose?
>
>>>> Probably for those who don't want to use the release plugin :-)
>
>>> But yes, it could be used as an alternative hashing method.
>
>> I thought that the release plugin was intended for all
>> components to converge on the same release "recipe"...
>
> That's not my understanding. We vote on the release artifacts; how
> these
> are created is up to the release manager. The release plugin offers a
> way to make releases easier but it is never going to become the only
> permitted way of cutting releases.

It's not what I meant either, even if it ultimately would
become the preferred, easy and fool-proof, way.
The suggestion is more on sub-project configuration (POM)
convergence.

Regards,
Gilles

>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Thomas Vandahl
In reply to this post by Gilles Sadowski
On 25.08.18 16:14, Gilles wrote:
>>> Probably for those who don't want to use the release plugin :-)
>>
>> I was mainly following up on the thread about updating CP to AP 21 [1]
>>
>> But yes, it could be used as an alternative hashing method.
>
> I thought that the release plugin was intended for all
> components to converge on the same release "recipe"...

This is unlikely to happen as long as it does not cover multi-module builds.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Gilles Sadowski
On Sun, 26 Aug 2018 10:43:02 +0200, Thomas Vandahl wrote:

> On 25.08.18 16:14, Gilles wrote:
>>>> Probably for those who don't want to use the release plugin :-)
>>>
>>> I was mainly following up on the thread about updating CP to AP 21
>>> [1]
>>>
>>> But yes, it could be used as an alternative hashing method.
>>
>> I thought that the release plugin was intended for all
>> components to converge on the same release "recipe"...
>
> This is unlikely to happen as long as it does not cover multi-module
> builds.

"Commons RNG" is multi-module and v1.1 was RMed by Rob
with his release-plugin.

Gilles

P.S. I hope that Rob will update the [RNG] step-by-step howto,
      currently in "doc/release" directory, so that anyone else
      can duplicate his feat. ;-)

>
> Bye, Thomas.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Mark Struberg-2
In reply to this post by Thomas Vandahl
> This is unlikely to happen as long as it does not cover multi-module builds

The maven-release-plugin covers multi-module releases since many years.

In the projects I'm working on there is no 'release manager'.
_Everybody_ can do releases without having to know anything special.
This is where the maven-release-plugin really shines.
Just use mvn release:prepare + mvn release:perform and be done.

Of course it's fine if projects use ant, etc.
But ideally there should be a single way to kick of a release (fully automated, same target name across projects, etc)

LieGrue,
strub


> Am 26.08.2018 um 10:43 schrieb Thomas Vandahl <[hidden email]>:
>
> On 25.08.18 16:14, Gilles wrote:
>>>> Probably for those who don't want to use the release plugin :-)
>>>
>>> I was mainly following up on the thread about updating CP to AP 21 [1]
>>>
>>> But yes, it could be used as an alternative hashing method.
>>
>> I thought that the release plugin was intended for all
>> components to converge on the same release "recipe"...
>
> This is unlikely to happen as long as it does not cover multi-module builds.
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Gilles Sadowski
On Tue, 28 Aug 2018 10:25:54 +0200, Mark Struberg wrote:

>> This is unlikely to happen as long as it does not cover multi-module
>> builds
>
> The maven-release-plugin covers multi-module releases since many
> years.
>
> In the projects I'm working on there is no 'release manager'.
> _Everybody_ can do releases without having to know anything special.
> This is where the maven-release-plugin really shines.
> Just use mvn release:prepare + mvn release:perform and be done.
>
> Of course it's fine if projects use ant, etc.
> But ideally there should be a single way to kick of a release (fully
> automated, same target name across projects, etc)

+1

Since the goal is the same the same across components (generate
JAR files and upload them to Nexus), having several ways is
duplicating maintenance effort.

Regards,
Gilles

>
> LieGrue,
> strub
>
>
>> Am 26.08.2018 um 10:43 schrieb Thomas Vandahl <[hidden email]>:
>>
>> On 25.08.18 16:14, Gilles wrote:
>>>>> Probably for those who don't want to use the release plugin :-)
>>>>
>>>> I was mainly following up on the thread about updating CP to AP 21
>>>> [1]
>>>>
>>>> But yes, it could be used as an alternative hashing method.
>>>
>>> I thought that the release plugin was intended for all
>>> components to converge on the same release "recipe"...
>>
>> This is unlikely to happen as long as it does not cover multi-module
>> builds.
>>
>> Bye, Thomas.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

sebb-2-2
In reply to this post by sebb-2-2
On 28 August 2018 at 09:25, Mark Struberg <[hidden email]> wrote:
>> This is unlikely to happen as long as it does not cover multi-module builds
>
> The maven-release-plugin covers multi-module releases since many years.
>
> In the projects I'm working on there is no 'release manager'.
> _Everybody_ can do releases without having to know anything special.
> This is where the maven-release-plugin really shines.
> Just use mvn release:prepare + mvn release:perform and be done.

If it works first time.

The problem is that the Maven release plugin design assumes that the
first release attempt will succeed.
As such, it updates trunk to the new snapshot version.
(This causes issues with CI builds)

It also assumes that the current workspace does not contain anything
it should not.

Neither of these assumptions is valid in general.

The Apache POM also makes assumptions about the content of the dist/ folder.

> Of course it's fine if projects use ant, etc.
> But ideally there should be a single way to kick of a release (fully automated, same target name across projects, etc)
>
> LieGrue,
> strub
>
>
>> Am 26.08.2018 um 10:43 schrieb Thomas Vandahl <[hidden email]>:
>>
>> On 25.08.18 16:14, Gilles wrote:
>>>>> Probably for those who don't want to use the release plugin :-)
>>>>
>>>> I was mainly following up on the thread about updating CP to AP 21 [1]
>>>>
>>>> But yes, it could be used as an alternative hashing method.
>>>
>>> I thought that the release plugin was intended for all
>>> components to converge on the same release "recipe"...
>>
>> This is unlikely to happen as long as it does not cover multi-module builds.
>>
>> Bye, Thomas.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Gilles Sadowski
On Tue, 28 Aug 2018 11:03:15 +0100, sebb wrote:

> On 28 August 2018 at 09:25, Mark Struberg <[hidden email]>
> wrote:
>>> This is unlikely to happen as long as it does not cover
>>> multi-module builds
>>
>> The maven-release-plugin covers multi-module releases since many
>> years.
>>
>> In the projects I'm working on there is no 'release manager'.
>> _Everybody_ can do releases without having to know anything special.
>> This is where the maven-release-plugin really shines.
>> Just use mvn release:prepare + mvn release:perform and be done.
>
> If it works first time.
>
> The problem is that the Maven release plugin design assumes that the
> first release attempt will succeed.
> As such, it updates trunk to the new snapshot version.
> (This causes issues with CI builds)
>
> It also assumes that the current workspace does not contain anything
> it should not.
>
> Neither of these assumptions is valid in general.
>
> The Apache POM also makes assumptions about the content of the dist/
> folder.

In light of this, then the approach implemented by Rob goes
in the right direction:
1. make it work here (for *all* components)
2. gradually fix upstream invalid assumptions (e.g. japicmp)

But the philosophy is the same: make the process simple and,
consequently, unique.

Regards,
Gilles

>
>> Of course it's fine if projects use ant, etc.
>> But ideally there should be a single way to kick of a release (fully
>> automated, same target name across projects, etc)
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 26.08.2018 um 10:43 schrieb Thomas Vandahl <[hidden email]>:
>>>
>>> On 25.08.18 16:14, Gilles wrote:
>>>>>> Probably for those who don't want to use the release plugin :-)
>>>>>
>>>>> I was mainly following up on the thread about updating CP to AP
>>>>> 21 [1]
>>>>>
>>>>> But yes, it could be used as an alternative hashing method.
>>>>
>>>> I thought that the release plugin was intended for all
>>>> components to converge on the same release "recipe"...
>>>
>>> This is unlikely to happen as long as it does not cover
>>> multi-module builds.
>>>
>>> Bye, Thomas.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Matt Sicker
In reply to this post by sebb-2-2
On Tue, 28 Aug 2018 at 05:03, sebb <[hidden email]> wrote:

> The problem is that the Maven release plugin design assumes that the
> first release attempt will succeed.
> As such, it updates trunk to the new snapshot version.
> (This causes issues with CI builds)
>

Would it work if you made a release branch first? Then you wouldn't merge
the release branch to master until the voted upon release candidate is
accepted.


> It also assumes that the current workspace does not contain anything
> it should not.
>

It doesn't check out the tag into a separate directory to build the release
artifacts?


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

sebb-2-2
On 28 August 2018 at 19:36, Matt Sicker <[hidden email]> wrote:

> On Tue, 28 Aug 2018 at 05:03, sebb <[hidden email]> wrote:
>
>> The problem is that the Maven release plugin design assumes that the
>> first release attempt will succeed.
>> As such, it updates trunk to the new snapshot version.
>> (This causes issues with CI builds)
>>
>
> Would it work if you made a release branch first? Then you wouldn't merge
> the release branch to master until the voted upon release candidate is
> accepted.

Unless it relies on updating trunk rather than the current workspace,
I guess that should work.

But it's extra work, so why does the plugin not do it for you?

>
>> It also assumes that the current workspace does not contain anything
>> it should not.
>>
>
> It doesn't check out the tag into a separate directory to build the release
> artifacts?

Last time I checked it did not.

>
> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Thomas Vandahl
In reply to this post by sebb-2-2
On 28.08.18 12:03, sebb wrote:

> On 28 August 2018 at 09:25, Mark Struberg <[hidden email]> wrote:
>>> This is unlikely to happen as long as it does not cover multi-module builds
>>
>> The maven-release-plugin covers multi-module releases since many years.
>>
>> In the projects I'm working on there is no 'release manager'.
>> _Everybody_ can do releases without having to know anything special.
>> This is where the maven-release-plugin really shines.
>> Just use mvn release:prepare + mvn release:perform and be done.
>
> If it works first time.

I think the release plugin does quite a good job in resuming broken
build processes, rolling back etc.
>
> The problem is that the Maven release plugin design assumes that the
> first release attempt will succeed.
> As such, it updates trunk to the new snapshot version.
> (This causes issues with CI builds)

You are free to choose whatever developmentVersion should be recorded.

> It also assumes that the current workspace does not contain anything
> it should not.

I actually consider this an advantage. It helps you to avoid
inconsistent source trees. If you want to get around this, see
checkModificationExcludeList of the prepare goal.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Thomas Vandahl
In reply to this post by sebb-2-2
On 29.08.18 01:18, sebb wrote:
>> It doesn't check out the tag into a separate directory to build the release
>> artifacts?
>
> Last time I checked it did not.

The release:perform goal does this and always did. See target/checkout.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

sebb-2-2
In reply to this post by Thomas Vandahl
On 30 August 2018 at 11:19, Thomas Vandahl <[hidden email]> wrote:

> On 28.08.18 12:03, sebb wrote:
>> On 28 August 2018 at 09:25, Mark Struberg <[hidden email]> wrote:
>>>> This is unlikely to happen as long as it does not cover multi-module builds
>>>
>>> The maven-release-plugin covers multi-module releases since many years.
>>>
>>> In the projects I'm working on there is no 'release manager'.
>>> _Everybody_ can do releases without having to know anything special.
>>> This is where the maven-release-plugin really shines.
>>> Just use mvn release:prepare + mvn release:perform and be done.
>>
>> If it works first time.
>
> I think the release plugin does quite a good job in resuming broken
> build processes, rolling back etc.

Only for the RM.

Meanwhile, trunk has been changed.

>>
>> The problem is that the Maven release plugin design assumes that the
>> first release attempt will succeed.
>> As such, it updates trunk to the new snapshot version.
>> (This causes issues with CI builds)
>
> You are free to choose whatever developmentVersion should be recorded.

It should not be necessary to downdate the new version.

>> It also assumes that the current workspace does not contain anything
>> it should not.
>
> I actually consider this an advantage. It helps you to avoid
> inconsistent source trees.

Huh?

If a local workspace contains spurious files, by definition it is inconsistent.

> If you want to get around this, see
> checkModificationExcludeList of the prepare goal.

Again, it should be the default to use a clean checkout of the tag for
building the binary/source artifacts.

> Bye, Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Benedikt Ritter-4
Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb <[hidden email]>:

> On 30 August 2018 at 11:19, Thomas Vandahl <[hidden email]> wrote:
> > On 28.08.18 12:03, sebb wrote:
> >> On 28 August 2018 at 09:25, Mark Struberg <[hidden email]>
> wrote:
> >>>> This is unlikely to happen as long as it does not cover multi-module
> builds
> >>>
> >>> The maven-release-plugin covers multi-module releases since many years.
> >>>
> >>> In the projects I'm working on there is no 'release manager'.
> >>> _Everybody_ can do releases without having to know anything special.
> >>> This is where the maven-release-plugin really shines.
> >>> Just use mvn release:prepare + mvn release:perform and be done.
> >>
> >> If it works first time.
> >
> > I think the release plugin does quite a good job in resuming broken
> > build processes, rolling back etc.
>
> Only for the RM.
>
> Meanwhile, trunk has been changed.
>
> >>
> >> The problem is that the Maven release plugin design assumes that the
> >> first release attempt will succeed.
> >> As such, it updates trunk to the new snapshot version.
> >> (This causes issues with CI builds)
> >
> > You are free to choose whatever developmentVersion should be recorded.
>
> It should not be necessary to downdate the new version.
>
> >> It also assumes that the current workspace does not contain anything
> >> it should not.
> >
> > I actually consider this an advantage. It helps you to avoid
> > inconsistent source trees.
>
> Huh?
>
> If a local workspace contains spurious files, by definition it is
> inconsistent.
>
> > If you want to get around this, see
> > checkModificationExcludeList of the prepare goal.
>
> Again, it should be the default to use a clean checkout of the tag for
> building the binary/source artifacts.
>

Please note, that all what you are saying is just your opinion on how a
release should be created. The maven team clearly has another opinion on
that. Both are valid.

Our release process is cumbersome and fragile leading to all release
looking a little different from each other, depending on who is RM.
The pain that our release process causes has been brought up again and
again since I started here at commons back in 2011. I wonder whether it is
a good idea to use a tool like maven that is pretty opinionated on how to
do things and then bend it to do it another way. Maybe we should simply use
maven the way it is intended. Or if we can't live with the way maven does
things, maybe we should use a tool that gives us more liberty in
customizing the build, e.g. gradle.

Benedikt


>
> > Bye, Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] SHA256/512 hashes

Thomas Vandahl
On 31.08.18 10:46, Benedikt Ritter wrote:
> Our release process is cumbersome and fragile leading to all release
> looking a little different from each other, depending on who is RM.
> The pain that our release process causes has been brought up again and
> again since I started here at commons back in 2011. I wonder whether it is
> a good idea to use a tool like maven that is pretty opinionated on how to
> do things and then bend it to do it another way. Maybe we should simply use
> maven the way it is intended. Or if we can't live with the way maven does
> things, maybe we should use a tool that gives us more liberty in
> customizing the build, e.g. gradle.

Thanks, Benedikt.
My big +1 for the Maven way. It simply works for all my other projects,
they may be open source or not. And people coming in from somewhere else
don't have to learn a dozen different tools.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12