Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 19804 invoked from network); 28 Jun 2006 16:18:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Jun 2006 16:18:49 -0000 Received: (qmail 55521 invoked by uid 500); 28 Jun 2006 16:18:44 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 55471 invoked by uid 500); 28 Jun 2006 16:18:43 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 55439 invoked by uid 99); 28 Jun 2006 16:18:43 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jun 2006 09:18:43 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [68.142.206.242] (HELO smtp109.plus.mail.mud.yahoo.com) (68.142.206.242) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 28 Jun 2006 09:18:42 -0700 Received: (qmail 53851 invoked from network); 28 Jun 2006 16:18:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=HYLRczWF/qdWrUTE2blWci9ybhfVoa4derVDe6katYoPTcHGl73i+pM/2+ReYan5pCSH7rDvAgwrZ0UZ2Lz4qaVCTlNy/eejwxrWH9l4tcA4F534XmxoXqs7TI4YuqSBv6qD457GRASbGXQ4XRtMOZa5PuZ3u8zBPLueS7QtWFQ= ; Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with plain) by smtp109.plus.mail.mud.yahoo.com with SMTP; 28 Jun 2006 16:18:20 -0000 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <54536EEE-4EDF-4B07-97A8-5A16A1E77945@planet57.com> References: <449F57AF.50005@toolazydogs.com> <7FF53704-A4D4-4B1D-942D-783747634447@planet57.com> <8D493BEB-3E46-4CA1-AEC2-ADD6E7C1F007@planet57.com> <54536EEE-4EDF-4B07-97A8-5A16A1E77945@planet57.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Unable to build using m2 Date: Wed, 28 Jun 2006 09:19:34 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.749.3) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Jun 27, 2006, at 2:15 PM, Jason Dillon wrote: >>> Any idea where the stax:stax-api:1.1.1-dev comes from? >>> >>> The root pom states that stax:stax-api:1.0 should be used... but >>> the errors with the xmlbeans plugin all state 1.1.1-dev. >> >> I've filed a bunch of bugs all over the place and the current >> status is: >> >> -- I'm working with the xmlbeans team to publish correct poms for >> xmlbeans 2.0.0-1, 2.1.0-1, and 2.2.0. This will take a while, but >> apparently won't conflict with the maven evangelism rules (my >> first attempt revealed that the evangelism instructions had no >> relationship to the actual process the maven team uses) > > How long is a while? don't know, I think I understand the dependencies properly, but I'd like to come up with plausible non-minimal poms for them. > > Urg... this is another thing about Maven that really bothers me... > we are SO completely dependent on other projects for our own > project to succeed. > > This would not be a problem if we had our own repo that we had > complete ownership of. We could fix any poms and install fixed > plugins. How would we get these fixes back into the community? I worry that having our own repo would make it harder to assure that we are using generally available versions of other projects, and make it harder to contribute our fixes back to those projects. For instance, it took me some time to get an m2 build of howl working and find out how to get it published, but the result is IMO much better for both howl and us than if we simply said "we'll just stick a pom for howl in our private repo". > And... the build would be completely repeatable. Chances are > that in a year or two, if anyone tries to build anything with Maven > off of an old branch it will fail miserably. IMO this is not > acceptable. Future build failures should only result from someone trashing the supposedly permanent ibiblio repo. As far as your other points, any time we decide to use software written by some other community, we are depending on them to do some work for us. I think we need to adopt a process that assures our contributions to their project in fact get back to their project in a timely fashion. > > >> -- The maven xmlbeans plugin has had a couple fixes applied, but >> whether a snapshot is publically available is not clear to me. I >> strongly recommend building the xmlbeans plugin from source. IIRC >> this will eliminate the need for the bogus stax dependencies. >> Here's the latest relevant jira: http://jira.codehaus.org/browse/ >> MXMLBEANS-20?page=all >> >> After all the fixes are in we should not need any dependencies on >> stax-api and the bogus dependencies on stax can be removed. > > I really don't like to have to go and check out a bunch of external > tools or libraries and then go step by step, configure and build > them... and hope like heck that their builds work all of the time, > and pray that Maven does not freak-out halfway through a long build > due to a missing dependency or repository timeout... just to get > the right bits in place to maybe get our build moving forward, Seems to me the alternative is to not use anyone elses code, which I find unacceptable. > > This is a nightmare IMO. I remember a certain nightmarish build > way back in the day that needed a bit of magic... in comparison to > our build, that nightmare was the sweetest of dreams. > > * * * > > The more I think about it the more it appears thats something major > is going to need to be done to really fix things... I surely don't have all the answers, but I'd prefer that anything we adopt doesn't result in our having all sorts of private changes that are not accepted by projects we use. So, some kind of geronimo repo that has a subset of publically available stuff is ok with me, but putting private patches that aren't from the originating project seems like asking for trouble. thanks david jencks > > --jason