scratch that. I'm working thru this: http://maven.apache.org/developers/release/apache-release.html as there's several steps I haven't done.
On 2 March 2010 16:17, Jeremy Hughes <[email protected]> wrote: > On 2 March 2010 02:28, David Jencks <[email protected]> wrote: >> I've done most of what I think is needed for aries to be basically >> releasable. There are some bits left and possibly stuff I've missed. >> >> 1. legal file review. There are a bunch of NOTICE files that claim that >> work from osgi is included. Really? license and notice files are supposed >> to apply to what is actually in an artifact or checkout. Are some of our >> source files copied from an osgi source? Also all the legal files that end >> up in binary artifacts need to be checked. Also we need to run the rat >> plugin: this should be configured in the default pom. Not sure if I will >> get to this. >> >> 2. actually using the eba-maven-plugn. I'm not entirely sure how to make >> sure that an eba is working so I didn't mess with this. I think the plugin >> itself is working well enough to use though. >> >> 2. ordering dependencies and dependency management. I find it convenient to >> have these alphabetized so I can find what I'm looking for, but I haven't >> done this in most poms. I'm not sure why there isn't a usable tool for >> doing this but I haven't found one. Dull but useful... >> >> 3. It would probably be a really good idea to run mvn dependency:analyze and >> look carefully at the results. The results from this can require >> interpretation so its best if someone who is very familiar with how the code >> works does this. >> >> 4. before a release all snapshots need to be resolved to released versions. >> I don't know if there are any snapshots. >> >> To summarize what I've tried to do: >> >> 1. default-parent has dependency management for the basic osgi dependencies >> that all projects are pretty sure to use including the pax stuff used mostly >> for testing. >> >> 2. each subproject has legal files in its checkout root >> >> 3. each subproject has an scm element in its pom, but no others do. >> >> 4. each subproject has dependency management for everything included in it. >> In addition, it has its subprojects listed in dependency management. (this >> is bent slightly for the samples). This means that >> (a) modules in a subproject don't need to include versions for use of other >> modules >> (b) you can get dependency management for all the modules in a subproject >> by depending on the subproject pom with scope import. (see the samples pom >> for an example). >> >> 5. As a result of (4), modules don't have any versions in any dependency >> elements. >> >> Release is going to involve... >> >> releasing the parent > > In trunk/parent I tried: > > mvn -DdryRun=true release:prepare -Papache-release > > Providing 0.1-incubating for the release version > Defaulting to parent-0.1-incubating for the SCM release tag > Defaulting to 0.2-incubating-SNAPSHOT for the new development version > > then when it builds the 'Top Parent POM' it outputs this: > > [INFO] [INFO] > ------------------------------------------------------------------------ > [INFO] [INFO] Building Aries :: Top Parent POM > [INFO] [INFO] task-segment: [clean, verify] > [INFO] [INFO] > ------------------------------------------------------------------------ > [INFO] [INFO] [clean:clean] > [INFO] [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] [INFO] Setting property: resource.loader => 'classpath'. > [INFO] [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] [INFO] [remote-resources:process {execution: default}] > [INFO] [INFO] [site:attach-descriptor] > [INFO] [INFO] [assembly:single {execution: source-release-assembly}] > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping > [INFO] [INFO] Building zip: > C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping > [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping > [INFO] [INFO] Preparing source:jar > [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent > recursive invocation. > [INFO] [INFO] No goals needed for project - skipping > [INFO] [INFO] [source:jar {execution: attach-sources}] > [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}] > [INFO] [INFO] Not executing Javadoc as the project is not a Java > classpath-capable package > [INFO] [INFO] [gpg:sign {execution: default}] > > so it seems to be outputting 1.0.0 artifacts still. Any ideas? > > Then stops at the gpg stage. I thought it would prompt me for my key > passphrase at this point. Do I need gpg-agent to be running? > >> updating the parent version wherever it is used (all subproject parents) >> >> releasing the subprojects in an appropriate order and updating their >> versions wherever they are used. >> >> It might be worthwhile changing the pom version to 0.1-incubating-SNAPSHOT >> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this because >> then the versions plugin can be used to update use of a subproject to the >> newly released version of what it uses. Going from >> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this. >> >> As noted in the "root" pom, don't try to release the root pom and don't try >> release everything at once from the root pom. >> >> thanks >> david jencks >> >> >> >> On Feb 24, 2010, at 11:55 PM, David Jencks wrote: >> >>> I started looking into cleaning up the build, and of course it is taking >>> longer than I expected. >>> >>> I'm seriously hampered by failing tests in a fresh checkout. >>> >>> There are some projects in application that stop compiling if you >>> alphabetize the dependencies. It looks like osgi 3 artifacts are getting on >>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to the >>> dependencies seems to fix it if you can figure out where the out of date >>> jars are coming from. >>> >>> The build is already much closer to a multi-release model than a single >>> release model. >>> >>> I've diffed what I have so far and attached it to ARIES-173. It includes >>> scm info and a lot of version corrections. Due to the failing tests I'm not >>> too comfortable committing it. >>> >>> Is anyone else seeing test failures locally? >>> >>> thanks >>> david jencks >>> >>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote: >>> >>>> Hi David, >>>> >>>> It 'd be great if you are willing to fix these build issues, since you >>>> just went through a big release in Geronimo. :) >>>> >>>> I know the maven release plugin isn't friendly to use some cases, so >>>> it is best we get these resolved to make our release process a bit >>>> easier. >>>> >>>> EBA plugin would be a very nice add-on, if it comes in time with the >>>> release. >>>> >>>> Thanks >>>> >>>> Lin >>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <[email protected]> >>>> wrote: >>>>> >>>>>> I would like to understand the problems you see better, but I do not >>>>>> have >>>>>> the maven background you guys have, any chance you could explain what >>>>>> the >>>>>> problems are, why they are problems and the solution at some point? >>>>> >>>>> The biggest immediate problem is that without correct svn info you can't >>>>> do >>>>> a release with the release plugin. I'm pretty sure the way its set up >>>>> now, >>>>> when you try, the tag will be under maven's apache pom, not aries. >>>>> (you'll >>>>> fail unless you happen to be a maven committer too). You definitely >>>>> don't >>>>> want to try to do a release without the release plugin. >>>>> >>>>> Organizationally there's no way that for instance blueprint, >>>>> application, >>>>> and samples should always be released in synchrony. Any time two of >>>>> them >>>>> happen to be ready for release at the same time it will be purely >>>>> accidental. Right now everyone wants to get a milestone out the door, >>>>> but >>>>> looking at the different projects their state of completion is pretty >>>>> much >>>>> wildly different. A decision to release all of them at once is not >>>>> based in >>>>> any way on them being equally complete. I'm suggesting that since build >>>>> fixes are needed anyway, why not set up a maintainable structure that >>>>> will >>>>> continue to work beyond this publicity release. The benefit to users is >>>>> that aries will be able to release bits in a timely fashion; otherwise >>>>> the >>>>> entire project will never be in a releasable state at once. (I'm only >>>>> exaggerating a little bit :-) >>>>> >>>>> What got me looking at this at all is what look like wild gyrations that >>>>> don't really use maven properly to get an .eba (or some artifact) out >>>>> the >>>>> door. This might be ok for one release but (a) I think this can be done >>>>> directly with the assembly plugin short term and (b) an eba-maven-plugin >>>>> seems like the obvious more long term solution. >>>>> >>>>> I'm willing to fix the build and probably work on an eba plugin, but >>>>> want to >>>>> be sure this is ok with everyone first. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>>> >>>>>> Thanks >>>>>> Alasdair >>>>>> >>>>>> On 23 Feb 2010, at 18:18, David Jencks <[email protected]> wrote: >>>>>> >>>>>>> This discussion got me worried enough to take a look at the aries >>>>>>> build. >>>>>>> Now I'm even more worried. >>>>>>> >>>>>>> While it might feel good to try to push out a release as fast as >>>>>>> possible >>>>>>> I'd prefer to see a sustainable build system in place first. So far >>>>>>> it >>>>>>> looks to me as if aries is going to be a bunch of loosely coupled >>>>>>> subprojects. Building them all at once is not going to work for long. >>>>>>> I >>>>>>> think we should recognize that and put that in the build system now. >>>>>>> To me >>>>>>> this means: >>>>>>> >>>>>>> 1. a parent pom that isn't at the root of the svn trunk. >>>>>>> 2. each subproject has pom info sufficient so it can be released >>>>>>> (mostly >>>>>>> svn info) (right now this is completely missing everywhere as far as >>>>>>> I can >>>>>>> see, which will result in ares getting tagged into svn as part of the >>>>>>> apache >>>>>>> pom) >>>>>>> >>>>>>> We can still have a "fake" pom that builds everything, but it won't be >>>>>>> part of any release procedure. >>>>>>> >>>>>>> Having separately released subprojects does not prevent having a >>>>>>> single >>>>>>> vote on all the releases. >>>>>>> >>>>>>> I'd suggest a few other pom tweaks such as using resources and >>>>>>> filtered-resources to distinguish when filtering is called for. >>>>>>> >>>>>>> In addition relevant to this particular bit of the thread, we need an >>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first release >>>>>>> would >>>>>>> be a great idea IMO. >>>>>>> >>>>>>> If there's general agreement I can spend some time playing with the >>>>>>> build >>>>>>> and possibly working on the eba plugin. >>>>>>> >>>>>>> thoughts? >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote: >>>>>>> >>>>>>>> Jeremy Hughes wrote: >>>>>>>>> >>>>>>>>> On 19 February 2010 13:09, Joe Bohn <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> I'd also like to see us release the sample applications but I think >>>>>>>>>> there is >>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader >>>>>>>>>> generate >>>>>>>>>> EBAs >>>>>>>>>> using different techniques - but both leverage the >>>>>>>>>> maven-antrun-plugin >>>>>>>>>> to >>>>>>>>>> finally produce a file of type "eba". >>>>>>>>> >>>>>>>>> I realised the .eba file generated in the blog-assembly module >>>>>>>>> wasn't >>>>>>>>> being pushed into my local repo. I've made some changes to the >>>>>>>>> pom.xml >>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba >>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact to >>>>>>>>> the >>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for >>>>>>>>> the ianal plugin in the verify phase to succeed. >>>>>>>> >>>>>>>> I've not used the build-helper-maven-plugin before. Do you know if >>>>>>>> it >>>>>>>> will work with the maven-release-plugin to push the eba artifacts >>>>>>>> when we do >>>>>>>> a release? If so, then I should look at using the same mechanism for >>>>>>>> AriesTrader. >>>>>>>> >>>>>>>>>> I think the result is that the eba will not be available in a maven >>>>>>>>>> repository. >>>>>>>>>> >>>>>>>>>> One of the differences is that AriesTrader first generates a jar >>>>>>>>>> using >>>>>>>>>> the >>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will >>>>>>>>>> be >>>>>>>>>> managed by maven and IIUC it should be deployable as an >>>>>>>>>> "application" >>>>>>>>>> even >>>>>>>>>> with an extension of "jar" rather than "eba". If that is correct >>>>>>>>>> then >>>>>>>>>> perhaps delivery of an application jar is an acceptable approach >>>>>>>>>> for >>>>>>>>>> the 1st >>>>>>>>>> release. Unfortunately I haven't actually setup my equinox >>>>>>>>>> assembly >>>>>>>>>> to >>>>>>>>>> deploy the eba yet - it still deploys all of the individual >>>>>>>>>> bundles. >>>>>>>>> >>>>>>>>> Using the maven-assembly-plugin likely the preferred approach long >>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the >>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven >>>>>>>>> control and add the .eba one? >>>>>>>> >>>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is >>>>>>>> there anything wrong with the approach I mentioned earlier of just >>>>>>>> using the >>>>>>>> jar artifacts rather than the eba artifacts? Will the current >>>>>>>> application >>>>>>>> support only look at *.eba archives? >>>>>>>> >>>>>>>>>> Joe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Guillaume Nodet wrote: >>>>>>>>>>> >>>>>>>>>>> I'd like to see at least those included: >>>>>>>>>>> * blueprint >>>>>>>>>>> * jmx >>>>>>>>>>> * jndi >>>>>>>>>>> * transaction >>>>>>>>>>> >>>>>>>>>>> I don't think applications are really usable yet and I haven't >>>>>>>>>>> really >>>>>>>>>>> looked at JPA yet, so can't tell about it. >>>>>>>>>>> The transaction component is functional and we've been using it >>>>>>>>>>> mostly >>>>>>>>>>> unchanged since a long time in ServiceMix. >>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking >>>>>>>>>>> about >>>>>>>>>>> declarative transactions for blueprint, note). >>>>>>>>>>> >>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for >>>>>>>>>>>> volunteering >>>>>>>>>>>> to be the release manager. Your response helps me get a better >>>>>>>>>>>> picture >>>>>>>>>>>> of >>>>>>>>>>>> the plans. >>>>>>>>>>>> >>>>>>>>>>>> I was really just interested in the general objectives and timing >>>>>>>>>>>> since >>>>>>>>>>>> it >>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means >>>>>>>>>>>> it >>>>>>>>>>>> will >>>>>>>>>>>> be >>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too >>>>>>>>>>>> steep to >>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong. >>>>>>>>>>>> >>>>>>>>>>>> The more communication the better. It's important to get >>>>>>>>>>>> everybody >>>>>>>>>>>> thinking >>>>>>>>>>>> and planning along the same lines (or understand quickly if there >>>>>>>>>>>> are any >>>>>>>>>>>> differences of opinion). Knowing that you are thinking of >>>>>>>>>>>> creating >>>>>>>>>>>> a >>>>>>>>>>>> release candidate next week means that we should be getting more >>>>>>>>>>>> restrictive >>>>>>>>>>>> on new content to avoid any unpleasant surprises. >>>>>>>>>>>> >>>>>>>>>>>> I don't have any strong opinions on what should be in or out - >>>>>>>>>>>> but >>>>>>>>>>>> in >>>>>>>>>>>> general it doesn't make sense to release things that aren't >>>>>>>>>>>> functional. >>>>>>>>>>>> At >>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of >>>>>>>>>>>> the >>>>>>>>>>>> components are fully functional yet (for example transaction). >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out >>>>>>>>>>>>> on >>>>>>>>>>>>> vacation until monday. >>>>>>>>>>>>> >>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we >>>>>>>>>>>>> have >>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must >>>>>>>>>>>>> haves' >>>>>>>>>>>>> are to get the build in the right shape to create the >>>>>>>>>>>>> distribution >>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of >>>>>>>>>>>>> the >>>>>>>>>>>>> code deserves at least a README to describe what's possible. >>>>>>>>>>>>> Since >>>>>>>>>>>>> this is the first release there are likely a few unknowns - >>>>>>>>>>>>> w.r.t >>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If >>>>>>>>>>>>> there >>>>>>>>>>>>> are >>>>>>>>>>>>> particular JIRAs or other issues you feel should be included >>>>>>>>>>>>> please >>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and >>>>>>>>>>>>> target >>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a >>>>>>>>>>>>> new >>>>>>>>>>>>> 0.2 version. WDYT? >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Jeremy >>>>>>>>>>>>> >>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeremy, >>>>>>>>>>>>>> >>>>>>>>>>>>>> What are your current thoughts and goals regarding the release >>>>>>>>>>>>>> and >>>>>>>>>>>>>> potential >>>>>>>>>>>>>> target dates? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it would be good if you could summarize your thoughts >>>>>>>>>>>>>> in >>>>>>>>>>>>>> an >>>>>>>>>>>>>> email >>>>>>>>>>>>>> or >>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we >>>>>>>>>>>>>> make >>>>>>>>>>>>>> progress. >>>>>>>>>>>>>> Of particular interest would be the content that we would like >>>>>>>>>>>>>> to >>>>>>>>>>>>>> see >>>>>>>>>>>>>> in >>>>>>>>>>>>>> the first release (clarifying what we consider "must have" from >>>>>>>>>>>>>> "nice >>>>>>>>>>>>>> to >>>>>>>>>>>>>> have"), the current status of that content, target dates for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> release, >>>>>>>>>>>>>> and the process that we plan to use to generate the release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Joe >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <[email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help. >>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to >>>>>>>>>>>>>>>> put >>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>> on the wiki. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the >>>>>>>>>>>>>>> process >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>> changed quite a bit :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes >>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Jeremy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller >>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all >>>>>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>>>> at a >>>>>>>>>>>>>>>>>> 0.1 >>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning >>>>>>>>>>>>>>>>>> scheme, >>>>>>>>>>>>>>>>>> IMO. >>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an >>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an >>>>>>>>>>>>>>>>>> important >>>>>>>>>>>>>>>>>> step >>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this >>>>>>>>>>>>>>>>>> happen... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --kevan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Joe >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Joe >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Joe >>>>>>> >>>>> >>>>> >>> >> >> >
