aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: [DISCUSSION] Aries release
Date Wed, 24 Feb 2010 21:50:44 GMT
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

EBA plugin would be a very nice add-on, if it comes in time with the release.


On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <> 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 <> 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 <> 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
>>>> 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
>>>>>> the
>>>>>> maven-assembly-plugin and then copies this to an eba.  The jar will
>>>>>> 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
>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>> 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
>>>> 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
>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>> The transaction component is functional and we've been using
>>>>>>> mostly
>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>> declarative transactions for blueprint, note).
>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <>
>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>> volunteering
>>>>>>>> to be the release manager.  Your response helps me get a
>>>>>>>> picture
>>>>>>>> of
>>>>>>>> the plans.
>>>>>>>> I was really just interested in the general objectives and
>>>>>>>> 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
>>>>>>>> steep to
>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>> The more communication the better.  It's important to get
>>>>>>>> thinking
>>>>>>>> and planning along the same lines (or understand quickly
if there
>>>>>>>> are any
>>>>>>>> differences of opinion).  Knowing that you are thinking of
>>>>>>>> a
>>>>>>>> release candidate next week means that we should be getting
>>>>>>>> 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
>>>>>>>>> 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.
>>>>>>>>> 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
>>>>>>>>> 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 <>
>>>>>>>>>> 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
>>>>>>>>>> Thanks,
>>>>>>>>>> Joe
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <>
>>>>>>>>>>> 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
>>>>>>>>>>>> <>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>> --
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Blog:
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Open Source SOA
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>> --
>>>>>>>> Joe
>>>>>> --
>>>>>> Joe
>>>> --
>>>> Joe

View raw message