Hi,
I have a plugin, which is basically controlled by a config file. So,
my plugin configuration looks like this:
src/main/myPlugin/config.xml
In a module, it is desirable to reuse the parents configuration, so this becomes
../src/main/myPlugin/config.xml
or, if the module wish
On Wed, Mar 20, 2024 at 3:51 PM Tamás Cservenák wrote:
> Look here:
> https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.18/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples/FindAvailableVersions.java
Thanks, very much, Tamas,
I hop
Hi,
I am currently in the processof implementing a plugin, which should be
able to fix missing @since tags. In order to determine the correct
value for a given Java class, method, or field, I need a list of all
previous artifact versions.
Question: Are there any ideas, how my plugin can do that
a
On Tue, Aug 22, 2023 at 9:35 AM Guillaume Nodet wrote:
> * Support for XML entities / XInclude
Careful with that one! You might open a flood of security reports like
"If the included file looks like this, or that, then ..."
Jochen
-
Hi, Guillaume,
rather than suggesting (and, what's worse: discussing) code change
details: Is there, by any change, an existing code style, that we
might adopt? In particular.could we reuse tools, like an Eclipse
fornatter, and the like?
Apart from that, I'd be more than happy about the changes,
On Sun, Jul 17, 2022 at 2:22 PM Gary Gregory wrote:
>
> It looks like the Apache RAT plugin tries to validate the
> .gitattributes file (in contrast to excluding .gitignore).
>
> Is that an issue to be fixed or documented?
Looking into the relevant sources [1], I notice, that the
.gitattributes f
On Tue, Jun 22, 2021 at 9:32 PM Gary Gregory wrote:
>
> It feels to me like JPMS just plainly breaks the informal industry standard
> of the Maven project layout we have all been using for a million years.
I don't think so. Reusing test classes downstream sounds to me highly unusual.
Jochen
--
On Wed, Jun 2, 2021 at 2:38 PM Gary Gregory wrote:
>
> On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> wrote:
> >
> > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold
> > wrote:
> >
> > > What do folks think about slowly moving away from Modello
On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold wrote:
> What do folks think about slowly moving away from Modello where
> feasible to simplify the build? Does anyone find Modello a net
> positive, especially in longterm maintenance, not just in initial code
> generation?
To me, it sounds f
On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell wrote:
> Other than that, I use mvnd at work and we never had problems on any
> project. We consistently save time without the need of adding the -T
> parameter manually. Another big question is probably: is there enough
> community demand to merge
On Wed, Aug 19, 2020 at 11:49 AM Michael Osipov wrote:
>
> Am 2020-08-19 um 11:27 schrieb Jochen Wiedmann:
> > Looking at
> >
> > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6822107
> >
> > I would very much like us to abstain from every attemp
Looking at
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6822107
I would very much like us to abstain from every attempt to go into the
direction, that Stefan suggests. The consequence could be, that we
need to bother with exotic corner cases. Let's stay simple, but
reliable.
Jochen
On Fri, Jul 17, 2020 at 6:23 PM Elliotte Rusty Harold
wrote:
>
> I don't think that should be necessary. A failed 3.3.0 release should
> not use up the version number. I think there are instructions on the
> release page for unrolling a failed release, though I haven't had
> cause to use them myse
Hi, Ben,
afaict, the issue *is* closed.
Jochen
On Sat, Dec 14, 2019 at 6:09 PM Benjamin Marwell wrote:
>
> Hi all,
>
> I think issue this can be closed:
>https://issues.apache.org/jira/browse/MCHECKSTYLE-373
> The original author is just asking for how to specify a property via
> command l
On Mon, Nov 11, 2019 at 11:02 PM Robert Scholte wrote:
>
> I'd say start a release. As it is based on JSR223 is should be very easy for
> any scripting language to be supported.
Before a release, I'd recommend to have at least *some* documentation.
Jochen
--
On Thu, Nov 28, 2019 at 9:46 PM Slawomir Jaranowski
wrote:
> I'm writing some maven plugins - some for fun and with public code but more
> maven plugins I'm writing for job in my company.
>
> Maven from version 3.1.x use slf4j for logging.
>
> But plugin api still use simple logging api
> org.apa
On Thu, Apr 26, 2018 at 1:11 AM Damon Jacobsen
wrote:
> I am trying to get my feet wet with plugin development, and struggling
> with some of the basics.I am trying to get the resource I am copying into
> the build directory to be filtered in the same way that the maven
resources
> plugin works
tool like it), and
> its dedicated security issues storage and update workflow, avoid adding a new
> management nightmare at every level of Maven
>
> Regards,
>
> Hervé
>
> Le mercredi 14 mars 2018, 13:27:53 CET Jochen Wiedmann a écrit :
> > Hi,
> >
> >
Hi,
recently I had an issue, where a security problem was claimed, because
a published POM was using a jar version, for which a CVE exists. The
reporter requested to upgrade to a current version, and publish an
updated POM.
As you know, we cannot update the POM. We only publish new POM's, so
the
On Tue, Jun 20, 2017 at 7:01 PM, Owen O'Malley wrote:
>Is there already a plugin for storing the transitive dependency
> information in the jar's META-INF as part of the build? I'd like to build a
> dynamic class loader that would be similar to shared libraries on
> Linux/Unix, but part of th
On Mon, Dec 5, 2016 at 3:31 PM, Chas Honton wrote:
> My personal experience is that mixins lead to jar hell rather fast.
You have personal experience with a feature, that doesn't even exist?
I am impressed...
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystone
On Sat, Oct 15, 2016 at 4:41 PM, Stephen Connolly
wrote:
> Hmmm shower thinking now has me pondering if a custom DSL might be
> better... something close to human friendly JSON with exceptions for
> dependency declaration so that they are always specified as g:a:p:v:c:t
> with the optional p and c
Hello, Markus,
are you aware, that plexus-utils is being replaced by the maven-shared-utils?
Jochen
On Sun, Jun 12, 2016 at 6:03 PM, Markus KARG wrote:
> Hello Maven Committers,
>
>
>
> I would like to kindly ask to consider my PRs for merging:
>
>
>
> * Plexus Utils: https://github.com/codeha
On Tue, May 31, 2016 at 8:45 AM, Bhowmik, Bindul
wrote:
>
> I have never used the Rat plugin, but the Maven Checkstyle plugin
> supports something like this, by declaring checkstyle as a dependency
> of the plugin[1], which can be overridden at runtime in the end user
> pom configuration[2].
Tha
Hi,
in the rat-maven-plugin we currently have a hard cored dependency from
the plugin to the rat core with the same version number. In other
words, if one would like to use a different version of the rat core,
one needs to use a different version of the plugin.
This has got an important disadvant
On Thu, May 26, 2016 at 5:35 PM, Manfred Moser wrote:
> Seems like a performance/networking glitch. I am talking to Sonatype ops and
> support to get more info/help.
Could you please forward the conversation to me, Manfred?
Thanks,
Jochen
--
The next time you hear: "Don't reinvent the wheel!
On Thu, May 26, 2016 at 3:30 PM, Karl Heinz Marbaise wrote:
> Can you check in Nexus the tab "Activity" (at the bottom of the page) there
> you should see what has failed...
That is where I found the few details that I can give.
Thanks,
Jochen
--
The next time you hear: "Don't reinvent the
Hi,
I hope that someone can help me with the following:
I staged a release of Apache Rat 0.12 on repository.apache.org. The
staging repository is orgapachecreadur-1002. Now, when I tried to
close it, I igot an error message "1 rule failed: Apache rules". As I
don't have any more information, thus
Surprise: There might be a good explanation, finally. ("Looking for a
new opportunity" :-)
https://www.linkedin.com/in/julia-antonova-81812742?authType=NAME_SEARCH&authToken=9cIm&locale=en_US&srchid=12489281456220267701&srchindex=4&srchtotal=28&trk=vsrp_people_res_name&trkInfo=VSRPsearchId%3A12489
On Thu, Dec 31, 2015 at 1:01 PM, Robert Scholte wrote:
> The next blocking issue requires some work by the Apache Maven team and/or
> at the QDox project[2].
> QDox is a Java Parser which is used to read javadoc and/or annotations from
> source in order to generate xml or other Java files.
> With
What exactly is it, you'd like to detect?
On Wed, Nov 25, 2015 at 8:11 AM, Kristian Rosenvold
wrote:
> I poked around in the depdenedncy analyzer code to see if I could make
> it "see" the following code:
>
> Module 1:
> public class Test2 {
> public static final int AZAZ = 42;
> }
>
> Modul
On Fri, Nov 6, 2015 at 1:56 PM, Attila-Mihály Balázs wrote:
> Given that we're almost in 2015, what do people think about updating the
> default source / target for maven-compiler-plugin to 1.8? (And also on the
> site:
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compile
According to [1], we're still at 3.3.3, aren't we?
1: http://maven.apache.org/download.cgi
On Tue, Oct 27, 2015 at 2:44 PM, Jason van Zyl wrote:
> I’m going to start cutting the 3.3.7 now.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Fou
Given the low likelyhood of another release: I don't think we need to care.
On Thu, Oct 8, 2015 at 6:03 PM, Robert Scholte wrote:
> It should be the first one specified in pluginManagement
>
> Robert
>
> Op Wed, 07 Oct 2015 23:38:10 +0200 schreef Dan Tran :
>
>> Just wonder
>>
>> after the migra
On Wed, Oct 7, 2015 at 8:04 PM, Gary Gregory wrote:
> Does m2e still want to pollute POMs withcryptic entries?
There are alternative storage possibilities, but that
doesn't fix the inherited difficulties. Just mákes the
SCM purists happy (and forces other users to live with the same
trouble that
Thanks, Igor!
On Fri, Oct 2, 2015 at 3:03 PM, Igor Fedorenko wrote:
> @Component
> private ResourceManager locator;
>
> --
> Regards,
> Igor
>
> On Fri, Oct 2, 2015, at 06:31 AM, Jochen Wiedmann wrote:
>> Hi,
>>
>> I am trying to migrate a plugin from
Hi,
I am trying to migrate a plugin from XDoclet to Annotations. In my new
Mojo, I have a parameter declared like this:
/**
* Plexus resource manager used to obtain XSL.
*/
@Parameter(required=true, readonly=true)
private ResourceManager locator;
This used to work perfectly
On Sun, Sep 27, 2015 at 11:25 AM, Lennart Jörelid
wrote:
> 2. Inject a MavenProject and use it to acquire any build property you like:
>
> @Parameter(defaultValue = "${project}", readonly = true)
> private MavenProject project;
This one sounds like what I wanted.
However, there is no method lik
On Sat, Sep 26, 2015 at 10:33 PM, Karl Heinz Marbaise wrote:
> Hi Jochen,
>
> On 9/26/15 10:28 PM, Jochen Wiedmann wrote:
>>
>> Hi,
>>
>> I'd like to access $[project.build.sourceEncoding} in a Maven Plugin.
>> How would I do that? Using what version o
Hi,
I'd like to access $[project.build.sourceEncoding} in a Maven Plugin.
How would I do that? Using what version of maven-model?
Thanks,
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x8
I'd solve your problem like this, Mark:
- Create an interface for a component, which is internally using the
JDK code in question, (say IRTUser).
- Create three implementations, each of which are targeting a
particular JDK. In what follows, I'll assume that they throw an
exception when being insta
Hi, Dennis,
I'd suggest the following approach:
- Write a small stub that replaces Logger.getLogger(), so that a small
facade is returned, which behaves like JUL,
but uses the Maven logger internally.
- Use the shade plugin to ensure that Logger.getLogger is redirected
to your stub.
That way,
RfC: How Maven could be *really fast*.
http://grumpyapache.blogspot.de/2014/05/build-system-performnce-on-windows.html
--
"That's what prayers are ... it's frightened people trying to make friends
with the bully!"
Terry Pratchett. The Last Hero
is the
> component metadata is not present or it's wrong. If you hand wrote it you
> might have a typo, or you might not have the metadata generators configured.
>
> On May 6, 2014, at 6:33 AM, Jochen Wiedmann
> wrote:
>
> > Hi,
> >
> > I am trying to implement
Hi,
I am trying to implement a test case for a plugin, utilizing the Plugin
testing harness. I am getting the exception below.
Any ideas what I might be doing wrong?
Thanks,
Jochen
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
java.util.NoSuchElementException
On Wed, Feb 27, 2013 at 7:52 PM, Gary Gregory wrote:
> We've had similar discussion @Commons about a topic like this one. My view
> is that you'll never know who will step up on volunteer, or who is in
> enough pain to stand up and do the work.
>
I think the question is less of a prediction what
What's Apache sources got to do at Github anywyays?
On Tue, Dec 4, 2012 at 8:34 AM, Anders Hammar wrote:
> This git repo at Github mirrors the old Git repo. Is it possible to change
> that to the new git repo, or should it be removed all together?
>
> /Anders
>
--
The best argument for cel
In that case, it's got to be 3.0, IMO.
On Fri, Nov 23, 2012 at 11:06 PM, Benson Margulies wrote:
> On Fri, Nov 23, 2012 at 4:57 PM, Jochen Wiedmann
> wrote:
> > This would be an incompatible change, would it?
>
> Yes, indeed, insofar as anyone who scripted to expect the
This would be an incompatible change, would it?
On Fri, Nov 23, 2012 at 10:38 PM, Benson Margulies wrote:
> I want to take up a suggestion of Stephen Connolly and fix the
> interactions between shade and jar by changing the default file name
> of 'replacing' shaded jars. I'd like incremental ja
Would be happy about comments on
http://grumpyapache.blogspot.de/2012/11/rfc-improving-mavens-performance.html
Thanks,
Jochen
--
The best argument for celibacy is that the clergy will sooner or later
become extinct.
On Thu, Aug 2, 2012 at 10:58 AM, Anders Hammar wrote:
> What I have done in a customer specific plugin, is to not have a
> dependency on some library in the plugin itself but rely on it being
> declared as a dependency in the Maven project where the plugin is
> bound. That made it totally controll
No suggestions?
On Wed, Jun 13, 2012 at 12:18 PM, Jochen Wiedmann
wrote:
> On Wed, Jun 13, 2012 at 10:46 AM, Belhadj abdessalem
> wrote:
>> what would you mean *shortName would be an attribute that's derived from
>> the artifact-ID ?*
>
> Just to g
On Wed, Jun 13, 2012 at 10:46 AM, Belhadj abdessalem
wrote:
> what would you mean *shortName would be an attribute that's derived from
> the artifact-ID ?*
Just to give an example: archetype-foo -> archetypeFoo.
--
In other words: what could be seen as a socially debilitating failure
of cha
On Wed, Jun 13, 2012 at 11:27 AM, John Patrick wrote:
> Additionally how would you be using these generated attributes?
>
> In plugins?
> Filtering files?
> Other?
Let's assume for filtering files, seems to be the easiest. I'd
appreciate more complex posssibilities, though.
--
In other words:
On Thu, May 10, 2012 at 10:41 AM, Mark Struberg wrote:
> I only have those profiles in my projects. The only profile I have in my
> settings.xml is for enabling staging repos.
>
> Do you have a sample so we get an idea what you try to solve?
Mark, you're getting me wrong. I am not trying to disc
On Thu, May 10, 2012 at 10:00 AM, Mark Struberg wrote:
> The reason why it got removed is obvious: you needed to know exactly what
> goes into it. Without that info you sometimes could not even compile your
> project.
>
> What you can try nowadays is to create profiles (maybe in your parent pom
Hi,
just opening a several years old project, which was written for Maven
2 before 3.0 and is making heavy use of profiles.xml.
Reminds me how much I am missing this feature: Local profiles used to
be the most obvious, easiest to use place for
local customizations like configuring a database URL o
Sure you really want to do that? It would amount to hard wiring your
plugin to a certain phase, whereas
a plugin should typically be able to run in any phase, depending on the POM.
On Tue, Jan 3, 2012 at 5:21 AM, Carson Gross wrote:
> I'd like to detect the current phase of a build within a plug
Mark, without being a lawyer, my guess is that you mean "no one can
sue you successfully", as opposed to "no one can sue you". And I'm
sure that any reasonable person would try to avoid even the former.
Jochen
On Tue, Jun 14, 2011 at 9:58 AM, Mark Struberg wrote:
> No Robert!
>
> Even in the U
On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly
wrote:
> but having seen my mistakes I think
> I have a better handle on the right path to take!
Strange enough, that's almost definitely what Ceki Gülcü would say ... :-)
--
Capitalism is the astounding belief that the most wickedest of men
w
On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 wrote:
> The client api is a separate artifact. You can reuse it as you want. In your
> repository you will get in the same release folder two artifacts :
That's completely understood. But as a separate jar file, you should
ensure that it is compilable
What the article describes, is definitely not recommended practice.
A better approach would be to have separate projects, say "client-api"
and "client-impl", with the latter depending on the former. With your
approach, you don't enforce that the api jar file is usable
standalone.
Jochen
On Wed,
On Mon, Apr 18, 2011 at 11:17 PM, Brian Fox wrote:
> The projects that need it should add the extension to their TLP pom,
> the defaults should be sufficient for the majority of projects. If
> there's something needed for the sites to work ok, but I wouldn't add
> it just for a handful of project
On Sun, Apr 17, 2011 at 9:50 PM, Olivier Lamy wrote:
> AFAIK wagon ssh is included in site plugin 3.0-beta-3 dependencies.
That's not the same than adding it to the pom as an extension, isn't it?
> BTW there are still people deploying tru scp to p.a.o so no problem to add it.
Please, let's
Hi,
are there any reasons for *not* adding wagon-ssh (and possibly others)
to the Apache parent POM? I'd opt adding this and releasing a version
10.
Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
-
To unsubscribe,
I suggest that you use the Nexus repository manager on
oss.sonatype.org for that. If you follow the instructions at
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
then the maven-release-plugin should be able to do anything what you need.
On Tue, Mar 1,
Thanks god, this didn't become a new Perl 6 ... :-)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Works fine here.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On Wed, Aug 18, 2010 at 11:18 PM, Hervé BOUTEMY wrote:
> I have only one concern with current maven-3 code in GitHub: it's not
> compatible with maven-site-plugin 3.0-beta-1
I think, that's a blocker for a new beta release, but not for a merge, isn't it?
Jochen
--
I Am What I Am And That's Al
On Wed, Aug 18, 2010 at 10:10 PM, Jason van Zyl wrote:
> There's been little to no feedback on beta-2 so I honestly don't think it
> matters.
That's good news, isn't it? :-)
--
I Am What I Am And That's All What I Yam (Popeye)
---
On Tue, Aug 10, 2010 at 12:45 PM, Stephen Connolly
wrote:
> is a -1 really called for on a beta release with this criteria?
>
> you could just vote -0.
>
> it's only a beta
I agree with you regarding the deficiencies in the site and in the
Javadoc, but if these are tru
+1 (Non-binding)
Works good on my most important builds, within M2Eclipse as well as outside.
On Sat, Aug 7, 2010 at 1:16 PM, Benjamin Bentmann
wrote:
> Hi,
>
> We solved 28 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16090
>
> There are still a couple of
the same.
>
> Milos
>
>
> On Wed, Jun 16, 2010 at 10:20 AM, Jochen Wiedmann > wrote:
>
>> Hi,
>>
>> I have already posted the same suggestion on the M2Eclipse mailing
>> list, with very limited response, so'd like to try it once more, and
>&
Hi,
I have already posted the same suggestion on the M2Eclipse mailing
list, with very limited response, so'd like to try it once more, and
with a wider audience.
In the times when I was using "make", or "ant", there have always been
some standard targets like "all", "install", "clean" and so on.
On Tue, Apr 20, 2010 at 9:26 AM, Stephen Connolly
wrote:
> provided does not make sense for a dependency of a plugin. for a dependency
> of a project, yes, but of a plugin, no. so I would think it is an error on
> your side
You are right. After changing that the build went on flawlessly.
+1 (N
Definitely not a killer, but perhaps something to know: I just tried 3
the release build on one of my projects and got the following error
message:
[ERROR] The project
com.tsystems.icto.tom:tom-icto-dependencies:0.2.22-SNAPSHOT
(C:\workspace\tom-icto-parent\tom-icto-dependencies\pom.
On Tue, Apr 20, 2010 at 12:11 AM, Jason van Zyl wrote:
>
> On Apr 19, 2010, at 12:19 PM, Jochen Wiedmann wrote:
>
>> Just a question, without voicing an opinion: I notice the "beta". What
>> is the meaning? Are there any plans of a schedule towards a 3.0 final?
&g
Just a question, without voicing an opinion: I notice the "beta". What
is the meaning? Are there any plans of a schedule towards a 3.0 final?
Thanks,
Jochen
--
Germanys national anthem is the most boring in the world - how telling!
-
On Wed, Nov 11, 2009 at 10:28 AM, Stephen Connolly
wrote:
> Side-step the problem.
>
> Since you are substituting the build path, I am going to assume that
> you are using this database for testing.
>
> If you are not using this database for testing, then you don't want to
> be using the hard-cod
Hi,
does anyone have an idea for
a) a workaround for MRESOURCES-111; this problem is hurting me quite much
b) a recommendation of where to look at, because I did not find the
respective property
even used, so I have no idea what to inspect in order to provide a fix
Thanks,
Jochen
--
Germ
On Mon, Oct 12, 2009 at 9:13 AM, Mark Struberg wrote:
> hmm I'm using zips on a few Linux Servers, Solaris and HP-UX and had no
> problem so far. _Very_ old gunzip had a few problems, but I'm not sure if we
> have to consider them.
>
> In any case there is still the fallback to use 'jar -x' to u
most likely
to occur on Unix servers, which have a major share in the productive
systems.
On Mon, Oct 12, 2009 at 8:35 AM, Jason van Zyl wrote:
> Sorry, I don't grok that sentence at all.
>
> On 2009-10-11, at 11:31 PM, Jochen Wiedmann wrote:
>
>> Internal distributions a
ips for internal distributions and it
> hasn't caused a problem. Just figured we would cater to the windows users
> because there are more of them.
>
> On 2009-10-11, at 11:23 PM, Jochen Wiedmann wrote:
>
>> Is it really worth bothering? I see no positive aspects, apart from
>> s
Is it really worth bothering? I see no positive aspects, apart from
saving some bytes of space and a few words in the pom and/or assembly
descriptors. OTOH, you'd make us depending on the presence of a
"modern zip implementation", which Unix distributions tend to have
not. I''d strongly recommend t
Arnaud HERITIER-3 wrote:
>
> What do you think about this post and comments :
> http://relation.to/12116.laceOne thing that it seems to annoy them is how
> our reactor is working.
> We cannot call a build from a submodule which will automa(g)ically call
> necessary builds in others modules.
>
On Wed, Aug 12, 2009 at 2:59 AM, Jason van Zyl wrote:
> For Maven 2.x you'll be interested in this:
>
> http://svn.codehaus.org/plexus/plexus-containers/branches/PLX-343-plexus-container-default-1.0-alpha-9-stable-1/src/main/java/org/codehaus/plexus/component/configurator/
Thanks, I'll take a loo
On Tue, Aug 11, 2009 at 12:13 PM, Jason van Zyl wrote:
> Brian semi-abused the configuration mechanism to achieve what he wanted. But
> he did get it to work :-) We'll devise something that uses the components
> for 3.x but what's happening is that configuration elements translate into
> classes i
On Tue, Aug 11, 2009 at 6:01 AM, Jason van Zyl wrote:
> Look at the enforcer plugin. As each rule is a component that gets
> configured.
Thanks once more. I have checked the sources of the enforcer and it
sounds *exactly* like what I am looking for. However, I haven't got
the slightest idea how it
5:15 AM, Jason van Zyl wrote:
>
> On 10-Aug-09, at 1:32 PM, Jochen Wiedmann wrote:
>
>> Hi,
>>
>> in a plugin, I'd like to select a component dynamically. Basically,
>> I'd like to have something along these lines:
>>
>>
>>
&
Hi,
in a plugin, I'd like to select a component dynamically. Basically,
I'd like to have something along these lines:
...
The idea is to use the hint for looking up the "myComponent" bean and
use the XML fragment between and to
configure the bean.
Is that poss
Hi,
in order to avoid reinventing the wheel: I need to implement name
transformation in a plugin. For example, the plugin would need to
convert
a.xml -> a.html
b.xml -> b.html
but would be configurable to create
a.xml -> a-13.html
b.xml -> b-13.html
instead. Is there any exampl
Milos, with all respect: Unless Nigel is an employee of or paid by
Microsoft, IBM, or whoever might have a professional interest in the
decline of NetBeans, I do think that's a valid expression of an
opinion.
On Mon, May 11, 2009 at 8:12 AM, Milos Kleint wrote:
> On Wed, Apr 29, 2009 at 10:34 PM
On Thu, Apr 30, 2009 at 8:04 AM, Paul Benedict wrote:
> Are we sure we don't want a 2.1.1 to just get rid of some regressions?
> 2.2.0 sounds good with the reasons stated, but it just seems goofy
> 2.1.0 would have no point release after that.
If Maven 2.2 would depend on 1.5, then further maint
Agreed, but OTOH, with 2.2 requiring 1.5, this could give the push for
better support of a separation between Maven runtime and JDK being
used for the build.
Jochen
On Thu, Apr 30, 2009 at 5:23 AM, John Casey wrote:
> I just had a disquieting thought:
>
> Assuming we require JDK 1.5 for Maven 2
On Tue, Apr 28, 2009 at 11:02 PM, John Casey wrote:
> So, what is an adequate reason in your eyes for moving to 1.5?
The thread you mentioned contained a few. ;-)
--
Don't trust a government that doesn't trust you.
-
To unsu
On Tue, Apr 28, 2009 at 10:24 PM, John Casey wrote:
> 1. MNG-4140: even working around the NoClassDefFoundError for XPath* in JDK
> 1.4, this means that version expressions won't be interpolated on
> install/deploy unless JDK 1.5+ is used. This was something we talked about
> in [1].
If I unders
On Tue, Apr 28, 2009 at 9:33 PM, John Casey wrote:
> However, there is another issue that I feel is important to address:
> MNG-4147.
I have to admit that I find the problem of a "very long password" fairly exotic.
Apart from that, there should be a possible workaround by explicitly choosing
the
On Tue, Apr 21, 2009 at 5:05 AM, Brian Fox wrote:
> projects to produce proper releases. I think to do it and avoid conflicts
> with any existing profiles, I would change the profile name from "release"
> to "apache-release" and activate that by default. Does anyone see any
> downsides to this?"
Used it for todays work, including with M2Eclipse.
+1 (Non-binding)
On Thu, Mar 19, 2009 at 1:12 AM, John Casey wrote:
> Hi everyone,
>
> It looks like Maven 2.1.0 is ready to release.
>
> You can try the binaries here:
>
> http://tinyurl.com/maven-2-1-0-vote
> (https://repository.apache.org/co
On Mon, Mar 16, 2009 at 5:51 PM, John Casey wrote:
> It looks like the last known bugs are resolved for 2.1.0. So, let's take
> another look things with RC3, and if everything is clean I'll call a vote in
> the next day or two.
>
> http://tinyurl.com/maven-2-1-0-RC3
> (https://repository.apache.o
1 - 100 of 300 matches
Mail list logo
