aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Date Tue, 22 Nov 2011 14:56:19 GMT
On 16 November 2011 16:15, Daniel Kulp <> wrote:
> On Wednesday, November 16, 2011 3:40:22 PM Jeremy Hughes wrote:
>> On 16 November 2011 01:49, Daniel Kulp <> wrote:
>> > tackling the first part.  :-)    I also *prefer* that it work behind a
>> > reasonably setup proxy/firewall (read: no snapshot deps not part of the
>> > build), but that is definitely tertiary.
>> I'm afraid I can't help here much as I don't have these proxy/firewall
>> restrictions. What do you suggest when a new feature / bug fix depends
>> on a bug fix to a dependency outside Aries? A snapshot dependency is
>> often needed for this until the dependency project is released.
> Like I said, kind of tertiary at this point.  Call it a stretch goal.  :-)
> In general, I discourage use of SNAPSHOTS unless we know a release of said
> snapshot is imminent (community is in final preparations or similar).    If
> it's a snapshot of another Apache project, I'm also usually a little more
> lenient as anyone behind said firewall at least be able to get those sources
> and build it if they can get the Aries sources.
>> > On a side note: it *really* bothers me that there is work that has been
>> > done on a branch that is not reflected on trunk.   IMO, trunk should
>> > always reflect the most up-to-date status of the code.
>> If you're referring to the oct-2011-release branch, sorry I'm getting
>> to it. I need to release 0.4.1 of blueprint-core, blueprint-cm,
>> blueprint-bundle and blueprint-itests. Either I can merge the branch
>> into trunk then create a new branch for the release, or I can do the
>> release from the existing branch then merge. In fact I'm minded to do
>> the former. Thoughts?
> Doesn't really matter to me.   I've already started porting back all the
> changes to trunk and getting version numbers updated and such.  It's NOT an
> easy port back so it's taking a little time.   I should have it done in a few
> hours though.    Once we released 0.4 of things, Nexus wiped out the 0.4-
> SNAPSHOT's from the snapshot repo so I need to go through all the poms and
> make sure they use the 0.4 release version and such.   Not a big deal, but it
> takes time.
> One more point though:  on any branch that a developer is expected to run "mvn
> install", the version number in the pom should ALWAYS be a SNAPSHOT version,
> never a  release version.   The oct branch violates that in several places,
> but I'm not sure if anyone would consider that branch a branch for developers.

Right, the oct-2011-release was intended as a release manager only branch.

> Dan
>> > Anyway, if anyone else has any input into this, feel free to add their
>> > thoughts!
>> Thanks for bringing all this up. I certainly wasn't aware of some of this.
>> > --
>> > Daniel Kulp
>> >
>> >
>> > Talend -
> --
> Daniel Kulp
> Talend -

View raw message