Return-Path: Delivered-To: apmail-incubator-aries-dev-archive@minotaur.apache.org Received: (qmail 30794 invoked from network); 2 Mar 2010 19:06:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Mar 2010 19:06:43 -0000 Received: (qmail 31377 invoked by uid 500); 2 Mar 2010 19:06:38 -0000 Delivered-To: apmail-incubator-aries-dev-archive@incubator.apache.org Received: (qmail 31343 invoked by uid 500); 2 Mar 2010 19:06:38 -0000 Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: aries-dev@incubator.apache.org Delivered-To: mailing list aries-dev@incubator.apache.org Received: (qmail 31334 invoked by uid 99); 2 Mar 2010 19:06:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Mar 2010 19:06:38 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.61] (HELO smtp106.prem.mail.sp1.yahoo.com) (98.136.44.61) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 02 Mar 2010 19:06:27 +0000 Received: (qmail 54562 invoked from network); 2 Mar 2010 19:06:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=gxHPJafXg+QUSQ/WWWpydpA7aIzuhtu24gZTGcJtUPiLkK5+pN8W/2q94+9LuL1gAMVSyHpSTwS+sHIiMcwc9j++LZT7tpUuWn0xBC42BR6lB/75jB+yOJNnl7SyT45VKv2NvC775obaIwyXsCVaDSdR2Tcwb0l5TJhYNJO0OmE= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 02 Mar 2010 11:06:04 -0800 PST X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: S8Z36N8VM1ls90P7ln68CcM377X7DQ2myZJvr0vdartiPSIUPvbyO1xRttREECyEvVi_4_bRrX3S.ybALMAGeNacOch231QtASlYccmg6uOCsXnM.it_NFRZOl0FiNe5P.F60ncrJvqOfBmPnN9jWpMaceG3D5h_wRpXkbeo4onYaZFpLPlHFuFV.JU_2MFOd1ZmOag6Zq8_heiq5BlvQ8u4rO2V0WP7kh978vMZSbuSEd7mcbUWw04qEjOFZhaA_WUZiCtaNbJ2OTTXTmx8nKfTHGIlGcCT37tLWhzhp2BcvNU28YSvGBDAG0kMh2M2cPsK1Q.KaeR9_8lHRFwV X-Yahoo-Newman-Property: ymail-3 Message-Id: <9D19D69E-FD1E-4469-B10C-029EB875CBC6@yahoo.com> From: David Jencks To: aries-dev@incubator.apache.org In-Reply-To: <4B8D59E9.1060802@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [DISCUSSION] Aries release Date: Tue, 2 Mar 2010 11:06:03 -0800 References: <4B82FEB3.2070800@gmail.com> <5B0147EC-86EF-41C8-8DBA-0363B4C50C63@yahoo.com> <285387ED-7978-4D55-ABB4-1DD640F1E0B3@apache.org> <7287D314-C01F-458D-8C77-0FED066CA2EB@yahoo.com> <595020BE-A779-409C-A7F5-AE695731F2C0@yahoo.com> <3A985FAE-9385-4329-8859-B60F7B30D31E@yahoo.com> <4B8D59E9.1060802@gmail.com> X-Mailer: Apple Mail (2.936) X-Virus-Checked: Checked by ClamAV on apache.org On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote: > I agree that we should make a global change to 0.1-incubating- > SNAPSHOT first. Why wouldn't we just do that now? I started doing some experiments here... running mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT in root and parent upgrades everything maven knows about just fine. However there's (1) mentioned below and also a hardcoded version in two blueprint-itests. According to http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin we should be able to replace the hardcoded versions with .versionAsInProject() if we run the maven-paxexam-plugin on the project. However I can't get it to work yet. > > Just a heads-up on some other issues related to versions in samples. > There are two potential problems that I am aware of: > > 1) For both Blog-Sample and AriesTrader there are hard-coded > version references in the Equinox assembly config.ini file which are > used to specify the bundle jars that are to be started for the > assembly. Naturally, the versions of the aries bundles in this file > won't be updated by the maven-release-plugin. I'm not sure of a > good solution for this beyond just manually changing the config.ini > files prior to creating a release candidate. I think we might be able to work around this by putting the config.ini files in src/main/resources/filtered-resources and defining a bunch of properties in an appropriate pom and using them for the version imports of the aries subproject dependencyManagement imports in the samples root pom. I haven't tried this yet... > > 2) I think there is still an unresolved issue related to Blog- > Sample and how we might be able to demonstrate a bundle upgrade > scenario. I'm not sure if this capability is included yet in Blog- > Sample - so it might still be a non-issue at the moment. However, > we had some discussion on this a week ago or so related to how we > might be able to include multiple versions of components in the > sample so that an upgrade scenario could be demonstrated. If that > is still a goal for the 0.1 release we will need to come up with > some solution. no ideas from me on this one :-) thanks david jencks > > Joe > > > David Jencks wrote: >> I think everything is ok.... I think (at least with dryRun=true) >> that the release plugin builds the project first as-is and checks >> that signing etc works. >> I added autoVersionSubmodules=true in the root parent pom which >> will make things work more smoothly :-) >> I really recommend changing the version to 0.1-incubating-SNAPSHOT >> first, I'm happy to do this if you want. >> thanks >> david jencks >> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote: >>> scratch that. I'm working thru this: >>> http://maven.apache.org/developers/release/apache-release.html as >>> there's several steps I haven't done. >>> >>> On 2 March 2010 16:17, Jeremy Hughes wrote: >>>> On 2 March 2010 02:28, David Jencks wrote: >>>>> I've done most of what I think is needed for aries to be basically >>>>> releasable. There are some bits left and possibly stuff I've >>>>> missed. >>>>> >>>>> 1. legal file review. There are a bunch of NOTICE files that >>>>> claim that >>>>> work from osgi is included. Really? license and notice files >>>>> are supposed >>>>> to apply to what is actually in an artifact or checkout. Are >>>>> some of our >>>>> source files copied from an osgi source? Also all the legal >>>>> files that end >>>>> up in binary artifacts need to be checked. Also we need to run >>>>> the rat >>>>> plugin: this should be configured in the default pom. Not sure >>>>> if I will >>>>> get to this. >>>>> >>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure >>>>> how to make >>>>> sure that an eba is working so I didn't mess with this. I think >>>>> the plugin >>>>> itself is working well enough to use though. >>>>> >>>>> 2. ordering dependencies and dependency management. I find it >>>>> convenient to >>>>> have these alphabetized so I can find what I'm looking for, but >>>>> I haven't >>>>> done this in most poms. I'm not sure why there isn't a usable >>>>> tool for >>>>> doing this but I haven't found one. Dull but useful... >>>>> >>>>> 3. It would probably be a really good idea to run mvn >>>>> dependency:analyze and >>>>> look carefully at the results. The results from this can require >>>>> interpretation so its best if someone who is very familiar with >>>>> how the code >>>>> works does this. >>>>> >>>>> 4. before a release all snapshots need to be resolved to >>>>> released versions. >>>>> I don't know if there are any snapshots. >>>>> >>>>> To summarize what I've tried to do: >>>>> >>>>> 1. default-parent has dependency management for the basic osgi >>>>> dependencies >>>>> that all projects are pretty sure to use including the pax stuff >>>>> used mostly >>>>> for testing. >>>>> >>>>> 2. each subproject has legal files in its checkout root >>>>> >>>>> 3. each subproject has an scm element in its pom, but no others >>>>> do. >>>>> >>>>> 4. each subproject has dependency management for everything >>>>> included in it. >>>>> In addition, it has its subprojects listed in dependency >>>>> management. (this >>>>> is bent slightly for the samples). This means that >>>>> (a) modules in a subproject don't need to include versions for >>>>> use of other >>>>> modules >>>>> (b) you can get dependency management for all the modules in a >>>>> subproject >>>>> by depending on the subproject pom with scope import. (see the >>>>> samples pom >>>>> for an example). >>>>> >>>>> 5. As a result of (4), modules don't have any versions in any >>>>> dependency >>>>> elements. >>>>> >>>>> Release is going to involve... >>>>> >>>>> releasing the parent >>>> >>>> In trunk/parent I tried: >>>> >>>> mvn -DdryRun=true release:prepare -Papache-release >>>> >>>> Providing 0.1-incubating for the release version >>>> Defaulting to parent-0.1-incubating for the SCM release tag >>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development >>>> version >>>> >>>> then when it builds the 'Top Parent POM' it outputs this: >>>> >>>> [INFO] [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] [INFO] Building Aries :: Top Parent POM >>>> [INFO] [INFO] task-segment: [clean, verify] >>>> [INFO] [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] [INFO] [clean:clean] >>>> [INFO] [INFO] Setting property: classpath.resource.loader.class => >>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. >>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'. >>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'. >>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound => >>>> 'false'. >>>> [INFO] [INFO] [remote-resources:process {execution: default}] >>>> [INFO] [INFO] [site:attach-descriptor] >>>> [INFO] [INFO] [assembly:single {execution: source-release- >>>> assembly}] >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, >>>> skipping >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already >>>> added, skipping >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already >>>> added, skipping >>>> [INFO] [INFO] Building zip: >>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0- >>>> incubating-SNAPSHOT-source-release.zip >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, >>>> skipping >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already >>>> added, skipping >>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already >>>> added, skipping >>>> [INFO] [INFO] Preparing source:jar >>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent >>>> recursive invocation. >>>> [INFO] [INFO] No goals needed for project - skipping >>>> [INFO] [INFO] [source:jar {execution: attach-sources}] >>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}] >>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java >>>> classpath-capable package >>>> [INFO] [INFO] [gpg:sign {execution: default}] >>>> >>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas? >>>> >>>> Then stops at the gpg stage. I thought it would prompt me for my >>>> key >>>> passphrase at this point. Do I need gpg-agent to be running? >>>> >>>>> updating the parent version wherever it is used (all subproject >>>>> parents) >>>>> >>>>> releasing the subprojects in an appropriate order and updating >>>>> their >>>>> versions wherever they are used. >>>>> >>>>> It might be worthwhile changing the pom version to 0.1- >>>>> incubating-SNAPSHOT >>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing >>>>> this because >>>>> then the versions plugin can be used to update use of a >>>>> subproject to the >>>>> newly released version of what it uses. Going from >>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this. >>>>> >>>>> As noted in the "root" pom, don't try to release the root pom >>>>> and don't try >>>>> release everything at once from the root pom. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>> >>>>> >>>>> On Feb 24, 2010, at 11:55 PM, David Jencks 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. >>>>>> >>>>>> 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 >>>>>> > >>>>>>> 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 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 >>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> manager. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 volunteers? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --kevan >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Joe >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Joe >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>>> > > > -- > Joe