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...@bea.com> on 2006/09/29 21:26:07 UTC
svn revision number
Hi,
It looks like the revision number that we're getting in
openjpa-lib/pom.xml is the latest revision number of the repo as a
whole, not the latest revision number of just the openjpa trunk. Does
anyone have a clue about how to get the latest revision for just
openjpa?
I would expect that we could get this info from running and parsing
'svnversion -c', but it looks like we're digging into files instead of
running commands. Any insight into why this is?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
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.
RE: svn revision number
Posted by Patrick Linskey <pl...@bea.com>.
> >> It looks like the revision number that we're getting in
> >> openjpa-lib/pom.xml is the latest revision number of the repo as a
> >> whole, not the latest revision number of just the openjpa
> trunk. Does
> >> anyone have a clue about how to get the latest revision for just
> >> openjpa?
>
> I had thought that would be sufficient for re-constructing a
> particular view from the repository. Is that not the case?
I think that it is sufficient, but it's just odd that running 'mvn
package' twice in a row may create different numbers.
> >> I would expect that we could get this info from running and parsing
> >> 'svnversion -c', but it looks like we're digging into files
> >> instead of
> >> running commands. Any insight into why this is?
>
> Well, I had been loathe to spawn commands as part of the build
> process. For example, what if someone is using Eclipse's built-in
> Subversion client, and so do not have a separate "svnversion"
> command
> on their machine? Should we just fail the build, or silently ignore?
>
> Parsing the .svn/entries file seemed like it would be a simpler
> process. Unfortunately, there is another reason we may need
> to change
> this: the latest Subversion release (1.4) changes the format of this
> file from XML to some custom format, which also breaks our parsing.
> Bummer.
> > Also, it would seem that the target runs during the 'run' goal
> > (whatever
> > that is). The upshot is that 'mvn clean && mvn package' builds a jar
> > with no revision information, since 'run' seems to happen after jar
> > assembly is complete.
>
> The goal is the action that you take on the plugin, not the phase in
> which the action is performed. The "maven-antrun-plugin" only has a
> single goal: "run".
>
> > I tried changing the goal to both 'package' and 'compile', but was
> > told
> > that that goal was unrecognized.
>
> It is the "phase" element that needs to be changed. Try
> "compile" and
> see if that fixes it.
>
> > Does anyone have any idea how to make 'compile' become a
> goal, or what
> > the name of a goal that happens before creating the jar might be?
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
>
>
>
>
>
_______________________________________________________________________
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.
RE: svn revision number
Posted by Patrick Linskey <pl...@bea.com>.
Note that the only time that a version number will have a "M" at the end
of it is when there are changes in the local copy.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
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.
> -----Original Message-----
> From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On
> Behalf Of Marc Prud'hommeaux
> Sent: Friday, September 29, 2006 3:10 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: svn revision number
>
>
> OK, I went ahead and changed the system to instead spawn the
> "svnrevision" command. It should gracefully set the version to
> "unknown" if the "svnrevision" command can't be found.
>
>
> On Sep 29, 2006, at 2:44 PM, Patrick Linskey wrote:
>
> >>>> I would expect that we could get this info from running
> and parsing
> >>>> 'svnversion -c', but it looks like we're digging into files
> >>>> instead of
> >>>> running commands. Any insight into why this is?
> >>
> >> Well, I had been loathe to spawn commands as part of the build
> >> process. For example, what if someone is using Eclipse's built-in
> >> Subversion client, and so do not have a separate "svnversion"
> >> command
> >> on their machine? Should we just fail the build, or
> silently ignore?
> >>
> >> Parsing the .svn/entries file seemed like it would be a simpler
> >> process. Unfortunately, there is another reason we may need
> >> to change
> >> this: the latest Subversion release (1.4) changes the
> format of this
> >> file from XML to some custom format, which also breaks our parsing.
> >> Bummer.
> >
> > Personally, I think that our primary goal with this should be making
> > things work well in an automated environment, for uploading
> new build
> > artifacts to ibiblio / the website.
> >
> >>> Also, it would seem that the target runs during the 'run' goal
> >>> (whatever
> >>> that is). The upshot is that 'mvn clean && mvn package'
> builds a jar
> >>> with no revision information, since 'run' seems to happen
> after jar
> >>> assembly is complete.
> >>
> >> The goal is the action that you take on the plugin, not
> the phase in
> >> which the action is performed. The "maven-antrun-plugin" only has a
> >> single goal: "run".
> >>
> >>> I tried changing the goal to both 'package' and 'compile', but was
> >>> told
> >>> that that goal was unrecognized.
> >>
> >> It is the "phase" element that needs to be changed. Try
> >> "compile" and
> >> see if that fixes it.
> >
> > Yep, that did it. Thanks.
> >
> > -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.
>
>
Re: svn revision number
Posted by Marc Prud'hommeaux <mp...@apache.org>.
OK, I went ahead and changed the system to instead spawn the
"svnrevision" command. It should gracefully set the version to
"unknown" if the "svnrevision" command can't be found.
On Sep 29, 2006, at 2:44 PM, Patrick Linskey wrote:
>>>> I would expect that we could get this info from running and parsing
>>>> 'svnversion -c', but it looks like we're digging into files
>>>> instead of
>>>> running commands. Any insight into why this is?
>>
>> Well, I had been loathe to spawn commands as part of the build
>> process. For example, what if someone is using Eclipse's built-in
>> Subversion client, and so do not have a separate "svnversion"
>> command
>> on their machine? Should we just fail the build, or silently ignore?
>>
>> Parsing the .svn/entries file seemed like it would be a simpler
>> process. Unfortunately, there is another reason we may need
>> to change
>> this: the latest Subversion release (1.4) changes the format of this
>> file from XML to some custom format, which also breaks our parsing.
>> Bummer.
>
> Personally, I think that our primary goal with this should be making
> things work well in an automated environment, for uploading new build
> artifacts to ibiblio / the website.
>
>>> Also, it would seem that the target runs during the 'run' goal
>>> (whatever
>>> that is). The upshot is that 'mvn clean && mvn package' builds a jar
>>> with no revision information, since 'run' seems to happen after jar
>>> assembly is complete.
>>
>> The goal is the action that you take on the plugin, not the phase in
>> which the action is performed. The "maven-antrun-plugin" only has a
>> single goal: "run".
>>
>>> I tried changing the goal to both 'package' and 'compile', but was
>>> told
>>> that that goal was unrecognized.
>>
>> It is the "phase" element that needs to be changed. Try
>> "compile" and
>> see if that fixes it.
>
> Yep, that did it. Thanks.
>
> -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.
RE: svn revision number
Posted by Patrick Linskey <pl...@bea.com>.
> >> I would expect that we could get this info from running and parsing
> >> 'svnversion -c', but it looks like we're digging into files
> >> instead of
> >> running commands. Any insight into why this is?
>
> Well, I had been loathe to spawn commands as part of the build
> process. For example, what if someone is using Eclipse's built-in
> Subversion client, and so do not have a separate "svnversion"
> command
> on their machine? Should we just fail the build, or silently ignore?
>
> Parsing the .svn/entries file seemed like it would be a simpler
> process. Unfortunately, there is another reason we may need
> to change
> this: the latest Subversion release (1.4) changes the format of this
> file from XML to some custom format, which also breaks our parsing.
> Bummer.
Personally, I think that our primary goal with this should be making
things work well in an automated environment, for uploading new build
artifacts to ibiblio / the website.
> > Also, it would seem that the target runs during the 'run' goal
> > (whatever
> > that is). The upshot is that 'mvn clean && mvn package' builds a jar
> > with no revision information, since 'run' seems to happen after jar
> > assembly is complete.
>
> The goal is the action that you take on the plugin, not the phase in
> which the action is performed. The "maven-antrun-plugin" only has a
> single goal: "run".
>
> > I tried changing the goal to both 'package' and 'compile', but was
> > told
> > that that goal was unrecognized.
>
> It is the "phase" element that needs to be changed. Try
> "compile" and
> see if that fixes it.
Yep, that did it. Thanks.
-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.
Re: svn revision number
Posted by Marc Prud'hommeaux <mp...@apache.org>.
>> It looks like the revision number that we're getting in
>> openjpa-lib/pom.xml is the latest revision number of the repo as a
>> whole, not the latest revision number of just the openjpa trunk. Does
>> anyone have a clue about how to get the latest revision for just
>> openjpa?
I had thought that would be sufficient for re-constructing a
particular view from the repository. Is that not the case?
>> I would expect that we could get this info from running and parsing
>> 'svnversion -c', but it looks like we're digging into files
>> instead of
>> running commands. Any insight into why this is?
Well, I had been loathe to spawn commands as part of the build
process. For example, what if someone is using Eclipse's built-in
Subversion client, and so do not have a separate "svnversion" command
on their machine? Should we just fail the build, or silently ignore?
Parsing the .svn/entries file seemed like it would be a simpler
process. Unfortunately, there is another reason we may need to change
this: the latest Subversion release (1.4) changes the format of this
file from XML to some custom format, which also breaks our parsing.
Bummer.
> Also, it would seem that the target runs during the 'run' goal
> (whatever
> that is). The upshot is that 'mvn clean && mvn package' builds a jar
> with no revision information, since 'run' seems to happen after jar
> assembly is complete.
The goal is the action that you take on the plugin, not the phase in
which the action is performed. The "maven-antrun-plugin" only has a
single goal: "run".
> I tried changing the goal to both 'package' and 'compile', but was
> told
> that that goal was unrecognized.
It is the "phase" element that needs to be changed. Try "compile" and
see if that fixes it.
> Does anyone have any idea how to make 'compile' become a goal, or what
> the name of a goal that happens before creating the jar might be?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
RE: svn revision number
Posted by Patrick Linskey <pl...@bea.com>.
Also, it would seem that the target runs during the 'run' goal (whatever
that is). The upshot is that 'mvn clean && mvn package' builds a jar
with no revision information, since 'run' seems to happen after jar
assembly is complete.
I tried changing the goal to both 'package' and 'compile', but was told
that that goal was unrecognized.
Does anyone have any idea how to make 'compile' become a goal, or what
the name of a goal that happens before creating the jar might be?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
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.
> -----Original Message-----
> From: Patrick Linskey
> Sent: Friday, September 29, 2006 12:26 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: svn revision number
>
> Hi,
>
> It looks like the revision number that we're getting in
> openjpa-lib/pom.xml is the latest revision number of the repo as a
> whole, not the latest revision number of just the openjpa trunk. Does
> anyone have a clue about how to get the latest revision for just
> openjpa?
>
> I would expect that we could get this info from running and parsing
> 'svnversion -c', but it looks like we're digging into files instead of
> running commands. Any insight into why this is?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________
> _________
> 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.
>