Tim,
I see where you're going and in general I agree with you as I think most
software should be extensible to handle unknown environments and unique
situations. However, I think the biggest bang for buck is to fix/enhance
the current one way and then add pluggability for POM parser substitution
I see your +1000 and will raise you +5000 as this is really needed.
Wb
On Feb 10, 2008 8:08 AM, Arik Kfir <[EMAIL PROTECTED]> wrote:
> As a long-time Maven user: a big +1000 from me :)
>
>
> --
>
> Thanks,
> Arik Kfir.
>
Hell yes, I'm all for the changes, especially the ability to clean the
repository of snapshots!! Ideally, I would like to have archiva
periodically keep the last x snapshots and delete the rest. The only other
thing I think is sorely missing is LDAP intregration. Jira, Confluce,
Pulse, Jive, an
As for modding the build order, I'm still not sure that's possible (or
advisable, in the larger context)...currently, I've only used the
build-context concept in maven-core as mainly a read-only data structure,
after it's setup. Are you talking about the need to inject new projects to
an existing
I've read the doc and the irc and while I can see the benefit to a shared
context, I'm curious as to whether the current pressing need is coming more
from maven or the kepler project? Doesn't matter either way just looking
for the origin of the pain. This proposal looks to satisfy some of the OS
Thanks Brett. I'll try digging through it later tonight.
Wb
On 12/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
DefaultPluginManager is the place to look. You are looking for the
creation of a child plexus container, and jar resources being added
to that.
On 07/12/2006, at 10:20
Can a dev comment on http://jira.codehaus.org/browse/MANTRUN-51 and/or
http://jira.codehaus.org/browse/MANTRUN-63 since I'm pretty sure their one
and the same? This is such an issue to work around that previously I got
around it by breaking my command invocation into 2 separate mvn invocations
th
I'm all +1 for more frequent releases too. However, this issue goes to the
core of an issue I brought up previously where maven should publish a build
milestone/release schedule similar to eclipse. For example, no one is
asking the Eclipse platform guys and gals to please make a release because
IIRC those are "standard" mappings and they are defined inside the
components.xml defined in the maven-core plugin in your /lib
directory. Because your plugin is not a "standard" plugin you have to use
the element with your plugin declaration in the pom of the
project that uses the maven-wsr-plu
fixed. May take a look at that piece later, later.
Wb
On 9/10/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
Thanks Brett, I guess I'll need to debug this later today as it's annoying
that it's not happening. I hopefully will submit a patch if I get to it
before someone
k.
On 10/09/2006, at 2:11 PM, Wendell Beckwith wrote:
> Is there a problem with executing the 2.1 trunk code with the -X or
> --debug
> options? I have 2 separate trunk checkouts, one from a week ago
> and one I
> just built. Both builds seem to work fine with the exception that
Is there a problem with executing the 2.1 trunk code with the -X or --debug
options? I have 2 separate trunk checkouts, one from a week ago and one I
just built. Both builds seem to work fine with the exception that it is
impossible to get debug output out of them it I pass --debug or -X on the
John Casey <[EMAIL PROTECTED]> wrote:
Where the finalName is important in the filename, I think the only
alternative is to copy (ugh, I know) the file inside ${
project.build.directory} with the appropriate name, and reference that
file.
-john
On 9/6/06, Wendell Beckwith <[EMAIL PROTECTED]&g
at repository without introducing ambiguity or
unreasonable performance penalties. Maybe it'll change for 2.x, but there
are no plans to do so right now.
Does that help?
-john
On 9/2/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
>
> I am working on creating a plugin to specifically do
e
a
chance to fix problems that are occurring in the assembly and clover
plugins
as well, I believe.
Cheers,
John
On 9/5/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
>
> On 5 Sep 06, at 2:55 AM 5 Sep 06, Milos Kleint wrote:
>
> > On 9/5/06, Wendell Beckwith <[EMA
On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote:
If you've done the work, go ahead and submit a patch. I think I'll
find the code easier to read than this mail :)
Done. Yeah, the email was verbose but the code changes were simple once I
found where the reactor was located.
I think we defi
I was hoping to get some discussion going about
http://jira.codehaus.org/browse/MNG-2546. For handling eclipse plugins this
is a big issue. I really see this as extending the support that maven
provides to single project builds to multi-project builds. A lot of plugins
dynamically add informati
On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote:
On 30/08/2006, at 6:10 AM, Wendell Beckwith wrote:
> For my team, I have been using, with minor adaptations, the eclipse
> dev
> process and in general I think it has the right amount of
> "agility". We
> post o
I am working on creating a plugin to specifically do Eclipse plugin builds
and OSGi bundles as a consequence that all plugins are bundles. I have run
into a problem where some parts of eclipse doesn't care what the name of a
jar file is as long as it's contents is correct. Then there is the Ecli
On 8/30/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Good morning,
...
More importantly, is anyone willing to help? Particularly if we could
grab this data from JIRA and automate it, it would be a lot easier.
This is something I could help do. I have written plugins for jira, but not
Co
Sorry, I did walk away there for a little bit.
On 8/27/06, Brett Porter <[EMAIL PROTECTED] > wrote:
On 28/08/2006, at 7:14 AM, Wendell Beckwith wrote:
> Take toady's latest example, say you want to remove an ant build
> file and do
> things the maven way, so you decide t
I primarily deal with 2 open source organizations, Apache and Eclipse. To a
lesser degree, I also interact with tigris.org for subversion and subclipse,
springframework.org for more and more each week it seems and a few other
".org" organizations. I like to think I grok open source software and
I looked through the open issues and didn't see anything but is there any
known gotchas about using alternate compilers with the
maven-compiler-plugin, like it's not fully baked/supported yet? Because as
issue http://jira.codehaus.org/browse/MCOMPILER-43, details it is unsafe to
use the eclipse c
On 8/3/06, nhb <[EMAIL PROTECTED]> wrote:
Hi,
Brett invited me to post an idea or two I had to the list:
Maven Curator
+1 - This just rolls of the tongue.
Wb
I would strongly favor this approach as it has fixed issues with our
projects where we now just specify the execution environment to be java 1.4and
5.0 and individuals can use different maintenance versions of Sun's java 5
jdk as well as some of the diagnostics in BEA's jrockit 5.0 jdk without
cha
Alternative component support would be a big win for maven 2.1 on the
OSGi/Eclipse bundle front. I look forward to hopefully contributing in this
area.
Wb
On 7/12/06, John Casey <[EMAIL PROTECTED]> wrote:
Hi everyone,
...
* Alternative Component Support
In order to flex to meet the n
-2.0" as a repo group and
adding this dependency to your pom would transitively resolved when the
group was resolved and add spring-2.0, commons-logging-1.1, log4j-1.2.13 and
hibernate-3.1.3 to the classpath for the project.
Wb
On 6/9/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Wen
On 6/9/06, Brett Porter <[EMAIL PROTECTED]> wrote:
It's totally possible, but you're probably going to need a custom Maven
installation at this point.
- Brett
Wendell Beckwith wrote:
> I recently raised from the dead the previous talk about mavenizing the
> development of
I recently raised from the dead the previous talk about mavenizing the
development of eclipse (or rather OSGi bundles) plugins, The thread can be
seen here, http://dev.eclipse.org/mhonarc/lists/pde-build-dev/maillist.html.
My question for the devs is that if we need to modify m2's dependency
reso
29 matches
Mail list logo
