On Thu, Dec 25, 2008 at 10:20 AM, sverhagen wrote:
> Two questions:
> - Why is MANIFEST.MF version controlled to begin with. Isn't it a generated
> file?
Depends on your workflow. In OSGi the manifest controls the classes
your bundle can even use, and Eclipse's PDE tooling modifies the
manifest d
lled to begin with. Isn't it a generated
file?
- Don't you update MANIFEST.MF on every build? We do so, since we also
appreciate to have package details available when a developer is just
experimenting with something that is a snapshot
--
View this message in context:
http://www.n
hat you describe "works" as well, but I feel it's a risky
shortcut in the 'reproducibility' department. I also feel that it's a matter
of loosing track of good SCM behavior because "your other tool" (Maven in
this case) allows you to (and yes, from a Maven point
t: Monday, December 15, 2008 2:18 PM
> To: users@maven.apache.org
> Subject: RE: Up-to-date release
>
>
>
> Todd Thiessen wrote:
> >
> > Unfortunately, I don't believe there is a way to completely
> ensure an
> > up-to-date work area. A commit coul
this was for:
"useEditMode:
Whether to use "edit" mode on the SCM, to lock the file for editing during
SCM operations."
(Although we don't use it, apparently we're taking that chance.)
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925
> -Original Message-
> From: sverhagen [mailto:verha...@sander.com]
> Sent: Saturday, December 13, 2008 8:31 AM
> To: users@maven.apache.org
> Subject: Re: Up-to-date release
>
>
>
> Wendy Smoak-3 wrote:
> >
> > I still tend to favor communicati
Comments within.
Anyone else have thoughts on this?
---
Todd Thiessen
> -Original Message-
> From: sverhagen [mailto:verha...@sander.com]
> Sent: Friday, December 12, 2008 8:47 PM
> To: users@maven.apache.org
> Subject: RE: Up-to-date release
>
>
> Hi, agai
t. (Our devs are tangled up in overhead a lot of their
time already, so whatever we can cover with improving our tooling is very
welcome.)
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20990217.html
Sent from the Mav
all... a good start... still thinking on it!
Thanks for that.
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20986559.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
T
t 'trunk' and 'head of trunk', this could just as
well have been some branch that I'm releasing from. Same story.)
Best regards, Sander.
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp209257
On Wed, Dec 10, 2008 at 9:12 AM, Todd Thiessen <[EMAIL PROTECTED]> wrote:
> This causes fewer "freezes" of the main trunk. Someone can do a formal
> release and other devs can still commit to trunk and only see those
> changes in SNAPSHOT versions where they can get some soak before making
> a form
Comments within.
---
Todd Thiessen
> -Original Message-
> From: sverhagen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2008 6:07 PM
> To: users@maven.apache.org
> Subject: Up-to-date release
>
>
> Hi. We heavily use the Maven release plug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm subscribed to this bug:
http://jira.codehaus.org/browse/SCM-406
Lots of people are complaining, but sadly there are no answers so far.
The problem seems to be that when doinf releaase:prepare, the release
plugin tries to commit the current worki
sverhagen schrieb:
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 does not explicitly update from SVN, the change from
On Tue, Dec 9, 2008 at 6:31 PM, sverhagen <[EMAIL PROTECTED]> wrote:
> Yours fails on inconsistent pom.xml. In my scenario I can tell you that the
> POM did not change due to the work of either one of the developers; the
> sources changed.
>
> Also, yours fails on commiting something to the trunk,
e. No argument.)
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20926113.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
1.5.0 (r31699)
compiled Jun 23 2008, 12:59:48
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20925991.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscri
On Tue, Dec 9, 2008 at 6:07 PM, sverhagen <[EMAIL PROTECTED]> wrote:
>
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 d
now I can make a nice shell script to check this, but I would like to
> configure it in Maven, to make things mandatory and reproducible.
>
> Thanks for your ideas!
>
> Sander.
> --
> View this message in context:
> http://www.nabble.com/Up-to-date-rele
.
I know I can make a nice shell script to check this, but I would like to
configure it in Maven, to make things mandatory and reproducible.
Thanks for your ideas!
Sander.
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20925759.html
Sent from the Maven - Use
20 matches
Mail list logo
