Hi all,
This is mainly for Deng and Teody as I've seen them working through
the issue for reporting... I took a look at the latest patch and it's
looking pretty good.
I did go to check about the jasper reports license, though, and it
appears from the POM that it is LGPL.
Though it's
Brett Porter wrote:
Hi all,
This is mainly for Deng and Teody as I've seen them working through
the issue for reporting... I took a look at the latest patch and it's
looking pretty good.
I did go to check about the jasper reports license, though, and it
appears from the POM that it is
Hi All,
We (Brett, Joakim and I) have segregated the issues in Jira to prep for
the upcoming 1.0 release (finally! :-) ). Anyway, there'll be two beta
releases first before 1.0.
So..here's the plan (excerpted from Brett):
- finish all issues for 1.0-beta-1
- then move on to 1.0-beta-2 issues
I've closed MRM-373 (Unable to delete the pre-configured example network
proxy), which was no longer valid.
Fabrice.
On 8/1/07, Maria Odea Ching [EMAIL PROTECTED] wrote:
Hi All,
We (Brett, Joakim and I) have segregated the issues in Jira to prep for
the upcoming 1.0 release (finally! :-) ).
Hi Maria, all,
Although i'm a new user of Archiva, i would like to know when in the
roadmap the team plan to fix issues related to running Archiva inside
Tomcat (issues like http://jira.codehaus.org/browse/MRM-323 ) ? Is it
something important for the team ? Did you expect users to deploy
Ok, thanks Fabrice :)
I'll add that to the list.
-Deng
Fabrice Bellingard wrote:
I've closed MRM-373 (Unable to delete the pre-configured example network
proxy), which was no longer valid.
Fabrice.
On 8/1/07, Maria Odea Ching [EMAIL PROTECTED] wrote:
Hi All,
We (Brett, Joakim and I)
I think null value will be enough. I think we'll need to test the null value in
the UI but it isn't a problem.
Emmanuel
Brett Porter a écrit :
Hi,
I've narrowed down the problem in upgrading from alpha-2 to beta-1 to
the following model change:
field
For a project notifier, I think we can keep what we have actually, but for a
group notifier, we can send a single mail by project group.
The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't
On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote:
For a project notifier, I think we can keep what we have actually,
but for a group notifier, we can send a single mail by project group.
The mail can be sent after the build of the latest project of the
group, I don't think it will be a
Hi all,
Is it possible to develop a plugin that defines a custom type of
artifact (a test campaign in our case), a custom lifecycle (with, for
examples, phases such as pre-start-servers, start-servers,
post-start-servers, pre-initialize-environment,
initialize-environment, etc...) and a default
Hi,
A while back I promised to write up what we are doing with jira
versions now, and finally got around to it. In the process, I came up
with a couple of tweaks we could make (see actions). Here it is in
point form - does everyone agree this is the process we are following
now? Missing
On 1 Aug 07, at 12:25 AM 1 Aug 07, Shane Isbell wrote:
I would like to see if there is any general interest from the Maven
community in using RDF for storing and retrieving of repository
information.
As the only means, and not accessed via some API shielding the
underlying store then my
I think this bug is related to an issue I'm currently having but I'd like to
confirm.
From the Getting
Startedhttp://maven.apache.org/guides/getting-started/index.htmlpage
there's mention that when performing a multi-module build that it is
not required that you run install to successfully
A couple more points I thought of:
There is another implementation that uses JSR 170 so it would be very
hard to have any level of interoperability without an API. I
certainly don't want that being RDF.
There are plenty of good tools that can be leveraged, for example I
use Lucene
Hi Jamie,
Please, look at this issue: http://jira.codehaus.org/browse/MJAR-75
(Jason - please, look at this issue / patch)
I think that If it is applied and you do the tests after package
phase (run mvn package to fire the tests),
the test's will use the new jar.
Thanks,
Piotr Tabor
Excellent stuff Brett. Let me know if I can help.
Most of this is equally important for plugins and other maven sub
projects. We should try to make an additional, more general, description
of versions that is not tied to MNG.
I have a couple of questions, see inline...
Brett Porter wrote:
To clarify: NMaven uses RDF for its local repository store (and has
abstractions of an AssemblyResolver/ProjectDao for the API). It does not
require that the remote repository contain RDF, but rather parses and stores
the information from the remote pom artifact into the RDF store. There is
also
+1
Vincent
2007/7/30, Dennis Lundberg [EMAIL PROTECTED]:
Hi,
I'd like to release maven-docck-plugin 1.0-beta-2. It has been 9 months
since the last release.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11361styleName=Htmlversion=13021
Tag:
Hi,
I'm using Maven 2.0 Integration (0.0.9) plugin in my Eclipse 3.2.2.
The project I'm trying to build using the plugin has prerequisites tag
checking for maven version 2.0.6 or higher. I can build the maven
project independently fine, but trying to build using the maven plugin
in Eclipse the
On 02/08/2007, at 5:31 AM, Dennis Lundberg wrote:
Excellent stuff Brett. Let me know if I can help.
Most of this is equally important for plugins and other maven sub
projects. We should try to make an additional, more general,
description of versions that is not tied to MNG.
Agreed, I
On 1 Aug 07, at 4:39 PM 1 Aug 07, Shane Isbell wrote:
To clarify: NMaven uses RDF for its local repository store (and has
abstractions of an AssemblyResolver/ProjectDao for the API). It
does not
require that the remote repository contain RDF, but rather parses
and stores
the information
All looks good, my only comments are I think the notions in Scrum
like Sprints for a release are good like the idea of fixing the set
of issues and sticking with it for the Sprint. Sensible patterns and
there's already literature on that. So in any parts you're talking
about planning I
I'd be happy to run some tests on Tomcat post beta-1 as well. I've
spent way too much time battling these things in a past life not to
have learned something that might be helpful :)
Anyone here deploying to something other than Tomcat? We have Jetty5
(via appserver) and 6 (via plugin)
On 02/08/2007, at 1:52 PM, Jason van Zyl wrote:
I'd encourage us sharing a good Mylyn set up and putting it on the
web site to encourage this consistency, but I think it's
unreasonable to mandate it.
Why? It's free and it's the best way to keep some level visibility.
For people
On 02/08/2007, at 1:22 PM, Jason van Zyl wrote:
All looks good, my only comments are I think the notions in Scrum
like Sprints for a release are good like the idea of fixing the set
of issues and sticking with it for the Sprint. Sensible patterns
and there's already literature on that. So
Hi,
How do people feel about planning betas to fit into: Aug 15, Aug 29,
Sep 12, Sep 26? (for releases, votes are the monday before)
If so, is the current beta-2 list achievable by Aug 15? Looks like it
needs to be trimmed (and we also have 11 unscheduled to find a home for)
Cheers,
On 1 Aug 07, at 11:37 PM 1 Aug 07, Brett Porter wrote:
On 02/08/2007, at 1:22 PM, Jason van Zyl wrote:
All looks good, my only comments are I think the notions in Scrum
like Sprints for a release are good like the idea of fixing the
set of issues and sticking with it for the Sprint.
It'd be nice to enforce it now, but I'm not prepared for that kind of
pain :) If someone else who's done more jira workflowy things wants
to try their hand, please do. Otherwise, I figure if we at least have
a stated pattern in agreement, if we see regular violations we should
either
Hi Cédric,
Looks very cool. Nice work!
I was wondering if you've seen the maven-shared-jar component? http://
maven.apache.org/shared/maven-shared-jar/
This seems like something you could use (and if you have some
additional features, as it appears you do, you might contribute them
Okay. I see where you are coming from. If we are using multiple datasources
- traditional pom object hierachy, RDF, Lucene index, XML stores - then we
need a 1) common API (for application developers); 2) SPI (from Maven); 3)
adapters (from framework developers). The SPI would need (at a minimum)
30 matches
Mail list logo
