"Alan D. Cabrera" <[EMAIL PROTECTED]> 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 via email to