On Thu, Feb 25, 2010 at 08:55, David Jencks <[email protected]> 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. >
Have you tried mvn dependency:tree This usually helps *a lot* with such issues > 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 >>>>> >>> >>> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
