openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: CI setup and publishing snapshots (Re: Update version to SNAPSHOT)
Date Mon, 28 Aug 2006 17:14:53 GMT


>> 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 "<name>" 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 <artifactId>-<version>-<assemblyName>.<archiveType>.
 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!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


Mime
View raw message