You should have karma now. If you don't email me.
Thanks a bunch, will try out tonight.
I think so too. Do you happen to know if the POMs on the remote repository retained the property notation, or actually had the expanded value? We have written a tool for Keel, and I just read the Maven-2 will automatically do this also, to do transitive dependency checks (i.e. look at first-level dependencies in project.xml, then retrieve POMs for those, look at those dependencies and so on and so forth)....it won't work if the POMs don't have the version-numbers.Given the number of modules, it'd be nice if I/we didn't have to go change
all the plugin.xml-s for the currentVersion and then everything else to
depend on the changed version numbes for every RC and then the release
cycle. Any ideas? One thought was to change the hard-coded version numbers
to Maven properties, and then define all the versions in build.properties in
excalibur-trunk (i.e have one file to control everything). The problem is I
don't know how the POM will look when deployed to a remote Maven repo.
We had a similar setup over in Avalon which Niclas and Steve worked on. It would be a lot easier to have all the version numbers in one place.
I haven't tagged in svn yet, I'll setup a sandbox to try it out. However, I started reading up on it yesterday, and the first thing I learnt was that tagging isn't quite like in CVS (or, like Clearcase "label"s); instead the "trunk" needs to be copied to a "branch" or "tag" directory as appropriate. I saw recommendations that each project have it's own trunk, and branch/tag dirs). It is really sub-project in our case, considering Excalibur is the project and our "trunk" is at Excalibur level. I am wondering if our svn structure is really suited to the sub-project level releases, and tagging, we want to do? Somebody help me out here....this is not a rhetorical question :-).I am assuming I do. Unless someone tells me
how to do this easily for all the modules, I think I am going to write
something in Jelly for Maven to allow use of the multiproject plugin, derive
a tag from currentVersion and apply the tag (doesn't look like Maven's scm,
repository, release plugins do what we need).
You could tag the whole 'trunk' but tagging individual component directories would be much better.
We could tag the entire repo for each sub-project release and tag, but that seems sheer overkill to me. Since we haven't tagged yet, this might be a good time to rearrange the repo as we need, once and for all.
I hadn't thought about buildsystem actually. Take cornerstone for example. there is a trunk/cornerstone/project-common.xml, that defines the currentVersion as "1.2". In this case all the cornerstone components are actuall being released as 1.2, so no problem. Let's say we make a bug fix to sockets-impl...making it 1.2.1. When we release sockets-1.2.1, do we also tag the parent directory and project-common.xml? But, changing project-common.xml makes *all* components go to 1.2.1.BTW, project-common.xml is
evil for this purpose....need to tag the parent dir even though only a
nested dir/project is being released.
You want to include the 'buildsystem' directory in each tag? One layout I suppose would be:
/tags
/${artifact}-${version}
/buildsystem
/[actual source directories here]
Is this what you were envisioning?
Same for Fortress....everything is 1.2, so if you fix Fortress-platform, you need to release all Fortress JARs. Same with instrumentation, there are others too.
I propose doing away with project-common.xml(s), and let each project stands completely on it's own. In any case, most project-common.xml(s) have very little content anyway, there's not much we'll be duplicating.
Shash
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
