ToDos for M4

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

ToDos for M4

ammulder
OK, I've finished the following:
 - fix the deployer to not echo your password
 - fix the deployer to not be totally silent
 - give the deployer a custom message for the case where RuntimeDeployer
   is not deployed
 - make sure exceptions propogate to the deploy tool well
 - fix problem where var/config/config.list is never updated

The main other thing I really want to get into M4 is:
 - get a release of ActiveMQ more recent than 7/8 (so our port list will
   show the ActiveMQ port)

And "would be nice but don't plan to do this myself":
 - have a sample web app set as the default so localhost:8080 doesn't 404
 - add a shutdown JAR, or management JAR with shutdown implemented
 - have startup/shutdown/deploy scripts
 - provide a bundled or linked MC4J release

But just to reiterate, I'm fine with branching now.

Thanks,
        Aaron

On Thu, 7 Jul 2005, David Blevins wrote:

> Alright, it's been a few days since this was proposed, going to move forward as there didn't seem to be any objections.  
>
>   (As a note to people who really want to get
>    features in before we release; good!  Let's
>    release again very very soon!)
>
>
> If you are in the middle of something, get to the end of it quick :)
>
> If you were thinking of starting something big, wait till tomorrow at this time.
>
> If you would prefer  we delay creating the branch a day or two (and have good reason for holding up the show), speak up.
>
> -David
>
Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

mos-2
Just some thoughts:

Shouldn't well known and essential bugs be fixed before doing the branch?
This could prevent duplicated work.
For example: http://issues.apache.org/jira/browse/GERONIMO-715

Bye the way:
Would the subprojects like OpenEJB be part of the branch of M4?
I assume this because this modules are an essential part of geronimo
and have to be closely synchronized with the rest.

Greetings
mos


On 7/10/05, Aaron Mulder <[hidden email]> wrote:

> OK, I've finished the following:
>  - fix the deployer to not echo your password
>  - fix the deployer to not be totally silent
>  - give the deployer a custom message for the case where RuntimeDeployer
>   is not deployed
>  - make sure exceptions propogate to the deploy tool well
>  - fix problem where var/config/config.list is never updated
>
> The main other thing I really want to get into M4 is:
>  - get a release of ActiveMQ more recent than 7/8 (so our port list will
>   show the ActiveMQ port)
>
> And "would be nice but don't plan to do this myself":
>  - have a sample web app set as the default so localhost:8080 doesn't 404
>  - add a shutdown JAR, or management JAR with shutdown implemented
>  - have startup/shutdown/deploy scripts
>  - provide a bundled or linked MC4J release
>
> But just to reiterate, I'm fine with branching now.
>
> Thanks,
>        Aaron
>
> On Thu, 7 Jul 2005, David Blevins wrote:
> > Alright, it's been a few days since this was proposed, going to move forward as there didn't seem to be any objections.
> >
> >   (As a note to people who really want to get
> >    features in before we release; good!  Let's
> >    release again very very soon!)
> >
> >
> > If you are in the middle of something, get to the end of it quick :)
> >
> > If you were thinking of starting something big, wait till tomorrow at this time.
> >
> > If you would prefer  we delay creating the branch a day or two (and have good reason for holding up the show), speak up.
> >
> > -David
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

Hiram Chirino
In reply to this post by ammulder
Hi Aaron,

ActiveMQ has pushed out new SNAPSHOT now so the port list stuff is in  
there now.  We are planning on doing a M4 release of ActiveMQ as soon  
as we fix a few tck regressions that occurred recently.  Once we do  
that I'll update the geronimo M4 branch to use the released version.

Regards,
Hiram


On Jul 10, 2005, at 2:29 AM, Aaron Mulder wrote:

> OK, I've finished the following:
>  - fix the deployer to not echo your password
>  - fix the deployer to not be totally silent
>  - give the deployer a custom message for the case where  
> RuntimeDeployer
>    is not deployed
>  - make sure exceptions propogate to the deploy tool well
>  - fix problem where var/config/config.list is never updated
>
> The main other thing I really want to get into M4 is:
>  - get a release of ActiveMQ more recent than 7/8 (so our port list  
> will
>    show the ActiveMQ port)
>
> And "would be nice but don't plan to do this myself":
>  - have a sample web app set as the default so localhost:8080  
> doesn't 404
>  - add a shutdown JAR, or management JAR with shutdown implemented
>  - have startup/shutdown/deploy scripts
>  - provide a bundled or linked MC4J release
>
> But just to reiterate, I'm fine with branching now.
>
> Thanks,
>     Aaron
>
> On Thu, 7 Jul 2005, David Blevins wrote:
>
>> Alright, it's been a few days since this was proposed, going to  
>> move forward as there didn't seem to be any objections.
>>
>>   (As a note to people who really want to get
>>    features in before we release; good!  Let's
>>    release again very very soon!)
>>
>>
>> If you are in the middle of something, get to the end of it quick :)
>>
>> If you were thinking of starting something big, wait till tomorrow  
>> at this time.
>>
>> If you would prefer  we delay creating the branch a day or two  
>> (and have good reason for holding up the show), speak up.
>>
>> -David
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

Alan Cabrera-2
In reply to this post by mos-2

On Jul 10, 2005, at 4:42 AM, mos wrote:

> Just some thoughts:
>
> Shouldn't well known and essential bugs be fixed before doing the
> branch?
> This could prevent duplicated work.
> For example: http://issues.apache.org/jira/browse/GERONIMO-715

I think that we should update the M4 roadmap to reflect what we really
think is needed before we kick this out the door, i.e. branch.  There
are things in there that I'm not sure that we'll complete in the
timeframe that we want for M4.

There are also things like 715 that people want to go out for M4.

> Bye the way:
> Would the subprojects like OpenEJB be part of the branch of M4?
> I assume this because this modules are an essential part of geronimo
> and have to be closely synchronized with the rest.
>

OpenEJB is not a sub-project of Geronimo. However, we should use a
specific version of OpenEJB in our M4 branch.  What I think that what
could be done is that we could build a snapshot of OpenEJB and label
the version w/ a timestamp.  We would then upload the jar into a maven
repo, preferably ibiblio.


Regards,
Alan

Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

sissonj

"Alan D. Cabrera" <[hidden email]> wrote on 11/07/2005 12:02:55 PM:

>
> On Jul 10, 2005, at 4:42 AM, mos wrote:
>
> > Just some thoughts:
> >
> > Shouldn't well known and essential bugs be fixed before doing the
> > branch?
> > This could prevent duplicated work.
> > For example: http://issues.apache.org/jira/browse/GERONIMO-715
>
> I think that we should update the M4 roadmap to reflect what we really
> think is needed before we kick this out the door, i.e. branch.  There
> are things in there that I'm not sure that we'll complete in the
> timeframe that we want for M4.
>
> There are also things like 715 that people want to go out for M4.
>
> > Bye the way:
> > Would the subprojects like OpenEJB be part of the branch of M4?
> > I assume this because this modules are an essential part of geronimo
> > and have to be closely synchronized with the rest.
> >
>
> OpenEJB is not a sub-project of Geronimo. However, we should use a
> specific version of OpenEJB in our M4 branch.  What I think that what
> could be done is that we could build a snapshot of OpenEJB and label
> the version w/ a timestamp.  We would then upload the jar into a maven
> repo, preferably ibiblio.


+1.

Can we do this with all our SNAPSHOT dependencies so the build is truly reproducable?  Looking at etc/project.properties we have approx 18 SNAPSHOTs in use.  How would we upload JARS of all these SNAPSHOTs of external projects (e.g. what maven groupId will they be under, will it be under geronimo)?

It would be nice if in the future developers could document why we need to use each SNAPSHOT, e.g. some comments above each SNAPSHOT in etc/project.properties.  This would help give everyone a better picture of the reason for and state of our dependencies.

John

>
>
> Regards,
> Alan
>


This e-mail message and any attachments may contain confidential, proprietary or non-public information.  This information is intended solely for the designated recipient(s).  If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail.  Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited.  Any opinions expressed in this e-mail are those of the author personally.

Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

David Blevins
On Mon, Jul 11, 2005 at 01:34:43PM +1100, [hidden email] wrote:
>
>    It would be nice if in the future developers could document why we need to
>    use each SNAPSHOT, e.g. some comments above each SNAPSHOT in
>    etc/project.properties.  This would help give everyone a better picture of
>    the reason for and state of our dependencies.

Super-dooper, mega, ginormous +1,000,000

-David
Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

Geir Magnusson Jr.
In reply to this post by Alan Cabrera-2

On Jul 10, 2005, at 10:02 PM, Alan D. Cabrera wrote:

>
> On Jul 10, 2005, at 4:42 AM, mos wrote:
>
>
>> Just some thoughts:
>>
>> Shouldn't well known and essential bugs be fixed before doing the  
>> branch?
>> This could prevent duplicated work.
>> For example: http://issues.apache.org/jira/browse/GERONIMO-715
>>
>
> I think that we should update the M4 roadmap to reflect what we  
> really think is needed before we kick this out the door, i.e.  
> branch.  There are things in there that I'm not sure that we'll  
> complete in the timeframe that we want for M4.
>
> There are also things like 715 that people want to go out for M4.

Well, how about doing a more formal M5 very soon with a clearer roadmap?

>
>
>> Bye the way:
>> Would the subprojects like OpenEJB be part of the branch of M4?
>> I assume this because this modules are an essential part of geronimo
>> and have to be closely synchronized with the rest.
>>
>>
>
> OpenEJB is not a sub-project of Geronimo. However, we should use a  
> specific version of OpenEJB in our M4 branch.

+1

> What I think that what could be done is that we could build a  
> snapshot of OpenEJB and label the version w/ a timestamp.  We would  
> then upload the jar into a maven repo, preferably ibiblio.

I assume "we" == "OpenEJB people at OpenEJB project"?  "we" ==  
"Geronimo project" shouldn't be doing releases on behalf of other  
projects, but I don't think you meant that.

geir


--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ToDos for M4

Jacek Laskowski-5
In reply to this post by David Blevins
David Blevins wrote:
> On Mon, Jul 11, 2005 at 01:34:43PM +1100, [hidden email] wrote:
>
>>   It would be nice if in the future developers could document why we need to
>>   use each SNAPSHOT, e.g. some comments above each SNAPSHOT in
>>   etc/project.properties.  This would help give everyone a better picture of
>>   the reason for and state of our dependencies.
>
>
> Super-dooper, mega, ginormous +1,000,000

Although it isn't that +1000000, but +1000 from me, too. I haven't ever
thought about it before. That's a very good question why Geronimo relies
on so many SNAPSHOTs. Aren't they a sign we depend on an unsable ground?
I've seen at least one project, where a major bug fix leads to a new
release (cf. Mevenide). I like it so we could decide that all of our
SNAPSHOTs should be reverted to their latest official releases and when
there's anything in a SNAPSHOT we really need, we could gently ask its
community to release a new version. I think it greatly improves the
quality of the whole software stack. I like it!

> -David

Jacek