ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/SDOJavaReleaseSteps" by KelvinGoodson
Date Mon, 02 Oct 2006 13:07:21 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by KelvinGoodson:

  	<jboynes>	so you should only need to change that once
+ === And another ===
+ {{{
+ 	<kgoodson>	jboynes, you were looking for me yesterday evening
+ 	<jboynes>	yeah
+ 	<jboynes>	was going to ping you on upgrading EMF
+ 	<jboynes>	I went and did it anyway :)
+ 	<kgoodson>	ok, great, i saw your tuscany-dev note and responded, but didn't see the
IRC ping
+ 	<jboynes>	I didn't make the change in the branch
+ 	<kgoodson>	ok, i can do that
+ 	<jboynes>	we also need to tag das for lresende
+ 	<jboynes>	what do you think about the samples?
+ 	<kgoodson>	so to check, we are tagging now, yes? So if a tag is pretty imutable,
how do we deal with comments on the release?
+ 	<kgoodson>	in what way? (samples)
+ 	<jboynes>	should we move them?
+ 	<jboynes>	it's really an issue for the list
+ 	<kgoodson>	i think moving could be good, but i'm not sure of the risks (e.g. documentation
that has http://svn style links into the repository. And to make one tree we would also have
to move the spec/sdo to sdo/spec
+ 	<jboynes>	re spec, IMO that should be separate
+ 	<jboynes>	at least, that's the case for SCA
+ 	<kgoodson>	ok, so i'm not sure of the value of moving anything unless we move everything,
becuase the main motivation for me is to remove the manual steps from creating the source
distribution branch/tag
+ 	<kgoodson>	i got feedback from the user list that one source distro was wanted, with
spec and impl together
+ 	<jboynes>	that's what I mean - are the spec's part of the Tuscany distro
+ 	<kgoodson>	we'll we kind of ship our own third party dependency, but when I cut RC1
is caused confusion, creating two archives
+ 	<kgoodson>	s/we'll/well/
+ 	<jboynes>	what was the confusion?
+ 	<jboynes>	as in, it seems to make sense to me - one spec, one impl
+ 	<kgoodson>	so one user doth not a straw poll make, but I can see the point that because
these two archives come from the same project its kind of off to see the source split into
+ 	<jboynes>	the spec an be used by many people
+ 	<kgoodson>	ok, i think it was possily the number of files in one directory .....
zip&tgz + asc + md5 for binary, spec and impl gives 18 files
+ 	<jboynes>	:) that's why m2 repos have a directory heirarchy
+ 	<kgoodson>	when i combined the source distros for RC1a it certainly looked clearer
+ 	<kgoodson>	ok, so if you feel stronly that we should have two source distros, i can
do that, and i will explain to the user list why we have not picked up on the suggestion of
having one source distro -- then that makes moving samples a useful task
+ 	<jboynes>	well, jboynes does not a straw poll make either ;)
+ 	<jboynes>	I come from JCP land where there is a strong isolation between spec and
+ 	<jboynes>	so that would shape my perspective on things
+ 	<jboynes>	but SDO does not have the same history
+ 	<jboynes>	e.g. it used to be you /had/ to ship spec api and impl in the same jar
+ 	<kgoodson>	ok, help me, I believe in spec & impl separation too, but I can see
that sdo/spec and sdo/impl separates the two
+ 	<jboynes>	ok
+ 	<jboynes>	my Q is on what you want to tag
+ 	<jboynes>	tag == release content
+ 	<jboynes>	i thought we were thinking of moving samples/sdo to sdo/samples so that
we can tag just by copying the sdo parent directory
+ 	<kgoodson>	i had imaged that we work on the branch until we are happy and then tag
the branch, but in the branch hierarchy i have replicated the structure of the overall project,
e.g. spec/sdo samples/sdo
+ 	<jboynes>	which would tag imp, plugins, tools and samples all at the same time
+ 	|<--	isilval_ has left ("Trillian (")
+ 	<kgoodson>	that would be a step in the right direction, to be hones i'm easy, and
I don't know what the right thing to do is, if there is a right thing to do
+ 	<jboynes>	I'm not sure what you mean by "right thing to do"
+ 	<kgoodson>	best practice, i guess
+ 	<jboynes>	there are things you can do to make things easier
+ 	<kgoodson>	i have not been involved in projects that do source distros before
+ 	<jboynes>	ok
+ 	<cr22rc>	rfeng been around any?
+ 	<kgoodson>	haven't seen him
+ 	<kgoodson>	jboynes, you said "there are things you can do to make things easier"
-- what did you mean, can you elaborate?
+ 	<jboynes>	so "best practice" is that a release is a "known good" version of the development
+ 	<jboynes>	"known good" = stable, rebuildable, less buggy, whatever criteria you apply
+ 	<kgoodson>	sure, i think we have that
+ 	<jboynes>	yeah
+ 	<jboynes>	except we don't really have a build that does just SDO
+ 	<jboynes>	it's a mix & match thing
+ 	<jboynes>	so the "rebuildable" it is not quite there
+ 	<kgoodson>	so if we get to the state that we have a build for SDO spec and one for
SDO impl (incl samples) then thats ideal
+ 	<jboynes>	ok
+ 	<jboynes>	I believe the spec build is standalone
+ 	<kgoodson>	good, then lets do that
+ 	<jboynes>	and also the sdo impl (sans samples)
+ 	<jboynes>	so we can get to that by moving the samples under sdo impl
+ 	<kgoodson>	ok, you've convinced me
+ 	<jboynes>	under sdo, not under sdo/impl :)
+ 	<jboynes>	I think we'd also move dist/sdo to sdo/dist
+ 	<kgoodson>	indeed, i was using impl in a slightly loose way, that meant impl + tools
+ plugins -- i.e. all our implementation related stuff
+ 	<kgoodson>	yes that would be very good
+ 	<jboynes>	me too (just thought I wasn't being clear)
+ 	<kgoodson>	but theres still the issue of the STATUS file
+ 	<jboynes>	:)
+ 	<jboynes>	yeah
+ 	<kgoodson>	i wonder if we had a subproject for that kind of stuff that each other
sub project depenmded on
+ 	<kgoodson>	could that work?
+ 	<kgoodson>	is that overkill?
+ 	<jboynes>	it's more the convention of how to lay out a ASF project
+ 	<jboynes>	project being all of tuscany
+ 	<jboynes>	and many projects don't include their STATUS file
+ 	<jboynes>	I happen to think that incubator projects should
+ 	<kgoodson>	its in the draft guidelines IIRC
+ 	<jboynes>	as i think community status is an important aspect of incubating projects
+ 	<kgoodson>	hmm, so if we cant do some kind of symbolic link trickery then I think
we are into manual copying, and all the maintenance issues associated
+ 	<jboynes>	well, we know symlinks don't work on windows
+ 	<jboynes>	how about if we have a manual step to copy the status file when we tag
+ 	<jboynes>	actually, we would /need/ to do that
+ 	<jboynes>	yeah
+ 	<jboynes>	so, we make whoever cuts the tag responsible for copying the STATUS file
from the root into the tag
+ 	<kgoodson>	in the absence of any advanced techinal trick for sharing that fle then
i think that's our only option
+ 	<kgoodson>	ok
+ 	<jboynes>	ok
+ 	<kgoodson>	so we should have a release policy in place i think, so this could be
a material part of that
+ 	<jboynes>	yes
+ 	<jboynes>	+1
+ 	<kgoodson>	i had started collecting info on the wiki
+ 	<kgoodson>	so i will make sure this is at least recorded there, and then plan to
sanitize it later
+ 	<jboynes>	as an aside, I like what robert did on the proposal guidelines for the
+ 	<jboynes>	guideline + reasoning + examples
+ 	<kgoodson>	i have looked at lots of docs recently, so i'm not sure exactyly which
doc you are talking about
+ 	<kgoodson>	is that the http://*****/releasemanagement link
+ 	<kgoodson>	?
+ 	<jboynes>
+ 	<jboynes>	(sorry, went looking)
+ 	<jboynes>	in the templatebit
+ 	<kgoodson>	ok, i'll take a look, so did you mention that as a suggestion for the
format of the release policy?
+ 	<kgoodson>	yes, on first scan that looks like a useful doc
+ 	<jboynes>	yes
+ 	<jboynes>	I think "why" is important :)
+ 	<kgoodson>	"yes" to usefulness, or proposal for format? on the "why" issue, I couldn't
agree more
+ 	<jboynes>	I liked the way in this document robert was able to mix guideline with
"why" with an example of "how"
+ 	<jboynes>	a reference on style (not content)
+ 	<kgoodson>	right, i'll put the proposal element on the wiki, with a link to this
doc as a style suggestion
+ 	<jboynes>	thanks
+ 	<jboynes>	where were we? :)
+ 	<jboynes>	ok, tag by copying "sdo"
+ 	<jboynes>	includes impl etc. and samples
+ 	<jboynes>	and then copy in STATUS
+ 	<kgoodson>	yes
+ 	<jboynes>	tag spec/sdo in the same way
+ 	<jboynes>	also the parent pom and the buildtools
+ 	<kgoodson>	so i'll need to rearrange my branch to match the trunk
+ 	<jboynes>	rm & recopy?
+ 	<kgoodson>	as to the parent pom, i was planning to digest a fair chunk of the free
maven book this weekend and become a power maven user, but alas that didnt work out
+ 	<jboynes>	:)
+ 	<jboynes>	anything I can help with (as I set that up) ?
+ 	<kgoodson>	theres been no change in the samples trunk so i can rm and recopy, yes
+ 	<jboynes>	I was thinking the whole thing
+ 	<jboynes>	would be easy (but assumes nothing really changed in trunk(
+ 	<kgoodson>	well, i can't recall exactly what my issue was wehn i had to stop on friday
night, but my branch was not building correctly, because of something to do with the parent
+ 	<jboynes>	ok
+ 	<kgoodson>	in the branch, after having copied in the samples stuff and tried to build
from distributuion/sdo i was getting ...
+ 	<kgoodson>	[INFO] ---------------------------------------------------------------------
+ [INFO] ---------------------------------------------------------------------
+ [INFO] Error building POM (may not be this project's POM).
+ Project ID: org.apache.tuscany.samples.sdo:sample-sdo:jar:1.0-incubator-M2-S
+ Reason: Cannot find parent: org.apache.tuscany.samples:parent for project: o
+ incubator-M2-SNAPSHOT
+ [INFO] ---------------------------------------------------------------------
+ [INFO] For more information, run Maven with the -e switch
+ [INFO] ---------------------------------------------------------------------
+ [INFO] Total time: 26 seconds
+ [INFO] Finished at: Fri Sep 29 17:29:43 BST 2006
+ [INFO] Final Memory: 8M/23M
+ [INFO] ---------------------------------------------------------------------
+ C:\Development\Tortoise\distroTest3\branches\sdo-java-M2\distribution\sdo>
+ 	<kgoodson>	so i figured i had to go play with the parent pom
+ 	<jboynes>	I can see that
+ 	<jboynes>	I think it will go away if we move samples under sdo
+ 	<jboynes>	currently the parent for samples/sdo is the pom in samples
+ 	<jboynes>	so that would need to be released or tagged as wel
+ 	<jboynes>	if we move the samples, then the parent would be the pom in "sdo"
+ 	<kgoodson>	ok, sounds good, i wan't planning on attacking that for a few hours as
i have domestic duties here before bedtime --- can this wait until the morning, or is it something
you could readily do?
+ 	<kgoodson>	don't get me wrong, i'm happy to do this stuff, but I'm feeling a little
rough round the edges at the moment
+ 	<jboynes>	i can do, can you drop a note to the list so everyone knows what's going
on ?
+ 	<kgoodson>	will do
+ 	<jboynes>	I have 8 hours on you :)
+ 	<kgoodson>	:-)
+ 	<jboynes>	and haven't started drinking yet
+ 	<jboynes>	(it's football day - 49ers just lost 41-0)
+ 	<kgoodson>	ah, its been a rugby day here, both offspring won their matches, but torrential
rain didn't make it the best of days for spectating :-(
+ 	<jboynes>	:)
+ 	<jboynes>	up for one more question?
+ 	<kgoodson>	sure
+ 	<jboynes>	in the binary distro, what do you want the samples to look like?
+ 	<kgoodson>	hmmm, good point
+ 	<kgoodson>	i guess its usual to copy the source of the samples into a binary distro
+ 	<kgoodson>	i cant recall exactly waht it looks like at the mo, i could take a look
+ 	<jboynes>	ok
+ 	<jboynes>	ok, I'll just move what's there around
+ 	<jboynes>	thanks
+ 	<kgoodson>	thank you
+ 	=-=	YOU are now known as kgoodson_away
+ 	[INFO]	You are now marked as away (User is away.). Click the nickname button or use the
|/back| command to return from being away.
+ }}}

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message