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 >>> > >
