>> If the snapshot deploy directory /x1/www/people.apache.org/repo/m2- >> snapshot-repository/org/apache/openjpa/ is available from the >> continuum server, I might be able to override the >> snapshotRepository to deploy straight to that directly, in which >> case we'd have automatic deployment of the snapshot (would would >> be very handy). Does that sound plausible to you? > > It would be perfect. Unfortunately, it's running in a solaris zone > on a completely different box :( That's too bad. To anyone's knowledge, has anyone accomplished automatic nightly deployment of snapshots to the Apache snapshot repository, or is it always a manual process? On Aug 24, 2006, at 2:51 PM, David Blevins wrote: > > On Aug 24, 2006, at 12:46 PM, Marc Prud'hommeaux wrote: > >> David- >> >>> I added it in (that's the easy part). See http:// >>> vmbuild.apache.org/continuum/servlet/continuum >>> >>> That machine is terribly slow.... >> >> I notice that there is both a "OpenJPA" and a "OpenJPA Project" >> build configured in continuum, and "OpenJPA" doesn't seem to >> actually be building anything. Was this intended? > > In continuum, you only need to add the root pom.xml (parent > pom.xml) and it will set up that project and all the subprojects > (child pom.xmls) for you. You need the parent pom.xml to build any > of the children, so you definitely want that in there. > > As an FYI, the names come from each pom.xml file's "" element > as you probably figured out. You may want to adopt the convention > of prefixing "OpenJPA" in all your name elements, such as > "OpenJPA :: JDBC", just so they all show up next to each other (for > example "XML Store" is way down on the page). Whatever you prefer > is fine. > > Also as Patrick has said a couple times, you'd like to get a > TeamCity server setup, cool. Just say "when" and I'll yank it from > the continuum setup. > >>> The tricky part with any CI system is the whole question of "Gee, >>> what credentials do we use to deploy snapshots?" >> >> If the snapshot deploy directory /x1/www/people.apache.org/repo/m2- >> snapshot-repository/org/apache/openjpa/ is available from the >> continuum server, I might be able to override the >> snapshotRepository to deploy straight to that directly, in which >> case we'd have automatic deployment of the snapshot (would would >> be very handy). Does that sound plausible to you? > > It would be perfect. Unfortunately, it's running in a solaris zone > on a completely different box :( > > -David > >> >> >> >> >> On Aug 23, 2006, at 10:41 PM, David Blevins wrote: >> >>> >>> On Aug 23, 2006, at 4:20 PM, Bryan Noll wrote: >>> >>>> So... I saw that David created the following two JIRA's, so I >>>> wanted to follow up on the thread. >>>> >>>> http://issues.apache.org/jira/browse/OPENJPA-29 >>>> http://issues.apache.org/jira/browse/OPENJPA-30 >>>> >>>> >>>> Regarding OPENJPA-29: >>>> >>>> openjpa-0.9.0-full.jar // contains all openjpa code, openjpa- >>>> *.jars merged >>>> openjpa-0.9.0-nodep.jar // contains all openjpa code and all >>>> third party dependency jars >>>> >>>> Do you have your descriptions backwards or am I misunderstanding >>>> what you're saying? >>> >>> I very well could have them backwards. As I said, "There's a >>> naming convention for this kind of thing, hope I've got it right." >>> >>>> Seems like 'nodep' would mean "no dependencies for this project >>>> are bundled into this jar" to me. >>>> IIUC (which I'm not sure that I do, so please correct me) then... >>>> >>>> openjpa-0.9.0-nodep.jar would extract to: >>>> - org/apache/openjpa/*/**.class >>>> - META-INF/* ............ (we still need to resolve the 'merge >>>> multiple files of the same name and locations (eg.. >>>> ProductDerivations) problem for this) >>>> >>>> openjpa-0.9.0-full.jar would extract to: >>>> - org/apache/openjpa/*/**.class >>>> - thirdPartyJars.jar (many of these) >>>> - META-INF/* .......... (same issue as above) >>> >>> The classes from the third party jars would also have been >>> extracted into the jar. >>> >>>> Would the openjpa-*.jar files be there instead of the unpacked >>>> classes? >>> >>> Classes. >>> >>>> Should the names actually be openjpa-nodep-0.9.0-SNAPSHOT.jar >>>> and openjpa-full-0.9.0-SNAPSHOT.jar? >>> >>> That'd be possible. You'd have to have one maven module for each >>> jar and poke at the assembly plugin setup to not use the default >>> name of --.. The >>> maven guys may know a better way. >>> >>>> >>>> Regarding OPENJPA-30: >>>> >>>> - I saw that Marc got the newly named SNAPSHOT jars up to a >>>> repo.... good stuff. >>> >>> Yep. Thanks again, Marc! Very appreciated! >>> >>>> - The next step would have one jar somewhere like http:// >>>> people.apache.org/repo/m2-snapshot-repository/org/apache/openjpa/ >>>> openjpa/0.9.0-SNAPSHOT/ for people to depend on, instead of >>>> many, correct? >>> >>> We (Geronimo and OpenEJB) use maven 2 which has transitive >>> dependencies, so it's not critical for us. But it'd be real >>> handy for anyone using maven 1 or ant. Or anyone really who just >>> wants to throw that jar in their webapp and say "go!" >>> >>>> - David... if you catch this... I would be glad to help >>>> (translation... observe and learn) you get the thing publishing >>>> nightly from the apache continuum server you spoke of. >>> >>> I added it in (that's the easy part). See http:// >>> vmbuild.apache.org/continuum/servlet/continuum >>> >>> That machine is terribly slow.... >>> >>> The tricky part with any CI system is the whole question of "Gee, >>> what credentials do we use to deploy snapshots?" >>> >>> To skirt the issue of what user to "push" jars as, I've typically >>> setup an rsync on the destination box and "pulled" the jars >>> down. That worked fine with maven 1, but maven 2 has these >>> wonderful index files in the repo that make that impossible to my >>> knowledge. Maybe Brett can confirm. >>> >>> -David >>> >>>> >>>> >>>> Thanks... >>>> >>>> Bryan >>>> >>>> >>>> David Blevins wrote: >>>>> >>>>> On Aug 15, 2006, at 7:42 AM, Craig L Russell wrote: >>>>> >>>>>> >>>>>> On Aug 15, 2006, at 6:38 AM, Patrick Linskey wrote: >>>>>> >>>>>>>> Check out the Assembly plugin and it's predefined >>>>>>>> "jar-with-dependencies" descriptor[1]. I'm pretty sure that >>>>>>>> most people >>>>>>>> using Maven will just have a runtime dependency on the core >>>>>>>> OpenJPA >>>>>>>> library and be done with it, but it's always nice for Ant >>>>>>>> users. >>>>>>> >>>>>>> Exactly -- mvn users will use the dependencies, but people >>>>>>> who want to >>>>>>> download and use the distribution directly may not want a >>>>>>> billion little >>>>>>> jars. >>>>>> >>>>>> Yes, my experience says it's ok to have 10 dependencies on >>>>>> e.g. commons-logger, antlr, etc. but having 10 dependencies on >>>>>> openjpa-kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is >>>>>> annoying. >>>>>> >>>>>> So if possible, I'd also like to have a jar with all the stuff >>>>>> in it. >>>>> >>>>> That'd be nice. Some jar that contains all the openjpa-*.jar >>>>> files is perfect for my needs. The good news is that the maven- >>>>> assembly-plugin allows you to define several assembly xml files >>>>> and build multiple archives containing whatever you like. So >>>>> if people want, we could have: >>>>> >>>>> openjpa-0.9.0-full.jar // contains all openjpa code, openjpa- >>>>> *.jars merged >>>>> openjpa-0.9.0-nodep.jar // contains all openjpa code and all >>>>> third party dependency jars >>>>> >>>>> There's a naming convention for this kind of thing, hope I've >>>>> got it right. >>>>> >>>>> -David >>>>> >>>>>> >>>>>> Craig >>>>>>> >>>>>>> -Patrick >>>>>>> ________________________________________________________________ >>>>>>> _______ >>>>>>> Notice: This email message, together with any attachments, >>>>>>> may contain >>>>>>> information of BEA Systems, Inc., its subsidiaries and >>>>>>> affiliated >>>>>>> entities, that may be confidential, proprietary, >>>>>>> copyrighted and/or >>>>>>> legally privileged, and is intended solely for the use of the >>>>>>> individual >>>>>>> or entity named in this message. If you are not the intended >>>>>>> recipient, >>>>>>> and have received this message in error, please immediately >>>>>>> return this >>>>>>> by email and then delete it. >>>>>> >>>>>> Craig Russell >>>>>> Architect, Sun Java Enterprise System http://java.sun.com/ >>>>>> products/jdo >>>>>> 408 276-5638 mailto:Craig.Russell@sun.com >>>>>> P.S. A good JDO? O, Gasp! >>>>>> >>>>> >>>>> >>>> >>> >> >