Re: Release preparation

2007-07-20 Thread Guillaume Nodet

I'd like to but i'o in holidays too. I may be able to help in a few weeks.

On 7/20/07, Marcel Offermans [EMAIL PROTECTED] wrote:

On Jul 20, 2007, at 19:34 , Carsten Ziegeler wrote:

 We could also use the maven release plugin to do all the work for us.

I agree, automating the whole release process is something that
should be on our list for the next release. Karl has just gone on
holiday for a couple of weeks, but perhaps you can have a look at the
changes we need to make and come up with a patch?

Greetings, Marcel





--
Cheers,
Guillaume Nodet

Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/


[jira] Updated: (FELIX-329) Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes thread

2007-07-20 Thread Toni Menzel (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Toni Menzel updated FELIX-329:
--

Summary: Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes 
thread  (was: Calling Felix.stopAndWait() from Runtime.shutdownHook() freezed 
thread)

 Calling Felix.stopAndWait() from Runtime.shutdownHook() freezes thread
 --

 Key: FELIX-329
 URL: https://issues.apache.org/jira/browse/FELIX-329
 Project: Felix
  Issue Type: Bug
  Components: Framework
 Environment: tested on trunk (r555374)
Reporter: Toni Menzel
 Fix For: 1.0.0


 if a shutdownHook invokes Felix.stopAndWait() the monitor never gets notified 
 and stays wait() forever.
 Until now i haven't found a direct way to fix this behaviour normally but 
 if we could use the timeout version wait(int) instead of wait() this 
 behaviour is not tied to the monitor.notifyAll() functionality. (so perhaps 
 its the better solution anyway and not just a workaround?)
 Toni

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Release preparation

2007-07-20 Thread Niclas Hedhman
On Saturday 21 July 2007 01:34, Carsten Ziegeler wrote:

 We could also use the maven release plugin to do all the work for us.
 Together with the gpg plugin it creates all necessary artifacts, signs
 them etc.

Yes, releasing large number of Maven artifacts without the help of the release 
plugin is pain in many unspoken places...

However, AFAIK, the release plugin does not support a staging, release 
candidate or similar repo, so that one can publish to the non-official final 
destination, for review and votes. And we can't upload until after the vote.

But I would be interested to learn how to leverage the release plugin. Below 
is an explanation of what I would have in mind.

1. Each maven artifact extends a parent named org.apache.felix:candidate.

2. That parent defines all the upload locations to some staging area on 
people.apache.org, and tagging the sources into a similar area in SVN.

3. One executes a mvn release:prepare/perform on TRUNK, and things is made 
available for review.

4. The vote is executed.

5. If it passes, one modifies the candidate branch in SVN and replaces 
the candidate parent to a org.apache.felix:final pom.

6. That pom has the tagging and uploading set to the final resting place in 
both SVN, artifacts uploads, tar ball uploads and documentation (if any).


WDYT?

In fact, this is of strong interest to the entire ASF, and I would like to 
hear from Carlos how Maven itself does it, since they have this problem at a 
grand scale.



Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug