Certain parts of Maven won't work correctly unless you follow
the "normal" version convent. That would be:
#[.#]*[-qualifier]*[-SNAPSHOT]
In the incubator, one of the qualifiers MUST be "-incubator".
In anycase, if you are working toward a 1.0 release, the first part
should be 1.0. (or
Jimmy John wrote:
Hello,
I was looking at the codec.py script and decided to write a unt test script
fot it. I wrote 41 tests of which 9 failed. The ones that failed were due to:
(1) No range testing for unsinged integers. e.g. an unsigned octet can take
values from 0 through 255. Hence
all - we should keep discussions of the BDB store off this list I
think, it is not part of the Apache project.
-- Rob
On 21/05/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
Rupert,
Are you suggesting that we use a single BDB tx for several concurrent
prepare/commit operations? In such a case we
Rupert,
Are you suggesting that we use a single BDB tx for several concurrent
prepare/commit operations? In such a case we would have to change the
code as we are allocating one BDB tx object per Xid. Note that we do not
do that in the case of the JDBC store. I am a little bit concern about
the sy
Unless the BDB Transaction.commitSync() method is already capable of doing
this? It doesn't seem impossible, but I'm assuming it doesn't or else the
batch synch queueing scheme wouldn't have been used in the old BDB store.
Rupert
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Hi Arnaud,
Hi Arnaud,
The old BDBMessageStore had a feature whereby commits in different threads
could batch their transactions into the same disk synch. Implemented by the
Commit and CommitThread inner class. The idea is that there is one hand-off
thread that is doing the writes to disk, and committing thr
Kevin Smith wrote:
Kevin Smith wrote:
Gordon Sim wrote:
Kevin Smith wrote:
Gordon Sim wrote:
Kevin Smith wrote:
Thanks for the update! If there are any patches for this against
M2, I'd be willing to help test.
Fantastic! We are aiming to fix the M2 branch first and if you
could re-run you
I believe we called it 1.0 as we are working towards that with each
Milestone release.
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
X-SNAPSHOT means heading towards version X. If we are sure trunk will become
M3, its the right name. If not, I suppose trunk-SNAPSHOT would do.
I don't see
Kevin Smith wrote:
Gordon Sim wrote:
Kevin Smith wrote:
Gordon Sim wrote:
Kevin Smith wrote:
Thanks for the update! If there are any patches for this against
M2, I'd be willing to help test.
Fantastic! We are aiming to fix the M2 branch first and if you could
re-run your test at that time
Only reason for calling it trunk is that when we get auto- build
failures posted, then when
we branch there is less config to do and the messages in the log can be
tracked better. At
the time we branch and create the M3 line we will add a M3 auto build
target. This gives
as clean way to know
I also thought about calling it trunk... and to be honest I'm not that
bothered other than it shouldn't have the same version as the M2 trunk
build...
My reasoning for accepting M3 on trunk was simply that the approach
we've used in the past was that the version on trunk has been that of
the next
Nuno,
I would start sending them to the commit list and I am sure you will get
comments then...
Carl.
Nuno Santos wrote:
Message from a successful C++ build on the trunk (for comparison with
earlier message).
Nuno
X-SNAPSHOT means heading towards version X. If we are sure trunk will become
M3, its the right name. If not, I suppose trunk-SNAPSHOT would do.
I don't see whats wrong with the decimal system that everyone else uses,
also need for maven version ranges, but...
Rupert
On 21/05/07, Carl Trieloff <
Robert,
I don't quite get that, why would be not make the next branch the M3
snapshot and keep the
trunk call trunk? How does it help us calling trunk M3 snapshot
Carl
Robert Godfrey wrote:
Yes - that makes more sense... Anyone any objections to changing
trunk to be M3 snapshot?
-- Rob
Why the 1.0 in the name? don't get that
Carl.
Rupert Smith wrote:
Actually, my mistakes, its happy with whatever you like in front of the
-SNAPSHOT. The SNAPSHOT gets replced with a timestamp when you run 'mvn
deploy', or to a fixed version when you do 'mvn release'.
Think we should change tr
On 21/05/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
ooh that might have been easier :) forgot about jython
Unlikely to be easier since it is highly likely that we use language
features not supported by jython.
I'd say people just have to download python and install it or learn to
type whate
Yes - that makes more sense... Anyone any objections to changing
trunk to be M3 snapshot?
-- Rob
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Actually, my mistakes, its happy with whatever you like in front of the
-SNAPSHOT. The SNAPSHOT gets replced with a timestamp when you run 'mvn
Actually, my mistakes, its happy with whatever you like in front of the
-SNAPSHOT. The SNAPSHOT gets replced with a timestamp when you run 'mvn
deploy', or to a fixed version when you do 'mvn release'.
Think we should change trunk to 1.0-incubating-M3-SNAPSHOT?
Rupert
On 21/05/07, Rupert Smith
So 'qpid-broker-incubating' '0.2-SNAPSHOT'? Maybe the position of the number
just needs to be moved so that it comes before the -SNAPSHOT bit? '
incubating-0.2-SNAPSHOT'? You never know with maven. I'll have a little
experiment and see what makes it happy.
Rupert
On 21/05/07, Martin Ritchie <[EM
We need to have the 'incubating' in our artifact names but i'm sure we
can put that some where other than version value.
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Should we have different version stamps under Maven for trunk and M2?
I was thinking about this as I rebuild M2 after tru
ooh that might have been easier :) forgot about jython
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
There's also a Jython plugin for Maven, seems quite immature and no idea if
the current tests would run under Jython, but here's the link anyway.
http://dev.servprise.com/maven-jython-plu
Should we have different version stamps under Maven for trunk and M2?
I was thinking about this as I rebuild M2 after trunk, to ensure that when I
built some other stuff against M2 I got the M2 build and not trunk. Really
M2 should be a different version to trunk, so I can distinguish the built
a
There's also a Jython plugin for Maven, seems quite immature and no idea if
the current tests would run under Jython, but here's the link anyway.
http://dev.servprise.com/maven-jython-plugin/
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Yes, but then just ask all developers to add the
Yes, but then just ask all developers to add the run-python-tests flag to an
active profile in their settings.xml. I'm thinking of someone outside of the
dev team downloading the source from from svn and trying to build it. If I
were in that position, being made to go and download and install pyth
On 21/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Could we do it the other way around, so you specify run-pyton-tests to run
them, and not if you don't? Its just that doing it this way breaks the maven
model, of it downloading and installing everything so that in theory at
least, all you have
Could we do it the other way around, so you specify run-pyton-tests to run
them, and not if you don't? Its just that doing it this way breaks the maven
model, of it downloading and installing everything so that in theory at
least, all you have to do is type 'mvn' against a checkout and it will
bui
[
https://issues.apache.org/jira/browse/QPID-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie updated QPID-423:
Fix Version/s: M3
Assignee: (was: Martin Ritchie)
> Allow authentication to be configura
[
https://issues.apache.org/jira/browse/QPID-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Simon updated QPID-496:
--
Attachment: jdbcStoreFinal.patch
Sorry about that, but the previous patch did break one test. Please use
[
https://issues.apache.org/jira/browse/QPID-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ritchie reassigned QPID-401:
---
Assignee: Martin Ritchie
> Integrate Python tests with mvn
> ---
>
On 21/05/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
Hi,
I have just added a patch that provides a generic JDBC store. I have
tested this implementation against Apache Derby. We need to pull the
derby jar out of the Apache repository though. Can somebody update maven
for doing that?
This impleme
[
https://issues.apache.org/jira/browse/QPID-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Simon updated QPID-496:
--
Attachment: jdbcStoreUpdated.patch
I just realized that I haven't updated the project before I made the p
Hi,
I have just added a patch that provides a generic JDBC store. I have
tested this implementation against Apache Derby. We need to pull the
derby jar out of the Apache repository though. Can somebody update maven
for doing that?
This implementation should work with Oracle even if I haven't test
[
https://issues.apache.org/jira/browse/QPID-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Simon updated QPID-496:
--
Attachment: jdbcStore.patch
Please apply this patch under \java\broker
> JDBC Store
> --
>
>
JDBC Store
--
Key: QPID-496
URL: https://issues.apache.org/jira/browse/QPID-496
Project: Qpid
Issue Type: New Feature
Components: Java Broker
Reporter: Arnaud Simon
Attachments: jdbcStore.patch
This is
34 matches
Mail list logo
