I also notice archiva-model is using jpox 1.1.6 plugin from Mojo
Is there a reason not to use jpox-one :
http://www.jpox.org/downloads/maven2/jpox/jpox-maven-plugin/
Nico.
2008/1/30, nicolas de loof [EMAIL PROTECTED]:
MVNII-14 was closed as Won't fix
The central POM is a converted from m1
That beeing said, jpox m2 POM is also invalid :
Validation Messages:
[0] 'dependencies.dependency.version' is missing for oracle:ojdbc
dependency
groupIdoracle/groupId
artifactIdojdbc/artifactId
/dependency
I've created MVNII-14 on www.jpox.org, if anyone here also works on
On Jan 30, 2008 8:18 AM, nicolas de loof [EMAIL PROTECTED] wrote:
Is there a good reason to declare jpox-repository in archiva main pom ?
The jpox pom.xml is a maven1 pom, and the requested artifact is available in
central.
I think it was added while we waited for jpox 1.1.9 to be uploaded
MVNII-14 was closed as Won't fix
The central POM is a converted from m1 POM, jPox also has a valid POM in SVN
That also shows that the m1 - m2 pom conversion doesn't work well and
produces invalid POMs.
Maybe this process should be enhance to validate the converted POM before
deployment, and
It really depends on whether you are looking to use the 1.1.9
enhnacement features, or the 1.1.9 runtime features. I think the bug
it was addressing was in the runtime - so to upgrade would be nice but
non essential.
As for the conversion, I'm not really sure...
- Brett
On 30/01/2008, at
Hi,
Great to see version 2.0 discussions kicking off! Thanks for putting the
ideas on confluence, Emmanuel. :-)
Some notes around the ideas outlined on the wiki:
1) Architecture
Moving to JSE 5 and JPA is a good idea \o/, it been fairly overdue ;-).
1-1)Can you please elaborate a bit on
TopLink has a large community of users and active forums at both Oracle and
Glassfish. If you are concerned about licensing, Oracle has donated the
full TopLink source to the Eclipse Foundation under the Eclipse Persistence
Services (EclipseLink) project. If you have any questions the
While using a 2.0.9 snapshot, I noticed that my plugins no longer see -D...
cli arguments as system properties.
Probably because System.setProperty(...) was removed in this revision. Why
was this necessary ?
Tom
On Jan 8, 2008 1:03 PM, [EMAIL PROTECTED] wrote:
Author: vsiveton
Date: Tue Jan
Here's my +1 :)
Had it running the whole day today and it's working quite nicely..
Thanks,
Deng
On Jan 29, 2008 7:11 PM, Maria Odea Ching [EMAIL PROTECTED] wrote:
Hi Everyone,
The Archiva 1.0.1 release candidate has been prepared. JPOX was upgraded
from 1.1.7 to 1.1.9 to fix an issue that
On 29/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
How about for MNG-3092 we make it configurable per repository whether the
metadata resolution includes snapshots in ranges... you could even default to
false to keep Dave and yourself happy and I can turn it on where i need it.
I'm not
Hi Lukas,
2008/1/30, Lukas Theussl [EMAIL PROTECTED]:
+1
Tested on maven and doxia sites, works great. Thanks for pushing this!
However, I'd like to propose a more appropriate name for the target
directory, since link checking is not directly a doxia-related task. I
first thought to put it
We are aware on this. FYI the issue MNG-2848 is still open.
Cheers,
Vincent
2008/1/30, Tom Huybrechts [EMAIL PROTECTED]:
While using a 2.0.9 snapshot, I noticed that my plugins no longer see -D...
cli arguments as system properties.
Probably because System.setProperty(...) was removed in
On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote:
I don't think that linking this level of artifact resolution
uncertainty to its source repository is a good idea. How version
ranges are resolved should be completely deterministic and independent
from where the artifact was actually
IMHO
I think a vote with the two positions clearly identified (perhaps with pros
and cons for both if the pair of ye can agree on the pros and cons). (unless
somebody else has a third position)
-Stephen.
On Jan 30, 2008 12:56 PM, Mark Hobson [EMAIL PROTECTED] wrote:
On 30/01/2008, Mark Hobson
Hey Everyone,
I noticed that the assembly plugin has not been released in a while (since last
april) and it seems like there are a lot of useful fixes in the current trunk.
I also noticed some issues that can probably be resolved easily:
http://jira.codehaus.org/browse/MASSEMBLY-188 (this is a
Hello Everyone,
I'd like to contribute to continuum community and I'll like to start work
on:
CONTINUUM-1344
CONTINUUM-1593
CONTINUUM-1549
In continuum road map 2.0 i read that it's necessary to have template, If
yes could
please tell me where I can find it.
Is this the 'right' way to start
Is there a good reason to declare jpox-repository in archiva main pom ?
The jpox pom.xml is a maven1 pom, and the requested artifact is available in
central.
Nico.
Anyone else notice how slow jira is if you click on the all tab or the
fisheye tab of an issue?
Is there anything that can be done to improve the performance of this?
Thanks!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
My suggestion is before releasing 2.2-beta-2, that the following issues be
addressed (simple 1 liner fixes)
http://jira.codehaus.org/browse/MASSEMBLY-277 (null pointer exception)
http://jira.codehaus.org/browse/MASSEMBLY-278 (config to not fail out on
missing descriptor)
If you like, I can even
Do you think this will also include the build context mechanics we talked
about a long time ago? Where mojo's can communicate to each other a map of
either status or configuration settings through some third party mechanism,
perhaps the build plan this talks about. I seem to remember you putting
it is certainly a good place to start :)
without looking through those continuum issues, I would say that your best
bet is to dig into the code a bit, come up with a gameplan on what you think
ought to be modified where, maybe a patch or three to th dev list and give
us an idea what your
How important is the database really to things in continuum?
To me it has always seemed somewhat of an annoyance to have to manage and
maintain when so much of things could just be some xml files on disk. There
isn't a great amount of search functionality in continuum that in my mind
begs a
Patches would be a big help, particularly if they include tests that
exhibit the failure behavior, as this can take some time to replicate
(even if they are small fixes, you're familiar with the problem,
while I'm not).
Thanks,
-john
On Jan 30, 2008, at 12:04 PM, Sejal Patel wrote:
My
well, when your working with something that will try and predetermine how
and when plugins will run and you have something like build context/state in
play then plugins will be able to turn themselves off depending on build
state based on the context of the build up to that point...which kinda
How do you see that impacting the lifecycle stuff, out of curiosity?
I did put the build context into trunk, but wound up taking it back
out because it wasn't implemented very well, and was leading to a
proliferation of separate, threadlocal-driven storage classes. I've
been thinking for
the point of the tests is not to prove to me that there is a problem, it's
to help us safeguard against reintroducing that problem later. If I have a
ready-made test that I can incorporate, it'll save me a lot of time and make
it more likely that I'll be able to get your fix in.
-john
On Jan 30,
I've updated 277 with a patch. Not sure that you really need proof to see
that a chunk of code that says project.getBaseDir() followed by a if
(project == null) is a bad thing that should be reversed.
issue 278 I can provide the patch but i think there is confusion since there
was a proposed
On Thu, 31 Jan 2008 01:56:09 Mark Hobson wrote:
On 30/01/2008, Mark Hobson [EMAIL PROTECTED] wrote:
I don't think that linking this level of artifact resolution
uncertainty to its source repository is a good idea. How version
ranges are resolved should be completely deterministic and
I get a test failure on MavenProjectInfoReportsPluginDependencyGraphTest
This test use maven-project-info-reports-plugin:2.1-SNAPSHOT to test
dependency graph :
unit.framework.AssertionFailedError:
(Extra Actual) org.codehaus.plexus:plexus-utils:1.0.4::jar
(Extra Actual)
JPA fully supports 'lazy' loading of relationships.
--Gordon
jmcconnell wrote:
How important is the database really to things in continuum?
but if we are going to stick with the database then I think the api needs
to
definitely take into account a more distributed nature where multiple
On Jan 30, 2008 12:34 PM, Jesse McConnell [EMAIL PROTECTED] wrote:
How important is the database really to things in continuum?
To me it has always seemed somewhat of an annoyance to have to manage and
maintain when so much of things could just be some xml files on disk.
Like the General
Sure thing I understand. I'll try to have the tests for you tomorrow. I ran
into them when making an extension to that plugin and so I'll have to come
up with a nice clean way to exploit this error and then show that the patch
fixes it. To do that I'll probably have to spend a little time studying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
| Heh, so you are willing to trade build reproducibility (for all
| projects linked to central repo) for care about the community? o.O
|
| Hrm, please put that on a vote before you do it!
|
| IF you are talking about putting up dummy
33 matches
Mail list logo
