On 24 February 2010 03:44, Joe Bohn <[email protected]> wrote: > David Jencks wrote: >> >> On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote: >> >>> I'm am new to maven, so sorry if I show my ignorance. >>> >>> While I think I can see the value to what you suggest moving forward if >>> we choose to release sub-projects independantly (I say if because we haven't >>> discussed or agreed what tbd long term answer is yet) I do not understand >>> the benefit to a user of Aries of this change. >>> >>> As a result it does not appear to me to be key to resolve prior to >>> release. >>> >>> 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. > > > The svn info can be added to support the maven-release-plugin without > reorganizing to support independent component releases. But I agree that it > would be nice to have the option of independent releases even if we intend > to release all components in this first release. So in general, I'm in > favor of the reorganization.
I'm starting to come to the same conclusion. Flexibility is good. We should have the ability to respond quickly to users who want a new release of a subproject and not be forced into releasing the entirety of Aries. So I'm +1 for a reorg to achieve this. > > As I mentioned earlier, I am concerned about the eba generation as well. I > think a maven-eba-plugin would be preferred versus the alternative I > mentioned of releasing the ebas simply as jars (again, assuming that the > application code can deal with an archive of type jar instead of eba). I am > using the maven-assembly-plugin to generate the jar for the eba in the > AriesTrader sample but I didn't find the magic formula necessary to create > the archive with a type of eba rather than jar and so I resorted to using > ant (which I know is bad). A maven-eba-plugin or the necessary > configuration to get the maven-release-plugin to generate something of type > eba would sure be nice. Yeah, resorting to ant made be barf too. I prefer a custom eba plugin over the assembly plugin so we can add our own features more easily, such as APPLICATION.MF generation. > > I guess the key question might be how long it would take to make these > changes and is it worth the wait. > > Joe > >> >> 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 >>>> >> >> > > > -- > Joe >
