You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2008/07/19 00:56:35 UTC
snapshot process (was: Re: Documentation links and content "out of date")
Hi,
I'm trying to get the snapshot process working as closely to the new
release process as possible. From what I can tell, mvn release:prepare
is really oriented towards releases, not towards snapshots. Does
anyone know of an equivalent snapshot target that we could use?
-Patrick
On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
> Sounds good, Patrick. So, in the mean time, should I make a temporary
> repository for the "latest" docs? Or, if you think this will get
> resolved
> in the next day or two, then I could just wait.
>
> Thanks,
> Kevin
>
> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey
> <pl...@gmail.com> wrote:
>
>> Hi,
>>
>> I think that this is because the machine that builds and uploads the
>> snapshots was offline for the last couple of months. I got that
>> partially
>> back up and running last week, and hope to get the snapshots
>> uploading again
>> later this week.
>>
>> -Patrick
>>
>>
>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>
>> Hi,
>>> I just noticed that our links for the "latest" OpenJPA
>>> documentation is
>>> out
>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>>> would
>>> expect that our "latest" link should point at some version of
>>> documentation
>>> associated with trunk. But, it's currently pointing at some
>>> version based
>>> on the 1.1.0 build. I was going to go ahead and clean this up,
>>> but it
>>> looks
>>> like I don't have proper authority to the /www/
>>> openjpa.apache.org/docs/latest directory. It looks like Patrick
>>> is the
>>> only
>>> one with enough authority.
>>>
>>> This "latest" directory is currently linked to this: latest ->
>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>
>>> So, I'm thinking a few things need to be done:
>>>
>>> o It would be great to post our current nightly drivers and
>>> documentation
>>> out on people.apache.org from our TC system. (BTW, it looks like
>>> our
>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT
>>> builds, so we
>>> have some clean up there as well.) I'm not sure on the status of
>>> Patrick's
>>> TC system and whether we are able to get something like this setup
>>> or not.
>>>
>>> o If we can post our nightly drivers and documentation, then we
>>> could
>>> change this "latest" directory link to our upload location for the
>>> drivers.
>>>
>>> o If this type of clean up and setup of nightly drivers is going
>>> to take
>>> some time, then at a minimum, it would be good to change the
>>> permissions
>>> on
>>> this "latest" directory so that we could do some manual (pardon
>>> the pun)
>>> cleanup.
>>>
>>> BTW, all of this came about because I had pointed a user at our
>>> "latest"
>>> manual to find out how to turn on the Query SQL Cache support
>>> (knowing it
>>> was part of the 1.2.0 trunk release). But, I soon discovered that
>>> our
>>> "latest" manual is quite out of date... :-)
>>>
>>> Thanks,
>>> Kevin
>>>
>>
>> --
>> Patrick Linskey
>> 202 669 5907
>>
>>
--
Patrick Linskey
202 669 5907
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Patrick Linskey <pl...@gmail.com>.
> $ mvn -Dmaven.test.skip=true deploy
> -DaltDeploymentRepository=myserver::default::scp://
> myserver.myhost.com/home/mikedd/temp22
>
> $ mvn -Dmaven.test.skip=true site:stage-deploy
> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
Interesting -- I didn't know you could pass in overrides like that.
> Here's what I propose, after the 1.0.3 release is approved I'll
> update the
> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The
> changes
> will be to update the default deploy location to be
> openjpa.apache.org/builds/latest/${version} (or something similar).
> That way
> the automated build system will go ahead and publish to the latest
> directory
> with no need for command line arguments.
I've got changes to the trunk pom.xml that does something much like
that right now (without the 'latest' dir); it failed to run from the
autobuild on Friday, and I was at a pre-OSCON event yesterday, but am
hoping to figure out why not today.
> In the release profile we'll change the deployment location to be
> people.apache.org/${user}/public_html/. . . so that the release is
> publicly
> available. If we can't override the location via the profile I'll
> update the
> instructions to pass it along as a command line arg.
Knowing that we can pass overrides into mvn, I think that there's a
case to be made for having the defaults be to put contents into the
user's homedir, and then have the snapshot process and the release
process override the values as appropriate. That seems a bit safer. I
think that the current settings for the repository locations in trunk
might actually be (almost) sufficient.
I think we should make one change: instead of the current values ([1]
and [2]), I think we should use the following:
scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-
repo
scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-
site
Thoughts?
-Patrick
[1] scp://people.apache.org/home/${user.name}/public_html/openjpa/$
{pom.version}/staging-repo
[2] scp://people.apache.org/home/${user.name}/public_html/openjpa/$
{pom.version}/staging-site
On Jul 21, 2008, at 8:48 AM, Michael Dick wrote:
> Hi,
>
> I gave this a quick test and it looks like it's working, here's
> exactly what
> I ran :
>
> $ mvn -Dmaven.test.skip=true deploy
> -DaltDeploymentRepository=myserver::default::scp://
> myserver.myhost.com/home/mikedd/temp22
>
> $ mvn -Dmaven.test.skip=true site:stage-deploy
> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>
> I think a similar set of arguments can be used for the release
> process.
>
> Here's what I propose, after the 1.0.3 release is approved I'll
> update the
> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The
> changes
> will be to update the default deploy location to be
> openjpa.apache.org/builds/latest/${version} (or something similar).
> That way
> the automated build system will go ahead and publish to the latest
> directory
> with no need for command line arguments.
>
> In the release profile we'll change the deployment location to be
> people.apache.org/${user}/public_html/. . . so that the release is
> publicly
> available. If we can't override the location via the profile I'll
> update the
> instructions to pass it along as a command line arg.
>
> If this sounds acceptable to everyone else I'll go ahead and open
> another
> JIRA (633 has enough changes).
>
> -mike
>
>
>
>
> On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org>
> wrote:
>
>> Hi Patrick,
>>
>> If you're looking to upload a snapshot to say your home directory on
>> people.apache.org you can just run
>> $ mvn deploy
>>
>> I think we'd rather have the snapshots deployed to our builds
>> directory though. Something like this should work (untested)
>> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D
>> >
>> deploy
>>
>> You'll need to add a server tag for people.apache.org to your
>> ${home}/.m2/settings.xml file. Something like this should work:
>>
>> <servers>
>> <server>
>> <id>people.apache.org</id>
>> <username>[your apache id]</username>
>> <passphrase>[secret passphrase]</passphrase>
>> <filePermissions>664</filePermissions>
>> <directoryPermissions>775</directoryPermissions>
>> </server>
>> </servers>
>>
>> The preceding examples will upload our maven artifacts. To deploy the
>> site I *think* this would work
>>
>> $ mvn -DstagingSiteURL=scp://
>> people.apache.org/www/openjpa.apache.org/builds/${version}
>> site:stage-deploy<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy
>> >
>>
>> I'll take a closer look when time permits, this should be a starting
>> point though.
>>
>> -mike
>>
>> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to get the snapshot process working as closely to the new
>> release process as possible. From what I can tell, mvn
>> release:prepare is
>> really oriented towards releases, not towards snapshots. Does
>> anyone know of
>> an equivalent snapshot target that we could use?
>>>
>>> -Patrick
>>>
>>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>>>
>>>> Sounds good, Patrick. So, in the mean time, should I make a
>>>> temporary
>>>> repository for the "latest" docs? Or, if you think this will get
>> resolved
>>>> in the next day or two, then I could just wait.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <plinskey@gmail.com
>>>> >
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think that this is because the machine that builds and uploads
>>>>> the
>>>>> snapshots was offline for the last couple of months. I got that
>> partially
>>>>> back up and running last week, and hope to get the snapshots
>>>>> uploading
>> again
>>>>> later this week.
>>>>>
>>>>> -Patrick
>>>>>
>>>>>
>>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I just noticed that our links for the "latest" OpenJPA
>>>>>> documentation
>> is
>>>>>> out
>>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>> would
>>>>>> expect that our "latest" link should point at some version of
>>>>>> documentation
>>>>>> associated with trunk. But, it's currently pointing at some
>>>>>> version
>> based
>>>>>> on the 1.1.0 build. I was going to go ahead and clean this up,
>>>>>> but it
>>>>>> looks
>>>>>> like I don't have proper authority to the /www/
>>>>>> openjpa.apache.org/docs/latest directory. It looks like
>>>>>> Patrick is
>> the
>>>>>> only
>>>>>> one with enough authority.
>>>>>>
>>>>>> This "latest" directory is currently linked to this: latest ->
>>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>>>
>>>>>> So, I'm thinking a few things need to be done:
>>>>>>
>>>>>> o It would be great to post our current nightly drivers and
>> documentation
>>>>>> out on people.apache.org from our TC system. (BTW, it looks
>>>>>> like our
>>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT
>>>>>> builds,
>> so we
>>>>>> have some clean up there as well.) I'm not sure on the status of
>>>>>> Patrick's
>>>>>> TC system and whether we are able to get something like this
>>>>>> setup or
>> not.
>>>>>>
>>>>>> o If we can post our nightly drivers and documentation, then
>>>>>> we could
>>>>>> change this "latest" directory link to our upload location for
>>>>>> the
>>>>>> drivers.
>>>>>>
>>>>>> o If this type of clean up and setup of nightly drivers is
>>>>>> going to
>> take
>>>>>> some time, then at a minimum, it would be good to change the
>> permissions
>>>>>> on
>>>>>> this "latest" directory so that we could do some manual (pardon
>>>>>> the
>> pun)
>>>>>> cleanup.
>>>>>>
>>>>>> BTW, all of this came about because I had pointed a user at our
>> "latest"
>>>>>> manual to find out how to turn on the Query SQL Cache support
>>>>>> (knowing
>> it
>>>>>> was part of the 1.2.0 trunk release). But, I soon discovered
>>>>>> that our
>>>>>> "latest" manual is quite out of date... :-)
>>>>>>
>>>>>> Thanks,
>>>>>> Kevin
>>>>>>
>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>
--
Patrick Linskey
202 669 5907
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Michael Dick <mi...@apache.org>.
On Wed, Jul 23, 2008 at 9:33 AM, Michael Dick <mi...@apache.org> wrote:
> On Tue, Jul 22, 2008 at 5:53 PM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
>> $ mvn -Dmaven.test.skip=true deploy
>>> -DaltDeploymentRepository=myserver::default::scp://
>>> myserver.myhost.com/home/mikedd/temp22
>>>
>>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>>
>>
>> Interesting -- I didn't know you could pass in overrides like that.
>>
>
> Depends on the plugin ;-). I think we can request similar parameters to
> other plugins if we have a compelling use case(s).
>
>>
>>
>> Here's what I propose, after the 1.0.3 release is approved I'll update
>>> the
>>> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The changes
>>> will be to update the default deploy location to be
>>> openjpa.apache.org/builds/latest/${version}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(or something similar). That way
>>> the automated build system will go ahead and publish to the latest
>>> directory
>>> with no need for command line arguments.
>>>
>>
>> I've got changes to the trunk pom.xml that does something much like that
>> right now (without the 'latest' dir); it failed to run from the autobuild on
>> Friday, and I was at a pre-OSCON event yesterday, but am hoping to figure
>> out why not today.
>>
>>
>> In the release profile we'll change the deployment location to be
>>> people.apache.org/${user}/public_html/<http://people.apache.org/$%7Buser%7D/public_html/>.
>>> . . so that the release is publicly
>>> available. If we can't override the location via the profile I'll update
>>> the
>>> instructions to pass it along as a command line arg.
>>>
>>
>> Knowing that we can pass overrides into mvn, I think that there's a case
>> to be made for having the defaults be to put contents into the user's
>> homedir, and then have the snapshot process and the release process override
>> the values as appropriate. That seems a bit safer. I think that the current
>> settings for the repository locations in trunk might actually be (almost)
>> sufficient.
>>
>
> You're right that's probably safer. We should be able to specify the
> options in a <profile> in pom.xml. So the maven invocation would look like :
> $ mvn -Pnightly-build deploy
>
> $ mvn -Prelease release:prepare
> // etc.
>
>
>> I think we should make one change: instead of the current values ([1] and
>> [2]), I think we should use the following:
>>
>> scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
>> repo
>> scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
>> site
>>
>
> I put the pom.version directory in the location to account for the corner
> case where a single release manager has published more than one version at
> the same time. For example if I had submitted a vote for 1.2.0 on Monday
> there would be 1.0.3 and 1.2.0 candidates in the same staging repository. At
> the end of the process when we run mvn stage:deploy I believe both versions
> would be copied to the ibiblio rsync repository.
>
> I think this is a known issue with the stage plugin which should be fixed
> in the near future, but with all the other changes for the release process I
> didn't want to add another point of failure.
>
> Admittedly this is a corner case, but once something is in the ibiblio
> repository it's very hard to remove it.
>
I didn't notice that you suggested removing the openjpa directory too. That
part seems OK with me, it's really only useful if you're releasing another
project at the same time.
>
> -mike
>
>
>> Thoughts?
>>
>> -Patrick
>>
>> [1] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
>> {pom.version}/
>>>
>>> staging-repo
>>> [2] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
>>> {pom.version}/staging-site
>>
>>
>
> On Wed, Jul 23, 2008 at 9:17 AM, Michael Dick <mi...@apache.org> wrote:
>
>> Comments inline below
>>
>> On Tue, Jul 22, 2008 at 5:57 PM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>
>>> A few questions, since it looks like you might grok this mvn thing better
>>> than I:
>>>
>>> $ mvn -Dmaven.test.skip=true deploy
>>>> -DaltDeploymentRepository=myserver::default::scp://
>>>> myserver.myhost.com/home/mikedd/temp22
>>>>
>>>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>>>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>>>
>>>
>>> What is the difference between site:deploy ad site:stage-deploy? Is it
>>> just a matter of which location it gets deployed to?
>>>
>>
>> It's just a matter of where the site is deployed. The site:deploy goal
>> doesn't allow you to override the destination. We might be able to work
>> around this by using a variable in pom.xml to specify the site location, but
>> from what I've seen the release plugin expands many of the variables when
>> you do a release.
>>
>>
>>
>>>
>>> What's with the myserver::default:: syntax?
>>>
>>
>> The definition is ${serverId}::${layout}::${scp.location}. ServerId is a
>> server defined in .m2/settings.xml. Maven uses the server id to authenticate
>> and determine default file permissions, etc. Layout is used to differentiate
>> between a maven1 and maven2 repository (default is maven2).
>>
>> -Mike
>>
>>
>>> Thanks,
>>>
>>> -Patrick
>>>
>>> On Jul 21, 2008, at 8:48 AM, Michael Dick wrote:
>>>
>>> Hi,
>>>>
>>>> I gave this a quick test and it looks like it's working, here's exactly
>>>> what
>>>> I ran :
>>>>
>>>> $ mvn -Dmaven.test.skip=true deploy
>>>> -DaltDeploymentRepository=myserver::default::scp://
>>>> myserver.myhost.com/home/mikedd/temp22
>>>>
>>>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>>>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>>>
>>>> I think a similar set of arguments can be used for the release process.
>>>>
>>>> Here's what I propose, after the 1.0.3 release is approved I'll update
>>>> the
>>>> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The
>>>> changes
>>>> will be to update the default deploy location to be
>>>> openjpa.apache.org/builds/latest/${version}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(or something similar). That way
>>>> the automated build system will go ahead and publish to the latest
>>>> directory
>>>> with no need for command line arguments.
>>>>
>>>> In the release profile we'll change the deployment location to be
>>>> people.apache.org/${user}/public_html/<http://people.apache.org/$%7Buser%7D/public_html/>.
>>>> . . so that the release is publicly
>>>> available. If we can't override the location via the profile I'll update
>>>> the
>>>> instructions to pass it along as a command line arg.
>>>>
>>>> If this sounds acceptable to everyone else I'll go ahead and open
>>>> another
>>>> JIRA (633 has enough changes).
>>>>
>>>> -mike
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org>
>>>> wrote:
>>>>
>>>> Hi Patrick,
>>>>>
>>>>> If you're looking to upload a snapshot to say your home directory on
>>>>> people.apache.org you can just run
>>>>> $ mvn deploy
>>>>>
>>>>> I think we'd rather have the snapshots deployed to our builds
>>>>> directory though. Something like this should work (untested)
>>>>> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
>>>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>>> <http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D
>>>>> >
>>>>> deploy
>>>>>
>>>>> You'll need to add a server tag for people.apache.org to your
>>>>> ${home}/.m2/settings.xml file. Something like this should work:
>>>>>
>>>>> <servers>
>>>>> <server>
>>>>> <id>people.apache.org</id>
>>>>> <username>[your apache id]</username>
>>>>> <passphrase>[secret passphrase]</passphrase>
>>>>> <filePermissions>664</filePermissions>
>>>>> <directoryPermissions>775</directoryPermissions>
>>>>> </server>
>>>>> </servers>
>>>>>
>>>>> The preceding examples will upload our maven artifacts. To deploy the
>>>>> site I *think* this would work
>>>>>
>>>>> $ mvn -DstagingSiteURL=scp://
>>>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>>> site:stage-deploy<
>>>>> http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy
>>>>> >
>>>>>
>>>>>
>>>>> I'll take a closer look when time permits, this should be a starting
>>>>> point though.
>>>>>
>>>>> -mike
>>>>>
>>>>> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to get the snapshot process working as closely to the new
>>>>>>
>>>>> release process as possible. From what I can tell, mvn release:prepare
>>>>> is
>>>>> really oriented towards releases, not towards snapshots. Does anyone
>>>>> know of
>>>>> an equivalent snapshot target that we could use?
>>>>>
>>>>>>
>>>>>> -Patrick
>>>>>>
>>>>>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>>>>>>
>>>>>> Sounds good, Patrick. So, in the mean time, should I make a
>>>>>>> temporary
>>>>>>> repository for the "latest" docs? Or, if you think this will get
>>>>>>>
>>>>>> resolved
>>>>>
>>>>>> in the next day or two, then I could just wait.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kevin
>>>>>>>
>>>>>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <plinskey@gmail.com
>>>>>>> >
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think that this is because the machine that builds and uploads the
>>>>>>>> snapshots was offline for the last couple of months. I got that
>>>>>>>>
>>>>>>> partially
>>>>>
>>>>>> back up and running last week, and hope to get the snapshots
>>>>>>>> uploading
>>>>>>>>
>>>>>>> again
>>>>>
>>>>>> later this week.
>>>>>>>>
>>>>>>>> -Patrick
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just noticed that our links for the "latest" OpenJPA
>>>>>>>>> documentation
>>>>>>>>>
>>>>>>>> is
>>>>>
>>>>>> out
>>>>>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>>>>>>>>>
>>>>>>>> would
>>>>>
>>>>>> expect that our "latest" link should point at some version of
>>>>>>>>> documentation
>>>>>>>>> associated with trunk. But, it's currently pointing at some
>>>>>>>>> version
>>>>>>>>>
>>>>>>>> based
>>>>>
>>>>>> on the 1.1.0 build. I was going to go ahead and clean this up, but
>>>>>>>>> it
>>>>>>>>> looks
>>>>>>>>> like I don't have proper authority to the /www/
>>>>>>>>> openjpa.apache.org/docs/latest directory. It looks like Patrick
>>>>>>>>> is
>>>>>>>>>
>>>>>>>> the
>>>>>
>>>>>> only
>>>>>>>>> one with enough authority.
>>>>>>>>>
>>>>>>>>> This "latest" directory is currently linked to this: latest ->
>>>>>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>>>>>>
>>>>>>>>> So, I'm thinking a few things need to be done:
>>>>>>>>>
>>>>>>>>> o It would be great to post our current nightly drivers and
>>>>>>>>>
>>>>>>>> documentation
>>>>>
>>>>>> out on people.apache.org from our TC system. (BTW, it looks like
>>>>>>>>> our
>>>>>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT
>>>>>>>>> builds,
>>>>>>>>>
>>>>>>>> so we
>>>>>
>>>>>> have some clean up there as well.) I'm not sure on the status of
>>>>>>>>> Patrick's
>>>>>>>>> TC system and whether we are able to get something like this setup
>>>>>>>>> or
>>>>>>>>>
>>>>>>>> not.
>>>>>
>>>>>>
>>>>>>>>> o If we can post our nightly drivers and documentation, then we
>>>>>>>>> could
>>>>>>>>> change this "latest" directory link to our upload location for the
>>>>>>>>> drivers.
>>>>>>>>>
>>>>>>>>> o If this type of clean up and setup of nightly drivers is going
>>>>>>>>> to
>>>>>>>>>
>>>>>>>> take
>>>>>
>>>>>> some time, then at a minimum, it would be good to change the
>>>>>>>>>
>>>>>>>> permissions
>>>>>
>>>>>> on
>>>>>>>>> this "latest" directory so that we could do some manual (pardon the
>>>>>>>>>
>>>>>>>> pun)
>>>>>
>>>>>> cleanup.
>>>>>>>>>
>>>>>>>>> BTW, all of this came about because I had pointed a user at our
>>>>>>>>>
>>>>>>>> "latest"
>>>>>
>>>>>> manual to find out how to turn on the Query SQL Cache support
>>>>>>>>> (knowing
>>>>>>>>>
>>>>>>>> it
>>>>>
>>>>>> was part of the 1.2.0 trunk release). But, I soon discovered that
>>>>>>>>> our
>>>>>>>>> "latest" manual is quite out of date... :-)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Patrick Linskey
>>>>>>>> 202 669 5907
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Patrick Linskey
>>>>>> 202 669 5907
>>>>>>
>>>>>>
>>>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>>
>>
>
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Michael Dick <mi...@apache.org>.
On Tue, Jul 22, 2008 at 5:53 PM, Patrick Linskey <pl...@gmail.com> wrote:
> $ mvn -Dmaven.test.skip=true deploy
>> -DaltDeploymentRepository=myserver::default::scp://
>> myserver.myhost.com/home/mikedd/temp22
>>
>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>
>
> Interesting -- I didn't know you could pass in overrides like that.
Depends on the plugin ;-). I think we can request similar parameters to
other plugins if we have a compelling use case(s).
>
>
> Here's what I propose, after the 1.0.3 release is approved I'll update the
>> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The changes
>> will be to update the default deploy location to be
>> openjpa.apache.org/builds/latest/${version}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(or something similar). That way
>> the automated build system will go ahead and publish to the latest
>> directory
>> with no need for command line arguments.
>>
>
> I've got changes to the trunk pom.xml that does something much like that
> right now (without the 'latest' dir); it failed to run from the autobuild on
> Friday, and I was at a pre-OSCON event yesterday, but am hoping to figure
> out why not today.
>
> In the release profile we'll change the deployment location to be
>> people.apache.org/${user}/public_html/<http://people.apache.org/$%7Buser%7D/public_html/>.
>> . . so that the release is publicly
>> available. If we can't override the location via the profile I'll update
>> the
>> instructions to pass it along as a command line arg.
>>
>
> Knowing that we can pass overrides into mvn, I think that there's a case to
> be made for having the defaults be to put contents into the user's homedir,
> and then have the snapshot process and the release process override the
> values as appropriate. That seems a bit safer. I think that the current
> settings for the repository locations in trunk might actually be (almost)
> sufficient.
You're right that's probably safer. We should be able to specify the options
in a <profile> in pom.xml. So the maven invocation would look like :
$ mvn -Pnightly-build deploy
$ mvn -Prelease release:prepare
// etc.
> I think we should make one change: instead of the current values ([1] and
> [2]), I think we should use the following:
>
> scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
> repo
> scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
> site
>
I put the pom.version directory in the location to account for the corner
case where a single release manager has published more than one version at
the same time. For example if I had submitted a vote for 1.2.0 on Monday
there would be 1.0.3 and 1.2.0 candidates in the same staging repository. At
the end of the process when we run mvn stage:deploy I believe both versions
would be copied to the ibiblio rsync repository.
I think this is a known issue with the stage plugin which should be fixed in
the near future, but with all the other changes for the release process I
didn't want to add another point of failure.
Admittedly this is a corner case, but once something is in the ibiblio
repository it's very hard to remove it.
-mike
> Thoughts?
>
> -Patrick
>
> [1] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
> {pom.version}/
>>
>> staging-repo
>> [2] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
>> {pom.version}/staging-site
>
>
On Wed, Jul 23, 2008 at 9:17 AM, Michael Dick <mi...@apache.org> wrote:
> Comments inline below
>
> On Tue, Jul 22, 2008 at 5:57 PM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
>> A few questions, since it looks like you might grok this mvn thing better
>> than I:
>>
>> $ mvn -Dmaven.test.skip=true deploy
>>> -DaltDeploymentRepository=myserver::default::scp://
>>> myserver.myhost.com/home/mikedd/temp22
>>>
>>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>>
>>
>> What is the difference between site:deploy ad site:stage-deploy? Is it
>> just a matter of which location it gets deployed to?
>>
>
> It's just a matter of where the site is deployed. The site:deploy goal
> doesn't allow you to override the destination. We might be able to work
> around this by using a variable in pom.xml to specify the site location, but
> from what I've seen the release plugin expands many of the variables when
> you do a release.
>
>
>
>>
>> What's with the myserver::default:: syntax?
>>
>
> The definition is ${serverId}::${layout}::${scp.location}. ServerId is a
> server defined in .m2/settings.xml. Maven uses the server id to authenticate
> and determine default file permissions, etc. Layout is used to differentiate
> between a maven1 and maven2 repository (default is maven2).
>
> -Mike
>
>
>> Thanks,
>>
>> -Patrick
>>
>> On Jul 21, 2008, at 8:48 AM, Michael Dick wrote:
>>
>> Hi,
>>>
>>> I gave this a quick test and it looks like it's working, here's exactly
>>> what
>>> I ran :
>>>
>>> $ mvn -Dmaven.test.skip=true deploy
>>> -DaltDeploymentRepository=myserver::default::scp://
>>> myserver.myhost.com/home/mikedd/temp22
>>>
>>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>>
>>> I think a similar set of arguments can be used for the release process.
>>>
>>> Here's what I propose, after the 1.0.3 release is approved I'll update
>>> the
>>> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The changes
>>> will be to update the default deploy location to be
>>> openjpa.apache.org/builds/latest/${version}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(or something similar). That way
>>> the automated build system will go ahead and publish to the latest
>>> directory
>>> with no need for command line arguments.
>>>
>>> In the release profile we'll change the deployment location to be
>>> people.apache.org/${user}/public_html/<http://people.apache.org/$%7Buser%7D/public_html/>.
>>> . . so that the release is publicly
>>> available. If we can't override the location via the profile I'll update
>>> the
>>> instructions to pass it along as a command line arg.
>>>
>>> If this sounds acceptable to everyone else I'll go ahead and open another
>>> JIRA (633 has enough changes).
>>>
>>> -mike
>>>
>>>
>>>
>>>
>>> On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org>
>>> wrote:
>>>
>>> Hi Patrick,
>>>>
>>>> If you're looking to upload a snapshot to say your home directory on
>>>> people.apache.org you can just run
>>>> $ mvn deploy
>>>>
>>>> I think we'd rather have the snapshots deployed to our builds
>>>> directory though. Something like this should work (untested)
>>>> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
>>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>> <http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>> deploy
>>>>
>>>> You'll need to add a server tag for people.apache.org to your
>>>> ${home}/.m2/settings.xml file. Something like this should work:
>>>>
>>>> <servers>
>>>> <server>
>>>> <id>people.apache.org</id>
>>>> <username>[your apache id]</username>
>>>> <passphrase>[secret passphrase]</passphrase>
>>>> <filePermissions>664</filePermissions>
>>>> <directoryPermissions>775</directoryPermissions>
>>>> </server>
>>>> </servers>
>>>>
>>>> The preceding examples will upload our maven artifacts. To deploy the
>>>> site I *think* this would work
>>>>
>>>> $ mvn -DstagingSiteURL=scp://
>>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>> site:stage-deploy<
>>>> http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy
>>>> >
>>>>
>>>>
>>>> I'll take a closer look when time permits, this should be a starting
>>>> point though.
>>>>
>>>> -mike
>>>>
>>>> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to get the snapshot process working as closely to the new
>>>>>
>>>> release process as possible. From what I can tell, mvn release:prepare
>>>> is
>>>> really oriented towards releases, not towards snapshots. Does anyone
>>>> know of
>>>> an equivalent snapshot target that we could use?
>>>>
>>>>>
>>>>> -Patrick
>>>>>
>>>>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>>>>>
>>>>> Sounds good, Patrick. So, in the mean time, should I make a temporary
>>>>>> repository for the "latest" docs? Or, if you think this will get
>>>>>>
>>>>> resolved
>>>>
>>>>> in the next day or two, then I could just wait.
>>>>>>
>>>>>> Thanks,
>>>>>> Kevin
>>>>>>
>>>>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <pl...@gmail.com>
>>>>>>
>>>>> wrote:
>>>>
>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> I think that this is because the machine that builds and uploads the
>>>>>>> snapshots was offline for the last couple of months. I got that
>>>>>>>
>>>>>> partially
>>>>
>>>>> back up and running last week, and hope to get the snapshots uploading
>>>>>>>
>>>>>> again
>>>>
>>>>> later this week.
>>>>>>>
>>>>>>> -Patrick
>>>>>>>
>>>>>>>
>>>>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>
>>>>>>>> I just noticed that our links for the "latest" OpenJPA documentation
>>>>>>>>
>>>>>>> is
>>>>
>>>>> out
>>>>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>>>>>>>>
>>>>>>> would
>>>>
>>>>> expect that our "latest" link should point at some version of
>>>>>>>> documentation
>>>>>>>> associated with trunk. But, it's currently pointing at some version
>>>>>>>>
>>>>>>> based
>>>>
>>>>> on the 1.1.0 build. I was going to go ahead and clean this up, but it
>>>>>>>> looks
>>>>>>>> like I don't have proper authority to the /www/
>>>>>>>> openjpa.apache.org/docs/latest directory. It looks like Patrick is
>>>>>>>>
>>>>>>> the
>>>>
>>>>> only
>>>>>>>> one with enough authority.
>>>>>>>>
>>>>>>>> This "latest" directory is currently linked to this: latest ->
>>>>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>>>>>
>>>>>>>> So, I'm thinking a few things need to be done:
>>>>>>>>
>>>>>>>> o It would be great to post our current nightly drivers and
>>>>>>>>
>>>>>>> documentation
>>>>
>>>>> out on people.apache.org from our TC system. (BTW, it looks like our
>>>>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT builds,
>>>>>>>>
>>>>>>> so we
>>>>
>>>>> have some clean up there as well.) I'm not sure on the status of
>>>>>>>> Patrick's
>>>>>>>> TC system and whether we are able to get something like this setup
>>>>>>>> or
>>>>>>>>
>>>>>>> not.
>>>>
>>>>>
>>>>>>>> o If we can post our nightly drivers and documentation, then we
>>>>>>>> could
>>>>>>>> change this "latest" directory link to our upload location for the
>>>>>>>> drivers.
>>>>>>>>
>>>>>>>> o If this type of clean up and setup of nightly drivers is going to
>>>>>>>>
>>>>>>> take
>>>>
>>>>> some time, then at a minimum, it would be good to change the
>>>>>>>>
>>>>>>> permissions
>>>>
>>>>> on
>>>>>>>> this "latest" directory so that we could do some manual (pardon the
>>>>>>>>
>>>>>>> pun)
>>>>
>>>>> cleanup.
>>>>>>>>
>>>>>>>> BTW, all of this came about because I had pointed a user at our
>>>>>>>>
>>>>>>> "latest"
>>>>
>>>>> manual to find out how to turn on the Query SQL Cache support (knowing
>>>>>>>>
>>>>>>> it
>>>>
>>>>> was part of the 1.2.0 trunk release). But, I soon discovered that our
>>>>>>>> "latest" manual is quite out of date... :-)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Kevin
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Patrick Linskey
>>>>>>> 202 669 5907
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>>
>>>>
>> --
>> Patrick Linskey
>> 202 669 5907
>>
>>
>
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Michael Dick <mi...@apache.org>.
Comments inline below
On Tue, Jul 22, 2008 at 5:57 PM, Patrick Linskey <pl...@gmail.com> wrote:
> A few questions, since it looks like you might grok this mvn thing better
> than I:
>
> $ mvn -Dmaven.test.skip=true deploy
>> -DaltDeploymentRepository=myserver::default::scp://
>> myserver.myhost.com/home/mikedd/temp22
>>
>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>
>
> What is the difference between site:deploy ad site:stage-deploy? Is it just
> a matter of which location it gets deployed to?
>
It's just a matter of where the site is deployed. The site:deploy goal
doesn't allow you to override the destination. We might be able to work
around this by using a variable in pom.xml to specify the site location, but
from what I've seen the release plugin expands many of the variables when
you do a release.
>
> What's with the myserver::default:: syntax?
>
The definition is ${serverId}::${layout}::${scp.location}. ServerId is a
server defined in .m2/settings.xml. Maven uses the server id to authenticate
and determine default file permissions, etc. Layout is used to differentiate
between a maven1 and maven2 repository (default is maven2).
-Mike
> Thanks,
>
> -Patrick
>
> On Jul 21, 2008, at 8:48 AM, Michael Dick wrote:
>
> Hi,
>>
>> I gave this a quick test and it looks like it's working, here's exactly
>> what
>> I ran :
>>
>> $ mvn -Dmaven.test.skip=true deploy
>> -DaltDeploymentRepository=myserver::default::scp://
>> myserver.myhost.com/home/mikedd/temp22
>>
>> $ mvn -Dmaven.test.skip=true site:stage-deploy
>> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>>
>> I think a similar set of arguments can be used for the release process.
>>
>> Here's what I propose, after the 1.0.3 release is approved I'll update the
>> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The changes
>> will be to update the default deploy location to be
>> openjpa.apache.org/builds/latest/${version}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(or something similar). That way
>> the automated build system will go ahead and publish to the latest
>> directory
>> with no need for command line arguments.
>>
>> In the release profile we'll change the deployment location to be
>> people.apache.org/${user}/public_html/<http://people.apache.org/$%7Buser%7D/public_html/>.
>> . . so that the release is publicly
>> available. If we can't override the location via the profile I'll update
>> the
>> instructions to pass it along as a command line arg.
>>
>> If this sounds acceptable to everyone else I'll go ahead and open another
>> JIRA (633 has enough changes).
>>
>> -mike
>>
>>
>>
>>
>> On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org> wrote:
>>
>> Hi Patrick,
>>>
>>> If you're looking to upload a snapshot to say your home directory on
>>> people.apache.org you can just run
>>> $ mvn deploy
>>>
>>> I think we'd rather have the snapshots deployed to our builds
>>> directory though. Something like this should work (untested)
>>> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>> <http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>> deploy
>>>
>>> You'll need to add a server tag for people.apache.org to your
>>> ${home}/.m2/settings.xml file. Something like this should work:
>>>
>>> <servers>
>>> <server>
>>> <id>people.apache.org</id>
>>> <username>[your apache id]</username>
>>> <passphrase>[secret passphrase]</passphrase>
>>> <filePermissions>664</filePermissions>
>>> <directoryPermissions>775</directoryPermissions>
>>> </server>
>>> </servers>
>>>
>>> The preceding examples will upload our maven artifacts. To deploy the
>>> site I *think* this would work
>>>
>>> $ mvn -DstagingSiteURL=scp://
>>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>> site:stage-deploy<
>>> http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy
>>> >
>>>
>>>
>>> I'll take a closer look when time permits, this should be a starting
>>> point though.
>>>
>>> -mike
>>>
>>> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm trying to get the snapshot process working as closely to the new
>>>>
>>> release process as possible. From what I can tell, mvn release:prepare is
>>> really oriented towards releases, not towards snapshots. Does anyone know
>>> of
>>> an equivalent snapshot target that we could use?
>>>
>>>>
>>>> -Patrick
>>>>
>>>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>>>>
>>>> Sounds good, Patrick. So, in the mean time, should I make a temporary
>>>>> repository for the "latest" docs? Or, if you think this will get
>>>>>
>>>> resolved
>>>
>>>> in the next day or two, then I could just wait.
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <pl...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>> Hi,
>>>>>>
>>>>>> I think that this is because the machine that builds and uploads the
>>>>>> snapshots was offline for the last couple of months. I got that
>>>>>>
>>>>> partially
>>>
>>>> back up and running last week, and hope to get the snapshots uploading
>>>>>>
>>>>> again
>>>
>>>> later this week.
>>>>>>
>>>>>> -Patrick
>>>>>>
>>>>>>
>>>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>>
>>>>>>> I just noticed that our links for the "latest" OpenJPA documentation
>>>>>>>
>>>>>> is
>>>
>>>> out
>>>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>>>>>>>
>>>>>> would
>>>
>>>> expect that our "latest" link should point at some version of
>>>>>>> documentation
>>>>>>> associated with trunk. But, it's currently pointing at some version
>>>>>>>
>>>>>> based
>>>
>>>> on the 1.1.0 build. I was going to go ahead and clean this up, but it
>>>>>>> looks
>>>>>>> like I don't have proper authority to the /www/
>>>>>>> openjpa.apache.org/docs/latest directory. It looks like Patrick is
>>>>>>>
>>>>>> the
>>>
>>>> only
>>>>>>> one with enough authority.
>>>>>>>
>>>>>>> This "latest" directory is currently linked to this: latest ->
>>>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>>>>
>>>>>>> So, I'm thinking a few things need to be done:
>>>>>>>
>>>>>>> o It would be great to post our current nightly drivers and
>>>>>>>
>>>>>> documentation
>>>
>>>> out on people.apache.org from our TC system. (BTW, it looks like our
>>>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT builds,
>>>>>>>
>>>>>> so we
>>>
>>>> have some clean up there as well.) I'm not sure on the status of
>>>>>>> Patrick's
>>>>>>> TC system and whether we are able to get something like this setup or
>>>>>>>
>>>>>> not.
>>>
>>>>
>>>>>>> o If we can post our nightly drivers and documentation, then we
>>>>>>> could
>>>>>>> change this "latest" directory link to our upload location for the
>>>>>>> drivers.
>>>>>>>
>>>>>>> o If this type of clean up and setup of nightly drivers is going to
>>>>>>>
>>>>>> take
>>>
>>>> some time, then at a minimum, it would be good to change the
>>>>>>>
>>>>>> permissions
>>>
>>>> on
>>>>>>> this "latest" directory so that we could do some manual (pardon the
>>>>>>>
>>>>>> pun)
>>>
>>>> cleanup.
>>>>>>>
>>>>>>> BTW, all of this came about because I had pointed a user at our
>>>>>>>
>>>>>> "latest"
>>>
>>>> manual to find out how to turn on the Query SQL Cache support (knowing
>>>>>>>
>>>>>> it
>>>
>>>> was part of the 1.2.0 trunk release). But, I soon discovered that our
>>>>>>> "latest" manual is quite out of date... :-)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kevin
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Patrick Linskey
>>>>>> 202 669 5907
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Patrick Linskey
>>>> 202 669 5907
>>>>
>>>>
>>>
> --
> Patrick Linskey
> 202 669 5907
>
>
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Patrick Linskey <pl...@gmail.com>.
A few questions, since it looks like you might grok this mvn thing
better than I:
> $ mvn -Dmaven.test.skip=true deploy
> -DaltDeploymentRepository=myserver::default::scp://
> myserver.myhost.com/home/mikedd/temp22
>
> $ mvn -Dmaven.test.skip=true site:stage-deploy
> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
What is the difference between site:deploy ad site:stage-deploy? Is it
just a matter of which location it gets deployed to?
What's with the myserver::default:: syntax?
Thanks,
-Patrick
On Jul 21, 2008, at 8:48 AM, Michael Dick wrote:
> Hi,
>
> I gave this a quick test and it looks like it's working, here's
> exactly what
> I ran :
>
> $ mvn -Dmaven.test.skip=true deploy
> -DaltDeploymentRepository=myserver::default::scp://
> myserver.myhost.com/home/mikedd/temp22
>
> $ mvn -Dmaven.test.skip=true site:stage-deploy
> -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
>
> I think a similar set of arguments can be used for the release
> process.
>
> Here's what I propose, after the 1.0.3 release is approved I'll
> update the
> pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The
> changes
> will be to update the default deploy location to be
> openjpa.apache.org/builds/latest/${version} (or something similar).
> That way
> the automated build system will go ahead and publish to the latest
> directory
> with no need for command line arguments.
>
> In the release profile we'll change the deployment location to be
> people.apache.org/${user}/public_html/. . . so that the release is
> publicly
> available. If we can't override the location via the profile I'll
> update the
> instructions to pass it along as a command line arg.
>
> If this sounds acceptable to everyone else I'll go ahead and open
> another
> JIRA (633 has enough changes).
>
> -mike
>
>
>
>
> On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org>
> wrote:
>
>> Hi Patrick,
>>
>> If you're looking to upload a snapshot to say your home directory on
>> people.apache.org you can just run
>> $ mvn deploy
>>
>> I think we'd rather have the snapshots deployed to our builds
>> directory though. Something like this should work (untested)
>> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
>> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D
>> >
>> deploy
>>
>> You'll need to add a server tag for people.apache.org to your
>> ${home}/.m2/settings.xml file. Something like this should work:
>>
>> <servers>
>> <server>
>> <id>people.apache.org</id>
>> <username>[your apache id]</username>
>> <passphrase>[secret passphrase]</passphrase>
>> <filePermissions>664</filePermissions>
>> <directoryPermissions>775</directoryPermissions>
>> </server>
>> </servers>
>>
>> The preceding examples will upload our maven artifacts. To deploy the
>> site I *think* this would work
>>
>> $ mvn -DstagingSiteURL=scp://
>> people.apache.org/www/openjpa.apache.org/builds/${version}
>> site:stage-deploy<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy
>> >
>>
>> I'll take a closer look when time permits, this should be a starting
>> point though.
>>
>> -mike
>>
>> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to get the snapshot process working as closely to the new
>> release process as possible. From what I can tell, mvn
>> release:prepare is
>> really oriented towards releases, not towards snapshots. Does
>> anyone know of
>> an equivalent snapshot target that we could use?
>>>
>>> -Patrick
>>>
>>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>>>
>>>> Sounds good, Patrick. So, in the mean time, should I make a
>>>> temporary
>>>> repository for the "latest" docs? Or, if you think this will get
>> resolved
>>>> in the next day or two, then I could just wait.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <plinskey@gmail.com
>>>> >
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think that this is because the machine that builds and uploads
>>>>> the
>>>>> snapshots was offline for the last couple of months. I got that
>> partially
>>>>> back up and running last week, and hope to get the snapshots
>>>>> uploading
>> again
>>>>> later this week.
>>>>>
>>>>> -Patrick
>>>>>
>>>>>
>>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> I just noticed that our links for the "latest" OpenJPA
>>>>>> documentation
>> is
>>>>>> out
>>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
>> would
>>>>>> expect that our "latest" link should point at some version of
>>>>>> documentation
>>>>>> associated with trunk. But, it's currently pointing at some
>>>>>> version
>> based
>>>>>> on the 1.1.0 build. I was going to go ahead and clean this up,
>>>>>> but it
>>>>>> looks
>>>>>> like I don't have proper authority to the /www/
>>>>>> openjpa.apache.org/docs/latest directory. It looks like
>>>>>> Patrick is
>> the
>>>>>> only
>>>>>> one with enough authority.
>>>>>>
>>>>>> This "latest" directory is currently linked to this: latest ->
>>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>>>
>>>>>> So, I'm thinking a few things need to be done:
>>>>>>
>>>>>> o It would be great to post our current nightly drivers and
>> documentation
>>>>>> out on people.apache.org from our TC system. (BTW, it looks
>>>>>> like our
>>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT
>>>>>> builds,
>> so we
>>>>>> have some clean up there as well.) I'm not sure on the status of
>>>>>> Patrick's
>>>>>> TC system and whether we are able to get something like this
>>>>>> setup or
>> not.
>>>>>>
>>>>>> o If we can post our nightly drivers and documentation, then
>>>>>> we could
>>>>>> change this "latest" directory link to our upload location for
>>>>>> the
>>>>>> drivers.
>>>>>>
>>>>>> o If this type of clean up and setup of nightly drivers is
>>>>>> going to
>> take
>>>>>> some time, then at a minimum, it would be good to change the
>> permissions
>>>>>> on
>>>>>> this "latest" directory so that we could do some manual (pardon
>>>>>> the
>> pun)
>>>>>> cleanup.
>>>>>>
>>>>>> BTW, all of this came about because I had pointed a user at our
>> "latest"
>>>>>> manual to find out how to turn on the Query SQL Cache support
>>>>>> (knowing
>> it
>>>>>> was part of the 1.2.0 trunk release). But, I soon discovered
>>>>>> that our
>>>>>> "latest" manual is quite out of date... :-)
>>>>>>
>>>>>> Thanks,
>>>>>> Kevin
>>>>>>
>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>
--
Patrick Linskey
202 669 5907
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Michael Dick <mi...@apache.org>.
Hi,
I gave this a quick test and it looks like it's working, here's exactly what
I ran :
$ mvn -Dmaven.test.skip=true deploy
-DaltDeploymentRepository=myserver::default::scp://
myserver.myhost.com/home/mikedd/temp22
$ mvn -Dmaven.test.skip=true site:stage-deploy
-DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site
I think a similar set of arguments can be used for the release process.
Here's what I propose, after the 1.0.3 release is approved I'll update the
pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The changes
will be to update the default deploy location to be
openjpa.apache.org/builds/latest/${version} (or something similar). That way
the automated build system will go ahead and publish to the latest directory
with no need for command line arguments.
In the release profile we'll change the deployment location to be
people.apache.org/${user}/public_html/. . . so that the release is publicly
available. If we can't override the location via the profile I'll update the
instructions to pass it along as a command line arg.
If this sounds acceptable to everyone else I'll go ahead and open another
JIRA (633 has enough changes).
-mike
On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mi...@apache.org> wrote:
> Hi Patrick,
>
> If you're looking to upload a snapshot to say your home directory on
> people.apache.org you can just run
> $ mvn deploy
>
> I think we'd rather have the snapshots deployed to our builds
> directory though. Something like this should work (untested)
> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp://
> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
> deploy
>
> You'll need to add a server tag for people.apache.org to your
> ${home}/.m2/settings.xml file. Something like this should work:
>
> <servers>
> <server>
> <id>people.apache.org</id>
> <username>[your apache id]</username>
> <passphrase>[secret passphrase]</passphrase>
> <filePermissions>664</filePermissions>
> <directoryPermissions>775</directoryPermissions>
> </server>
> </servers>
>
> The preceding examples will upload our maven artifacts. To deploy the
> site I *think* this would work
>
> $ mvn -DstagingSiteURL=scp://
> people.apache.org/www/openjpa.apache.org/builds/${version}
> site:stage-deploy<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy>
>
> I'll take a closer look when time permits, this should be a starting
> point though.
>
> -mike
>
> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I'm trying to get the snapshot process working as closely to the new
> release process as possible. From what I can tell, mvn release:prepare is
> really oriented towards releases, not towards snapshots. Does anyone know of
> an equivalent snapshot target that we could use?
> >
> > -Patrick
> >
> > On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
> >
> >> Sounds good, Patrick. So, in the mean time, should I make a temporary
> >> repository for the "latest" docs? Or, if you think this will get
> resolved
> >> in the next day or two, then I could just wait.
> >>
> >> Thanks,
> >> Kevin
> >>
> >> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <pl...@gmail.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I think that this is because the machine that builds and uploads the
> >>> snapshots was offline for the last couple of months. I got that
> partially
> >>> back up and running last week, and hope to get the snapshots uploading
> again
> >>> later this week.
> >>>
> >>> -Patrick
> >>>
> >>>
> >>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
> >>>
> >>> Hi,
> >>>>
> >>>> I just noticed that our links for the "latest" OpenJPA documentation
> is
> >>>> out
> >>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I
> would
> >>>> expect that our "latest" link should point at some version of
> >>>> documentation
> >>>> associated with trunk. But, it's currently pointing at some version
> based
> >>>> on the 1.1.0 build. I was going to go ahead and clean this up, but it
> >>>> looks
> >>>> like I don't have proper authority to the /www/
> >>>> openjpa.apache.org/docs/latest directory. It looks like Patrick is
> the
> >>>> only
> >>>> one with enough authority.
> >>>>
> >>>> This "latest" directory is currently linked to this: latest ->
> >>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
> >>>>
> >>>> So, I'm thinking a few things need to be done:
> >>>>
> >>>> o It would be great to post our current nightly drivers and
> documentation
> >>>> out on people.apache.org from our TC system. (BTW, it looks like our
> >>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT builds,
> so we
> >>>> have some clean up there as well.) I'm not sure on the status of
> >>>> Patrick's
> >>>> TC system and whether we are able to get something like this setup or
> not.
> >>>>
> >>>> o If we can post our nightly drivers and documentation, then we could
> >>>> change this "latest" directory link to our upload location for the
> >>>> drivers.
> >>>>
> >>>> o If this type of clean up and setup of nightly drivers is going to
> take
> >>>> some time, then at a minimum, it would be good to change the
> permissions
> >>>> on
> >>>> this "latest" directory so that we could do some manual (pardon the
> pun)
> >>>> cleanup.
> >>>>
> >>>> BTW, all of this came about because I had pointed a user at our
> "latest"
> >>>> manual to find out how to turn on the Query SQL Cache support (knowing
> it
> >>>> was part of the 1.2.0 trunk release). But, I soon discovered that our
> >>>> "latest" manual is quite out of date... :-)
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>>
> >>>
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>
Re: snapshot process (was: Re: Documentation links and content "out of date")
Posted by Michael Dick <mi...@apache.org>.
Hi Patrick,
If you're looking to upload a snapshot to say your home directory on
people.apache.org you can just run
$ mvn deploy
I think we'd rather have the snapshots deployed to our builds
directory though. Something like this should work (untested)
$ mvn -DaltDeploymentRepository=people.apache.org::default:scp://people.apache.org/www/openjpa.apache.org/builds/${version}
deploy
You'll need to add a server tag for people.apache.org to your
${home}/.m2/settings.xml file. Something like this should work:
<servers>
<server>
<id>people.apache.org</id>
<username>[your apache id]</username>
<passphrase>[secret passphrase]</passphrase>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
</server>
</servers>
The preceding examples will upload our maven artifacts. To deploy the
site I *think* this would work
$ mvn -DstagingSiteURL=scp://people.apache.org/www/openjpa.apache.org/builds/${version}
site:stage-deploy
I'll take a closer look when time permits, this should be a starting
point though.
-mike
On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <pl...@gmail.com> wrote:
>
> Hi,
>
> I'm trying to get the snapshot process working as closely to the new release process as possible. From what I can tell, mvn release:prepare is really oriented towards releases, not towards snapshots. Does anyone know of an equivalent snapshot target that we could use?
>
> -Patrick
>
> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote:
>
>> Sounds good, Patrick. So, in the mean time, should I make a temporary
>> repository for the "latest" docs? Or, if you think this will get resolved
>> in the next day or two, then I could just wait.
>>
>> Thanks,
>> Kevin
>>
>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <pl...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I think that this is because the machine that builds and uploads the
>>> snapshots was offline for the last couple of months. I got that partially
>>> back up and running last week, and hope to get the snapshots uploading again
>>> later this week.
>>>
>>> -Patrick
>>>
>>>
>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote:
>>>
>>> Hi,
>>>>
>>>> I just noticed that our links for the "latest" OpenJPA documentation is
>>>> out
>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I would
>>>> expect that our "latest" link should point at some version of
>>>> documentation
>>>> associated with trunk. But, it's currently pointing at some version based
>>>> on the 1.1.0 build. I was going to go ahead and clean this up, but it
>>>> looks
>>>> like I don't have proper authority to the /www/
>>>> openjpa.apache.org/docs/latest directory. It looks like Patrick is the
>>>> only
>>>> one with enough authority.
>>>>
>>>> This "latest" directory is currently linked to this: latest ->
>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/
>>>>
>>>> So, I'm thinking a few things need to be done:
>>>>
>>>> o It would be great to post our current nightly drivers and documentation
>>>> out on people.apache.org from our TC system. (BTW, it looks like our
>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT builds, so we
>>>> have some clean up there as well.) I'm not sure on the status of
>>>> Patrick's
>>>> TC system and whether we are able to get something like this setup or not.
>>>>
>>>> o If we can post our nightly drivers and documentation, then we could
>>>> change this "latest" directory link to our upload location for the
>>>> drivers.
>>>>
>>>> o If this type of clean up and setup of nightly drivers is going to take
>>>> some time, then at a minimum, it would be good to change the permissions
>>>> on
>>>> this "latest" directory so that we could do some manual (pardon the pun)
>>>> cleanup.
>>>>
>>>> BTW, all of this came about because I had pointed a user at our "latest"
>>>> manual to find out how to turn on the Query SQL Cache support (knowing it
>>>> was part of the 1.2.0 trunk release). But, I soon discovered that our
>>>> "latest" manual is quite out of date... :-)
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>>
>
> --
> Patrick Linskey
> 202 669 5907
>