+1
-Ursprüngliche Nachricht-
Von: Wendy Smoak [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 9. August 2008 18:19
An: Maven Developers List
Betreff: [VOTE] Release Maven War plugin version 2.1-alpha-2
It's time to release the War Plugin. Thanks to Benjamin and Olivier
for removing all
Hi John,
It seems that project.getExecutionProject().getCompileSourceRoots()
uses relative paths (i.e. target/generated-sources/plugin)
Thanks,
Vincent
2008/8/9 Wendy Smoak [EMAIL PROTECTED]:
On Fri, Aug 8, 2008 at 3:52 PM, John Casey [EMAIL PROTECTED] wrote:
The distro is here:
Hi,
I have attempted to use the javadocDirectory plugin of the
maven-javadoc-plugin. In 2.4, this parameter is documented like this:
Specifies the Javadoc ressources directory to be included in the
Javadoc (i.e. package.html, images...).
I read this like I could use the parameter for the
Dennis,
Just a follow up on the reports.
The reports generated by Swizzle are here (I restored them):
https://svn.apache.org/repos/asf/maven/sandbox/trunk/reports
And they are checked out in the home directory of Hudson on the CI
server.
Also note that whatever reports we come up we can
+1
We've offered our help from Eclipse IAM in the past [1], and maybe we can
get the Eclipse Buckminster folks to lend a hand.
Since there are many external parties interested, having a clear
roadmap/project plan for what would be an stable embedder would be
extremely useful. As Milos mentions,
On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi
[EMAIL PROTECTED] wrote:
Milos Kleint wrote:
please, please, let's not add anything else to trunk (2.1) and
stabilize it. I've been waiting for a stable embeddable version for 2
years and with the number of work (complete rewrites of everything)
+1
--
Olivier
2008/8/9 Wendy Smoak [EMAIL PROTECTED]:
It's time to release the War Plugin. Thanks to Benjamin and Olivier
for removing all the snapshot dependencies to make this possible!
We discussed making this release beta-1 or even 2.1, but with all the
recent changes around filtering I
On Aug 10, 2008, at 9:54 AM, Jason van Zyl wrote:
Dennis,
Just a follow up on the reports.
The reports generated by Swizzle are here (I restored them):
https://svn.apache.org/repos/asf/maven/sandbox/trunk/reports
And they are checked out in the home directory of Hudson on the CI
server.
I've just deployed a new set of snapshots for GMaven 1.0-rc-3-
SNAPSHOT. This contains a bunch of stuff. See the road-map for more
details:
http://jira.codehaus.org/browse/MGROOVY?report=com.atlassian.jira.plugin.system.project:roadmap-panel
Anyways, just wanted folks to give this new
comments for this improvement is much appreciated.
Thanks
-D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think having the intermediary bridge is a good idea, and I would be
comfortable finding the last stable version of trunk that works with
Mevenide and then release that and then leave that as a stable branch
for you to work off.
One of the problems is that your code seems not to be very
That is all OK, but I'd really like to see a 2.1 that allows more to be
done on the 2.0.x branch than we are currently comfortable with. Nothing
as revolutionary as what is in trunk, but with some ability to fix some
problems that might not be completely compatible. The bugs I am
currently
On 10-Aug-08, at 2:25 PM, Ralph Goers wrote:
That is all OK, but I'd really like to see a 2.1 that allows more to
be done on the 2.0.x branch than we are currently comfortable with.
That's the plan that people have been suggesting and what I refer to
as the intermediary bridge i.e. the
Jason van Zyl wrote:
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without being
incompatible, even if what is currently happening - deploying poms
with a variable in the version element - is just wrong.
Not
Why are you locking it here instead in the parent pom ?
I think it's a better practice to do it in an higher level ASAP to check
that we don't find regressions in our builds.
WDYT ?
If you will release the javadoc plugin, I think parents will be released
soon ?
We are just waiting for a release
On 10-Aug-08, at 5:26 PM, Ralph Goers wrote:
Jason van Zyl wrote:
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without
being incompatible, even if what is currently happening -
deploying poms with a variable
Jason,
The issues I'm finding (or my userbase actually) are not with mevenide
integration. It's also not something I could test on my side. It's in
99% of cases incompatibilities with 2.0.x. And it's not a reoccuring
pattern, no trunk-to-trunk regressions. So no test could save me from
it
On 10-Aug-08, at 9:05 PM, Milos Kleint wrote:
Jason,
The issues I'm finding (or my userbase actually) are not with mevenide
integration. It's also not something I could test on my side. It's in
99% of cases incompatibilities with 2.0.x. And it's not a reoccuring
pattern, no trunk-to-trunk
So it looks like the general consensus is:
- Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float
by as options)
- Call trunk 3.0-SNAPSHOT
We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator toward
3.0, and given the mediator exists we're a lot safer doing a 3.0-
19 matches
Mail list logo
