Just a question: are you keeping good notes as to what you're
doing? I'd like for the details of the process to end up on a wiki
page if they are not already there. After reading these messages I
have no clue what you are doing :-)
Greg
On Dec 19, 2006, at 7:49 PM, Rahul Akolkar
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote:
Just a question: are you keeping good notes as to what you're
doing? I'd like for the details of the process to end up on a wiki
page if they are not already there. After reading these messages I
have no clue what you are doing :-)
snip/
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
snip/
OK, if everyone's fine with that, I will create the 1.0 branch (called
SHALE_1_0_x unless there are better suggestions) when we get closer to
the release (after all 1.0.4-SNAP
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote:
On Dec 20, 2006, at 2:01 PM, Rahul Akolkar wrote:
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I would have a mild preference for naming the branch SHALE_1_0 but
I'm not
going to choke if we go with what you proposed either. I'm
On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote:
* Since the trunk is being continuously built by Continuum,
trying to do our release cutting there (including removing
SNAPSHOT from the version numbers) would cause Continuum
to publish a release, with the real version number, before
we
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote:
On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote:
* Since the trunk is being continuously built by Continuum,
trying to do our release cutting there (including removing
SNAPSHOT from the version numbers) would cause Continuum
to
On Dec 20, 2006, at 7:54 PM, Wendy Smoak wrote:
On 12/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote:
So the first thing we'd do when we decide to release is - after
finishing up business - start a branch for the release. Then we
work
On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
Sounds like reasonable things to do :-) We even have a staging repo
defined in the master pom (thanks Wendy) which we should use for this.
By default if the version doesn't end in -SNAPSHOT,
On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
Sounds like reasonable things to do :-) We even have a staging repo
defined in the master pom (thanks Wendy) which we should use for
On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
Sounds like reasonable things to do :-) We even have a staging repo
defined in the master pom (thanks Wendy) which we should use for this.
By default if the version doesn't end in -SNAPSHOT, the artifacts will
end up in
On 12/15/06, Craig McClanahan [EMAIL PROTECTED] wrote:
snip/
Re: you guys tag teaming on RM for Shale ... +1! :-). The wiki has a
bunch of notes (mostly from Wendy) that I basically followed last time. A
couple of things to watch out for:
* The shale-master pom should be upversioned and
On 12/13/06, Greg Reddin [EMAIL PROTECTED] wrote:
My project at work is finally in a place where we really need to use
Shale :-) The 1.0.3 release does not work out of the box for us
because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces
1.1.1. Shale 1.0.4-SNAPSHOT does not. So
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote:
In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this
weekend once I'm done traveling -- that leaves us with SHALE-61. I
dropped the ball on that, and ATM I don't think there is any concrete
proposal towards it.
It looks like
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote:
In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this
weekend once I'm done traveling -- that leaves us with SHALE-61.
... also SHALE-211 [1]. I'm guessing we can close that one. Any
objections?
Greg
[1]
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote:
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote:
In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this
weekend once I'm done traveling -- that leaves us with SHALE-61. I
dropped the ball on that, and ATM I don't think there
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote:
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote:
In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this
weekend once I'm done traveling -- that leaves us with SHALE-61.
... also SHALE-211 [1]. I'm guessing we can close that
On Dec 15, 2006, at 11:10 AM, Rahul Akolkar wrote:
... also SHALE-211 [1]. I'm guessing we can close that one. Any
objections?
snip/
Resolve it, at worst it will get re-opened. Its shouldn't affect the
release anyway, IMO.
Done :-)
Greg
On Dec 14, 2006, at 3:42 AM, Craig McClanahan wrote:
It's just what the POM says, but I don't know how to override it. In
1.1.1 MyFaces used the myfaces groupId and now they use
org.apache.myfaces. Because of this Maven doesn't know that my
dependency on MyFaces 1.1.5 should override Shale's
On 12/14/06, Greg Reddin [EMAIL PROTECTED] wrote:
shale-master.pom - This is the base POM for the whole project. It
inherits from an org.apache parent. We only have to release a new
version of this if the information contained in it changes, right
(i.e. add new committer, mailing list, svn
On Dec 14, 2006, at 8:53 AM, Niall Pemberton wrote:
As the shale-tiles module has no dependency on the rest of shale and
can be used in a vanilla JSF environment wouldn't it make more sense
to move this to the proposed Tiles project? I think the argument for
having JSF support in Tiles is
On Dec 14, 2006, at 9:22 AM, Wendy Smoak wrote:
Yes, shale-master is released independently. It has to be released in
advance of the framework so we don't have a snapshot as a parent.
Oh, I see. When I first looked at it I couldn't find a version number.
shale-parent.pom - The base POM
On 12/14/06, Greg Reddin [EMAIL PROTECTED] wrote:
On Dec 14, 2006, at 9:22 AM, Wendy Smoak wrote:
Whether to release the framework together or in pieces is just
something we need to decide, figure out how to communicate to users,
and then adjust the build to match.
Sounds like that
On Dec 14, 2006, at 10:43 AM, Wendy Smoak wrote:
For the record, I'm for together. While there are some good
arguments for releasing components individually, and it might even be
easier from a technical standpoint, I think we'll have problems
explaining it to users. (I remember not wanting
On 12/13/06, Greg Reddin [EMAIL PROTECTED] wrote:
My project at work is finally in a place where we really need to use
Shale :-)
That's great!
The 1.0.3 release does not work out of the box for us
because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces
1.1.1.
Is it
24 matches
Mail list logo
