You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Blevins <da...@visi.com> on 2006/08/24 23:51:10 UTC
CI setup and publishing snapshots (Re: Update version to SNAPSHOT)
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!
>>>>>
>>>>
>>>>
>>>
>>
>
Re: CI setup and publishing snapshots (Re: Update version to SNAPSHOT)
Posted by David Blevins <da...@visi.com>.
On Aug 28, 2006, at 10:14 AM, Marc Prud'hommeaux wrote:
>
>
>>> 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?
>
Not to my knowledge for m2. With m1 it was easier as there were no
"index" files that you had to update on every deploy. You could just
rsync and add/update a bunch of jars with no issue.
I'd like to see this solved too.
As an interim solution, continuum itself can be used as a maven2
repository. People would just have to add this to their pom:
<repository>
<id>continuum-m2-snapshot</id>
<name>Continuum Snapshot Repository</name>
<url>http://vmbuild.apache.org/continuum/repository</url>
</repository>
-David
>
>
>
> 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!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: CI setup and publishing snapshots (Re: Update version to SNAPSHOT)
Posted by Marc Prud'hommeaux <mp...@apache.org>.
>> 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!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>