[DISCUSS] Why is releasing such a pain and what can we do to make it easier?

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

[DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Benedikt Ritter-4
Hi,

one of the points that seem to always come up once in a while is the
process of releasing components. I've never done it myself so I'm asking
people who have done it:

What are the problems and how can we make releasing easier?
Is the complexity of the parent pom a problem? (Do we really need all the
stuff that is declared there?)
Is there a way to automate all the stuff that needs to be done in a
portable way?
Would it be possible to automate release for example on a Jenkins instance?

Benedikt


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Emmanuel Bourg-3
Le 08/10/2013 18:46, Benedikt Ritter a écrit :

> What are the problems and how can we make releasing easier?

I have a real example with JCI. I get an error when running the release
profile with "mvn package -DskipTests -Prelease" :

[INFO] ----------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------
[INFO] Error assembling JAR

Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
does not exist.


Any idea?

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

garydgregory
In reply to this post by Benedikt Ritter-4
IMO the problems are dealing with Nexus, a web site, and a 'dist'
directory; that THREE things to get just right, none are 100% automated.
With Nexus you have to do some manual steps. If you look at all the
instructions for any commons component, it is long, a combo of manual and
Maven+Nexus magic and error prone. It is not fun and a barrier.

Gary


On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
> one of the points that seem to always come up once in a while is the
> process of releasing components. I've never done it myself so I'm asking
> people who have done it:
>
> What are the problems and how can we make releasing easier?
> Is the complexity of the parent pom a problem? (Do we really need all the
> stuff that is declared there?)
> Is there a way to automate all the stuff that needs to be done in a
> portable way?
> Would it be possible to automate release for example on a Jenkins instance?
>
> Benedikt
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

[JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

Benedikt Ritter-3
In reply to this post by Emmanuel Bourg-3
Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.

Benedikt

Send from my mobile device

> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <[hidden email]>:
>
> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>
>> What are the problems and how can we make releasing easier?
>
> I have a real example with JCI. I get an error when running the release
> profile with "mvn package -DskipTests -Prelease" :
>
> [INFO] ----------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ----------------------------------------------------
> [INFO] Error assembling JAR
>
> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
> does not exist.
>
>
> Any idea?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Benedikt Ritter-3
In reply to this post by garydgregory
Hey Gary,

you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?

Benedikt

Send from my mobile device

> Am 08.10.2013 um 19:52 schrieb Gary Gregory <[hidden email]>:
>
> IMO the problems are dealing with Nexus, a web site, and a 'dist'
> directory; that THREE things to get just right, none are 100% automated.
> With Nexus you have to do some manual steps. If you look at all the
> instructions for any commons component, it is long, a combo of manual and
> Maven+Nexus magic and error prone. It is not fun and a barrier.
>
> Gary
>
>
>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <[hidden email]> wrote:
>>
>> Hi,
>>
>> one of the points that seem to always come up once in a while is the
>> process of releasing components. I've never done it myself so I'm asking
>> people who have done it:
>>
>> What are the problems and how can we make releasing easier?
>> Is the complexity of the parent pom a problem? (Do we really need all the
>> stuff that is declared there?)
>> Is there a way to automate all the stuff that needs to be done in a
>> portable way?
>> Would it be possible to automate release for example on a Jenkins instance?
>>
>> Benedikt
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

garydgregory
Luckily, Ralph handles release manager duties, for which I am
grateful. So I cannot speak to the ease or difficulty of the process
there.

Gary

On Oct 8, 2013, at 14:08, Benedikt Ritter <[hidden email]> wrote:

> Hey Gary,
>
> you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?
>
> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <[hidden email]>:
>>
>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>> directory; that THREE things to get just right, none are 100% automated.
>> With Nexus you have to do some manual steps. If you look at all the
>> instructions for any commons component, it is long, a combo of manual and
>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>
>> Gary
>>
>>
>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> one of the points that seem to always come up once in a while is the
>>> process of releasing components. I've never done it myself so I'm asking
>>> people who have done it:
>>>
>>> What are the problems and how can we make releasing easier?
>>> Is the complexity of the parent pom a problem? (Do we really need all the
>>> stuff that is declared there?)
>>> Is there a way to automate all the stuff that needs to be done in a
>>> portable way?
>>> Would it be possible to automate release for example on a Jenkins instance?
>>>
>>> Benedikt
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Woonsan Ko
I think I understand what Gary means.
I once wrote down the process to release Apache Portals Application for other PMC members here:
- http://wiki.apache.org/portals/Applications/Release_Process
I guess the process is almost the same in other projects (log4j2 or possibly lang).

There are many time consuming / error-prone steps like Gary mentioned. I have no idea on how we can possibly improve the process though.


Regards,

Woonsan



----- Original Message -----

> From: Gary Gregory <[hidden email]>
> To: Commons Developers List <[hidden email]>
> Cc:
> Sent: Tuesday, October 8, 2013 2:10 PM
> Subject: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
>
> Luckily, Ralph handles release manager duties, for which I am
> grateful. So I cannot speak to the ease or difficulty of the process
> there.
>
> Gary
>
> On Oct 8, 2013, at 14:08, Benedikt Ritter <[hidden email]> wrote:
>
>>  Hey Gary,
>>
>>  you are involved in other projects (like log4j2) how do they do it? Is it
> easier to release log4j2 than it is to release for example [lang]?
>>
>>  Benedikt
>>
>>  Send from my mobile device
>>
>>>  Am 08.10.2013 um 19:52 schrieb Gary Gregory
> <[hidden email]>:
>>>
>>>  IMO the problems are dealing with Nexus, a web site, and a
> 'dist'
>>>  directory; that THREE things to get just right, none are 100%
> automated.
>>>  With Nexus you have to do some manual steps. If you look at all the
>>>  instructions for any commons component, it is long, a combo of manual
> and
>>>  Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>>  Gary
>>>
>>>
>>>>  On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter
> <[hidden email]> wrote:
>>>>
>>>>  Hi,
>>>>
>>>>  one of the points that seem to always come up once in a while is
> the
>>>>  process of releasing components. I've never done it myself so
> I'm asking
>>>>  people who have done it:
>>>>
>>>>  What are the problems and how can we make releasing easier?
>>>>  Is the complexity of the parent pom a problem? (Do we really need
> all the
>>>>  stuff that is declared there?)
>>>>  Is there a way to automate all the stuff that needs to be done in a
>>>>  portable way?
>>>>  Would it be possible to automate release for example on a Jenkins
> instance?
>>>>
>>>>  Benedikt
>>>>
>>>>
>>>>  --
>>>>  http://people.apache.org/~britter/
>>>>  http://www.systemoutprintln.de/
>>>>  http://twitter.com/BenediktRitter
>>>>  http://github.com/britter
>>>
>>>
>>>
>>>  --
>>>  E-Mail: [hidden email] | [hidden email]
>>>  Java Persistence with Hibernate, Second
> Edition<http://www.manning.com/bauer3/>
>>>  JUnit in Action, Second Edition
> <http://www.manning.com/tahchiev/>
>>>  Spring Batch in Action <http://www.manning.com/templier/>
>>>  Blog: http://garygregory.wordpress.com
>>>  Home: http://garygregory.com/
>>>  Tweet! http://twitter.com/GaryGregory
>>
>>  ---------------------------------------------------------------------
>>  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: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Christian Grobmeier
In reply to this post by Benedikt Ritter-3
On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:

> Hey Gary,
>
> you are involved in other projects (like log4j2) how do they do it? Is
> it easier to release log4j2 than it is to release for example [lang]?

Check this guide:
http://wiki.apache.org/logging/Log4j2ReleaseGuide

In fact we have an ASF maven pom:
http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
This is extended by tons of plugins and other things and called "commons
parent pom". The commons parent pom does a lot of things, and all
components are more or less required to run the same way.

The question is, why should a component not be independent from
commons-parent-pom and decide on it's on? With having the ASF-parent
only releasing could be:

mvn release:prepare release:perform

Then everything should be on Nexus.

I know this is a controverse question. But as people can download the
artifacts directly from nexus if they wish - including source, LICENSE,
NOTICE and all that… why are we bothering to put on any other place?
One could see at as: we release source code, as we create a tag. For
convenience we put it on Nexus. Nothing else.

For site: I think components should be free to chose on their own. I was
thinking different in the past. But now I believe we should just have a
front page listing our components like we have here:
http://logging.apache.org
…and that site should link to the appropriate sub component site. How
it looks or works or how it is build should be decided by the component
maintainers independently.

Cheers
Christian

> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <[hidden email]>:
>>
>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>> directory; that THREE things to get just right, none are 100%
>> automated.
>> With Nexus you have to do some manual steps. If you look at all the
>> instructions for any commons component, it is long, a combo of manual
>> and
>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>
>> Gary
>>
>>
>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter
>>> <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> one of the points that seem to always come up once in a while is the
>>> process of releasing components. I've never done it myself so I'm
>>> asking
>>> people who have done it:
>>>
>>> What are the problems and how can we make releasing easier?
>>> Is the complexity of the parent pom a problem? (Do we really need
>>> all the
>>> stuff that is declared there?)
>>> Is there a way to automate all the stuff that needs to be done in a
>>> portable way?
>>> Would it be possible to automate release for example on a Jenkins
>>> instance?
>>>
>>> Benedikt
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> Java Persistence with Hibernate, Second
>> Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

sebb-2-2
On 8 October 2013 19:44, Christian Grobmeier <[hidden email]> wrote:

> On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
>
>> Hey Gary,
>>
>> you are involved in other projects (like log4j2) how do they do it? Is it
>> easier to release log4j2 than it is to release for example [lang]?
>
>
> Check this guide:
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> In fact we have an ASF maven pom:
> http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
> This is extended by tons of plugins and other things and called "commons
> parent pom". The commons parent pom does a lot of things, and all components
> are more or less required to run the same way.
>
> The question is, why should a component not be independent from
> commons-parent-pom and decide on it's on? With having the ASF-parent only
> releasing could be:
>
> mvn release:prepare release:perform

Or equally using the package / deploy manual version.

> Then everything should be on Nexus.
>
> I know this is a controverse question. But as people can download the
> artifacts directly from nexus if they wish - including source, LICENSE,
> NOTICE and all that… why are we bothering to put on any other place?

If you are referring to staging for the release vote, then I agree,
it's not necessary to use another area.

But for formal ASF releases, these must be done via www.apache.org/dist/commons

> One could see at as: we release source code, as we create a tag. For
> convenience we put it on Nexus. Nothing else.

No - Nexus is the only way to release components to Maven Central;
it's not possible to publish jars to MC independently.
(With good reason - there were several accidental 'releases' before
Nexus was introduced).

> For site: I think components should be free to chose on their own. I was
> thinking different in the past. But now I believe we should just have a
> front page listing our components like we have here:
> http://logging.apache.org
> …and that site should link to the appropriate sub component site. How it
> looks or works or how it is build should be decided by the component
> maintainers independently.

OK by me, so long as the ASF branding etc. requirements are met.

> Cheers
> Christian
>
>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <[hidden email]>:
>>>
>>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>>> directory; that THREE things to get just right, none are 100% automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>> Gary
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <[hidden email]>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>>
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need all
>>>> the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins
>>>> instance?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> Java Persistence with Hibernate, Second
>>> Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
>
> ---------------------------------------------------------------------
> 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: [JCI] Problem with release profile

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-3
Le 08/10/2013 20:06, Benedikt Ritter a écrit :
> Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.

Could this be caused by the fact that jci is a multi module project?

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

sebb-2-2
In reply to this post by Benedikt Ritter-3
On 8 October 2013 19:06, Benedikt Ritter <[hidden email]> wrote:
> Maybe it's a problem with the maven-bundle-plugin. It should generate the Manifest for you. I'm on my mobile right now and will not have the time to have a look until tomorrow.

It's not only the osgi Manifest.

I tried copying an existing Manifest, and the build process failed with:

[INFO] Error for project: Apache Commons JCI FileAlterationMonitor
(during package)
[INFO] ------------------------------------------------------------------------
[INFO] Failed to create assembly: Error creating assembly archive bin:
You must set at least one file.

The problems are probably due to the use of multiple modules, which
are (much) harder to set up.

However, there are other commons components with multiple modules; it
should be possible to get some clues from them.

Note: we must update Javadoc plugin to the latest version to ensure
that the scripting bug is fixed.

I expect there are several parts of the main pom that can be removed
as the parent pom defines all the common stuff that it can.

> Benedikt
>
> Send from my mobile device
>
>> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <[hidden email]>:
>>
>> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>>
>>> What are the problems and how can we make releasing easier?
>>
>> I have a real example with JCI. I get an error when running the release
>> profile with "mvn package -DskipTests -Prelease" :
>>
>> [INFO] ----------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO] ----------------------------------------------------
>> [INFO] Error assembling JAR
>>
>> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
>> does not exist.
>>
>>
>> Any idea?
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> 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: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

Benedikt Ritter-4
Do you have included the latest commons parent pom?


2013/10/8 sebb <[hidden email]>

> On 8 October 2013 19:06, Benedikt Ritter <[hidden email]> wrote:
> > Maybe it's a problem with the maven-bundle-plugin. It should generate
> the Manifest for you. I'm on my mobile right now and will not have the time
> to have a look until tomorrow.
>
> It's not only the osgi Manifest.
>
> I tried copying an existing Manifest, and the build process failed with:
>
> [INFO] Error for project: Apache Commons JCI FileAlterationMonitor
> (during package)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to create assembly: Error creating assembly archive bin:
> You must set at least one file.
>
> The problems are probably due to the use of multiple modules, which
> are (much) harder to set up.
>
> However, there are other commons components with multiple modules; it
> should be possible to get some clues from them.
>
> Note: we must update Javadoc plugin to the latest version to ensure
> that the scripting bug is fixed.
>
> I expect there are several parts of the main pom that can be removed
> as the parent pom defines all the common stuff that it can.
>
> > Benedikt
> >
> > Send from my mobile device
> >
> >> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <[hidden email]>:
> >>
> >> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
> >>
> >>> What are the problems and how can we make releasing easier?
> >>
> >> I have a real example with JCI. I get an error when running the release
> >> profile with "mvn package -DskipTests -Prelease" :
> >>
> >> [INFO] ----------------------------------------------------
> >> [ERROR] BUILD ERROR
> >> [INFO] ----------------------------------------------------
> >> [INFO] Error assembling JAR
> >>
> >> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
> >> does not exist.
> >>
> >>
> >> Any idea?
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [JCI] Problem with release profile

Emmanuel Bourg-3
In reply to this post by sebb-2-2
Le 08/10/2013 21:25, sebb a écrit :

> However, there are other commons components with multiple modules; it
> should be possible to get some clues from them.

Thank you for the suggestion, I found the solution in vfs.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [JCI] Problem with release profile (was: Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?)

sebb-2-2
In reply to this post by Benedikt Ritter-4
Yes.

On 8 October 2013 20:40, Benedikt Ritter <[hidden email]> wrote:

> Do you have included the latest commons parent pom?
>
>
> 2013/10/8 sebb <[hidden email]>
>
>> On 8 October 2013 19:06, Benedikt Ritter <[hidden email]> wrote:
>> > Maybe it's a problem with the maven-bundle-plugin. It should generate
>> the Manifest for you. I'm on my mobile right now and will not have the time
>> to have a look until tomorrow.
>>
>> It's not only the osgi Manifest.
>>
>> I tried copying an existing Manifest, and the build process failed with:
>>
>> [INFO] Error for project: Apache Commons JCI FileAlterationMonitor
>> (during package)
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to create assembly: Error creating assembly archive bin:
>> You must set at least one file.
>>
>> The problems are probably due to the use of multiple modules, which
>> are (much) harder to set up.
>>
>> However, there are other commons components with multiple modules; it
>> should be possible to get some clues from them.
>>
>> Note: we must update Javadoc plugin to the latest version to ensure
>> that the scripting bug is fixed.
>>
>> I expect there are several parts of the main pom that can be removed
>> as the parent pom defines all the common stuff that it can.
>>
>> > Benedikt
>> >
>> > Send from my mobile device
>> >
>> >> Am 08.10.2013 um 19:25 schrieb Emmanuel Bourg <[hidden email]>:
>> >>
>> >> Le 08/10/2013 18:46, Benedikt Ritter a écrit :
>> >>
>> >>> What are the problems and how can we make releasing easier?
>> >>
>> >> I have a real example with JCI. I get an error when running the release
>> >> profile with "mvn package -DskipTests -Prelease" :
>> >>
>> >> [INFO] ----------------------------------------------------
>> >> [ERROR] BUILD ERROR
>> >> [INFO] ----------------------------------------------------
>> >> [INFO] Error assembling JAR
>> >>
>> >> Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
>> >> does not exist.
>> >>
>> >>
>> >> Any idea?
>> >>
>> >> Emmanuel Bourg
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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]
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Reply | Threaded
Open this post in threaded view
|

Re: [JCI] Problem with release profile

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-3
I made some progress but I still have an issue with 'mvn site', see
http://apaste.info/pOvS

Again, any idea is welcome.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Ralph Goers
In reply to this post by Christian Grobmeier
I wrote the Log4j2 wiki page just so I could remember and repeat the few manual steps I have to do for each release. The difficulty is getting the bugs out of the first release.  Log4j 2 still has some difficulties though around its build process primarily because none of us are OSGi experts and we know that what we are building isn't correct for that.  When you factor in trying to build stuff so that it works in Google App Engine, Android, various JDK versions and vendors then things start to become more difficult.  On that though, my attitude has always been to build and test for the environments I use and let people who work in other environments test and provide fixes for theirs, at least as much as possible.

However, the primary goal of a release is to have a source distribution that meets the legal obligations as stated by the ASF.  There is no requirement to build and ship binaries - we do that as a convenience for our users and because we know we will get lots of complaints if we don't.

Ralph

On Oct 8, 2013, at 11:44 AM, Christian Grobmeier wrote:

> On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
>
>> Hey Gary,
>>
>> you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]?
>
> Check this guide:
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> In fact we have an ASF maven pom:
> http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml
> This is extended by tons of plugins and other things and called "commons parent pom". The commons parent pom does a lot of things, and all components are more or less required to run the same way.
>
> The question is, why should a component not be independent from commons-parent-pom and decide on it's on? With having the ASF-parent only releasing could be:
>
> mvn release:prepare release:perform
>
> Then everything should be on Nexus.
>
> I know this is a controverse question. But as people can download the artifacts directly from nexus if they wish - including source, LICENSE, NOTICE and all that… why are we bothering to put on any other place?
> One could see at as: we release source code, as we create a tag. For convenience we put it on Nexus. Nothing else.
>
> For site: I think components should be free to chose on their own. I was thinking different in the past. But now I believe we should just have a front page listing our components like we have here:
> http://logging.apache.org
> …and that site should link to the appropriate sub component site. How it looks or works or how it is build should be decided by the component maintainers independently.
>
> Cheers
> Christian
>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <[hidden email]>:
>>>
>>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>>> directory; that THREE things to get just right, none are 100% automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>>
>>> Gary
>>>
>>>
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>>
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need all the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins instance?
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

Stefan Bodewig
In reply to this post by Benedikt Ritter-3
On 2013-10-08, Benedikt Ritter wrote:

> you are involved in other projects (like log4j2) how do they do it? Is
> it easier to release log4j2 than it is to release for example [lang]?

Over the past year I've cut releases at the ASF for Commons Compress,
Ant and log4net and outside of the ASF of a small company sponsored QMQP
library at github and XMLUnit at sourceforge.

The QMQP lib was trivial to release because I didn't have to vote,
didn't intend to have a proper distribution outside of MC and the only
site is the Readme.md.  This wouldn't be possible for anything
non-trivial.  Still there was a Nexus between my command line and Maven
central and it's been more than a single step.

All ASF releases and XMLUnit have been similar - it is always a painful
manual process.  Create a tag, build the stuff upload to Nexus (not for
log4net), upload non Maven-distributables, update site.  In XMLUnit I
can skip the votes, but I don't see how to make anything of this a lot
easier.

As long as we think we have to distribute things to three places and
vote on all of them, I don't see how to simplify things.  I must admit
I'm not sure we actually have to do that, we can change the site as
often as we want to, so why vote on it?  And we can trust our tooling,
why vote on Nexus staged artifacts if the tarball is fine?  I'm not
talking about releasing to MC directly but rather about not pushing
anything to Nexus before the vote on the tarball has passed.  This could
reduce the release process to tagging and publishing the tarballs before
the vote.

At work I've been cutting releases for stuff built from 15 git repos
every two weeks - at the end of scrum sprints.  We've automated things
so far that it is mostly down to tagging the repositories and the rest
is done by CI.

But there are things the build process doesn't do and that cannot be
automated for good reasons - PGP signing for example.  I wouldn't want
to put a private key on a CI machine, or rather I wouldn't trust a key
that lived on such a machine.

In addition I probably wouldn't trust the artifacts built on a public CI
machine that is open to as many people as our Jenkins either - it would
be a beautiful target for attacks and a great resource for publishing
backdoored releases if we were to rely on CI to build our releases.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: [JCI] Problem with release profile

Emmanuel Bourg-3
In reply to this post by sebb-2-2
Le 08/10/2013 21:25, sebb a écrit :

> Note: we must update Javadoc plugin to the latest version to ensure
> that the scripting bug is fixed.

Done

> I expect there are several parts of the main pom that can be removed
> as the parent pom defines all the common stuff that it can.

I cleaned up the pom as much as I could, but most reporting plugins
still have to be redeclared to specify the aggregate property.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?

sebb-2-2
In reply to this post by Stefan Bodewig
On 9 October 2013 05:43, Stefan Bodewig <[hidden email]> wrote:

> On 2013-10-08, Benedikt Ritter wrote:
>
>> you are involved in other projects (like log4j2) how do they do it? Is
>> it easier to release log4j2 than it is to release for example [lang]?
>
> Over the past year I've cut releases at the ASF for Commons Compress,
> Ant and log4net and outside of the ASF of a small company sponsored QMQP
> library at github and XMLUnit at sourceforge.
>
> The QMQP lib was trivial to release because I didn't have to vote,
> didn't intend to have a proper distribution outside of MC and the only
> site is the Readme.md.  This wouldn't be possible for anything
> non-trivial.  Still there was a Nexus between my command line and Maven
> central and it's been more than a single step.
>
> All ASF releases and XMLUnit have been similar - it is always a painful
> manual process.  Create a tag, build the stuff upload to Nexus (not for
> log4net), upload non Maven-distributables, update site.  In XMLUnit I
> can skip the votes, but I don't see how to make anything of this a lot
> easier.
>
> As long as we think we have to distribute things to three places and
> vote on all of them, I don't see how to simplify things.  I must admit
> I'm not sure we actually have to do that, we can change the site as
> often as we want to, so why vote on it?

I don't think we do vote on it; it's provided for convenience and for
people to review for obvious omissions.

> And we can trust our tooling,

Sorry, but that is not the case.
There are lots of ways that the build process can break.
I was assured categorically on the Maven dev list that their release
process was fool-proof.
Several releases were later found to have spurious files in the source bundles.

> why vote on Nexus staged artifacts if the tarball is fine?  I'm not
> talking about releasing to MC directly but rather about not pushing
> anything to Nexus before the vote on the tarball has passed.  This could
> reduce the release process to tagging and publishing the tarballs before
> the vote.

So where are you going to publish the tarballs?
At some point the tarballs are going to have to end up on Nexus
anyway, so why not use it?

> At work I've been cutting releases for stuff built from 15 git repos
> every two weeks - at the end of scrum sprints.  We've automated things
> so far that it is mostly down to tagging the repositories and the rest
> is done by CI.
>
> But there are things the build process doesn't do and that cannot be
> automated for good reasons - PGP signing for example.  I wouldn't want
> to put a private key on a CI machine, or rather I wouldn't trust a key
> that lived on such a machine.

ASF infra would not allow that.

> In addition I probably wouldn't trust the artifacts built on a public CI
> machine that is open to as many people as our Jenkins either - it would
> be a beautiful target for attacks and a great resource for publishing
> backdoored releases if we were to rely on CI to build our releases.

Indeed.

> 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: [JCI] Problem with release profile

sebb-2-2
In reply to this post by Emmanuel Bourg-3
On 9 October 2013 14:06, Emmanuel Bourg <[hidden email]> wrote:

> Le 08/10/2013 21:25, sebb a écrit :
>
>> Note: we must update Javadoc plugin to the latest version to ensure
>> that the scripting bug is fixed.
>
> Done
>
>> I expect there are several parts of the main pom that can be removed
>> as the parent pom defines all the common stuff that it can.
>
> I cleaned up the pom as much as I could, but most reporting plugins
> still have to be redeclared to specify the aggregate property.

Maybe there's some way that could be added to the parent pom?
Perhaps via a property that defaults to an appropriate setting for
components that _don't_ have modules (the most common case in
Commons).

> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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]

12