Inside the Maven2 repo, this pom for SLF4J 1.0 appears to be in Maven2
format:
http://www.ibiblio.org/maven2/org/slf4j/slf4j-log4j12/1.0/slf4j-log4j12-1.0.pom
but this one for SLF4J 1.0.1 appears to be in Maven1 format:
http://www.ibiblio.org/maven2/org/slf4j/slf4j-log4j12/1.0.1/slf4j-log4j12
define dependency blocks with ID.
*javax.faces*
jsf-api
jsf
Then users of Spring framework may include them:
*org.springframework*
spring-webflow
default,jsf
Eric
On 4/30/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
I am curious how heavy Maven2 us
you always know
exactly what you have and what you need.
just my 2 cents
On 4/30/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
I am curious how heavy Maven2 users are getting around the lack of
custom scopes.
Profiles seem to fill the need sometimes, allowing you to produce a
module (j
I am curious how heavy Maven2 users are getting around the lack of
custom scopes.
Profiles seem to fill the need sometimes, allowing you to produce a
module (jar file) that is specific to a particular profile, having
dependencies specific to that profile.
This assumes you are actually ok wit
#x27;t see the probelm with JSPs because you would at most filter the
web.xml setting a parameter that is later accessed at runtime from the
jsps. I can't think about a use case where you would need to filter
all the jsps at build time.
On 4/29/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrot
o idea how/where to
modify the "default filter string pattern" if it is even possible.
Wayne
On 4/29/06, Colin Sampaleanu <[EMAIL PROTECTED]> wrote:
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '
On 4/29/2006 4:55 PM, Simon Kitching wrote:
On Sat, 2006-04-29 at 16:09 -0400, Colin Sampaleanu wrote:
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any w
Hi,
When turning on filtering for resources in Maven2, is there any way to
override the default filter string pattern of '${token}'? I can't find
any mention of any way to customize this, in any docs.
The use of ${token} as a token is IMHO a really bad choice, given the
fact that it's such
The maven xdoclet plugin is huge because it is actually generated (as
part of the xdoclet build).
I personally find it generally useless. For anything more than the
simpler cases, it is easier and cleaner to have 'ant-style' xdoclet
definitions in maven.xml exactly as you would have used in an
ns of course that you have to put all properties at
the top level.
Thanks
-Vincent
-Original Message-
From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]
Sent: 19 September 2003 20:30
To: Maven Users List
Subject: Any way to have shared properties when extending from a base
project
I just rea
I just realized that while you can extend a project with something like
extend>${basedir}/../master/project.xml
maven doesn't seem to read in build.properties (and project.properties
either I guess) from the master project. This is a real PITA, as I don't
want to force people to put identical b
You can definitely use file: references to set up remote repos. I use
this definition for maven.repo.remote in some projects:
maven.repo.remote=\
file:${basedir}/../../shared/repository,\
http://www.ibiblio.com/maven
Try using 'file:' instead of 'file://', the latter is not really kosher.
y but just the jar files.
I don't know if this new or not, I'll post it into JIRA anyway.
Rogelio
-Original Message-
From: Robles, Rogelio [mailto:[EMAIL PROTECTED]
-Original Message-
From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]
However, note
Colin,
which is the bug report?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Colin Sampaleanu <[EMAIL PROTECTED]> wrote on 12/08/2003 10:48:37 PM:
You can definitely use file: references to set up remote repos. I use
this definition for maven.
You can do something like this in maven.xml:
file="${basedir}/lib/core/xmltypes.jar"
tofile="${jardir__}/${pom.artifactId}-xmltypes-${pom.currentVersion}.jar"
overwrite="true"
/>
However, whether this is a good idea is another question. In this case,
the ja
Are you expecting that this will be merged back into HEAD, or HEAD
merged into this in the future? Unfortuntately I think your chance of
merging 2 diverged branches (where ongoing work has gone on in both)
with CVS is next to nil. What is probably more realistic is for Jason
or whoever to do
Can anybody think of a way to make Maven support use of ant filterchains
when copying resources, short of completely overriding the resource
copying code? I don't think there is any way, but maybe somebody has an
idea...
We find filterchains like
with the ant copy task extre
If you are doing mostly C/C++ with some Java, you might want to look at
SCons. It's _way_better thank makefiles, and now has some knowledge of
Java, although nothing on the level of Maven. Presumably you could have
SCons call out to Maven or Ant for more complicated Java work.
http://www.scons
Jason van Zyl wrote:
On Tue, 2003-06-17 at 11:37, Jason van Zyl wrote:
Hi,
I wanted to check with users about the frequency of using ${pom.X}
notation in properties files. I would like to remove this feature as it
is causing some grief internally and the only place I see it being used
internal
There is another bug related to the repo override which I reported a
long time ago
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-224
and I don't think has been fixed. Effectively, repo overrides don't work
as far as plugins are concerned. Not necessarilly much of an issue for
the plu
It's a bit of a hack in that ideally you would nest the projects, but it
should work fine, although you might have to work on the reactor setup a
bit so you don't include your root.
The main issue with using Eclipse in similr scenarios is when you get
handed a maven or ant based nested structur
This is a problem, because while Eclipse can handle nested sources via
exclusion filters, it can't actually handle nested projects where you
need to have the eclipse project metadata somewhere at a root level, and
below that have eclipse project metadata for other projects.
Now what will work i
btw, maven plugins can be found in the plugins dir underneath the local
repository location...
Colin Sampaleanu wrote:
I see what you are getting at. The maven docs which mention goals in
maven.xml
http://maven.apache.org/reference/user-guide.html#maven.xml
are basically not giving any info
ng for was some information on what goals are and how
to write them. As far as I understand, in order to add project
specific functionality to maven I need to add goals in a similar way
as I added targets in ant.
Cheers
Neil
Colin Sampaleanu wrote:
You can find some werkz documentat
You can find some werkz documentation here:
http://werkz.werken.com/
although you normally shouldn't have to understand werkz that much if
all you want to do is use maven (as opposed to hacking it).
Neil Blue wrote:
Hello,
I am trying to get started with Maven, but I can't find any
documentat
Jason van Zyl wrote:
On Wed, 2003-04-02 at 09:05, Rafal Krzewski wrote:
Jason van Zyl wrote:
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirem
Jason van Zyl wrote:
On Tue, 2003-04-01 at 10:33, Colin Sampaleanu wrote:
Jason, can you clarify what the real issue with multiple source
directories is?
...
Given that Maven already does support
multiple source dirs in the only fashion I use them (to separate test
sources from non
Jason van Zyl wrote:
On Mon, 2003-03-31 at 19:29, [EMAIL PROTECTED] wrote:
"Mark H. Wilkinson" <[EMAIL PROTECTED]> wrote on 01/04/2003
01:44:01 AM:
On Fri, 2003-03-28 at 20:57, Mark McBride wrote:
Ahh; see what you mean. I don't think it would be that difficult to add
support for that kind of
28 matches
Mail list logo
