Brett Porter wrote:
Colin Sampaleanu wrote:
There are some creative ways to get flexible and less verbose with
scopes. In Ivy for example, scopes can inherit from each other, first
of all. Secondly, when declaring configs (scopes) of dependencies
that you need, and declaring configs (scopes
Brett Porter wrote:
Colin Sampaleanu wrote:
Thanks Brett,
These days I don't normally track the discussion on a daily basis on
the dev or user lists, so had not see any, in a cursory look.
Filtering on 'scope' in the subject I've found "A dependency with
compi
enda for the (hopefully final) IRC meeting
tonight. Anyone is welcome to attend, or attach your comments in
advance to the wiki page which I'll have up shortly.
Thanks,
Brett
Colin Sampaleanu wrote:
I was taking a look at the description of the Scope support in Maven 2:
http://m
night. Anyone is welcome to attend, or attach your comments in
advance to the wiki page which I'll have up shortly.
Thanks,
Brett
Colin Sampaleanu wrote:
I was taking a look at the description of the Scope support in Maven 2:
http://maven.apache.org/maven2/dependencies.html
but am confused as to
I was taking a look at the description of the Scope support in Maven 2:
http://maven.apache.org/maven2/dependencies.html
but am confused as to hove Maven 2 handles dependencies which are needed
only for compiling, but _not_ at runtime.
Consider the example of the servlet apis (or really any ot
yrepo) to store extra info (basically the ivyxml files for vairous
modules) in addition to the data available in the Maven POMs on iBiblio.
Regards,
Colin
--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springfram
I just saw a reference to a new (open-srouce) build management tool
called Invicta, and after looking at it a bit I thought you guys might
find its approach interesting as a source of ideas or at least in
comparison to Maven.
http://invicta.sourceforge.net/
http://invicta.sourceforge.net/manual
Jason van Zyl wrote:
On Sat, 2003-09-20 at 15:41, Colin Sampaleanu wrote:
I wanted to get the rationale as to why build.properties from
${user.home} is more dominant than build.properties and
project.properties from the project dir.
To provide a final place where all values can be
I wanted to get the rationale as to why build.properties from
${user.home} is more dominant than build.properties and
project.properties from the project dir.
This has always seemed ass-backwards to me, and is in fact backwards to
the order in which a number of ant projects I've seen (and mine)
[EMAIL PROTECTED] wrote:
Colin Sampaleanu <[EMAIL PROTECTED]> wrote on 19/09/2003 05:07:29 AM:
...
may even be released as the final version. As such, I don't think this
would really qualify. There are a number of serious issues to still
resolve (one affecting me for example, i
I really like the idea of another public release which incorporates all
the fixes since b10.
Maybe I'm just being picky, but I think beta-11 is a much more
appropriate name than RC1. Release Candidate implies it's a candidate
for release, with generally no known bugs (non-trvial, anyways) which
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
I was thinking that it would be useful to enhance the artifact plugin to
support deploying artifacts which are not the primary artifact produced
by the project.
I have a project which builds a jar file. That project also uses a jar
file which is manually built once in a while. It lives in the /
If an artifact is not available in the remote repo(s), but is available
in the local repo, and downloaded from there, maven tells you so. It's
perfectly normal for some artifacts to only be availble locally, say if
you created them yourself and did an install.
Why should maven draw attention to
I built maven from bootstrap, killing the old repo just to be sure. The
build went ok (although running maven afterwards on itself does fail in
one of the touchstone tests).
Now, I do
maven eclipse:generate-project
and it works fine. But if I do
maven eclipse
which is simply defined as
prer
I know after the refactoring last week it was not recommended that HEAD
be touched for a while. Is it relatively usable again?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I tried the .tgz version on a simple build. Seems to work ok, except for
oddity on the first attempt to download all the dependencies for the
plugins. Got an issue with Velociry as follows:
Attempting to download velocity-1.3.jar.
.
.
java.lang.ClassNotFoundException: velocity
Michal Maczka wrote:
...
Last time I am asking:
Does anybody has something against building war ___always__ in two distinct
steps?
a) copying to build area (somewhere in target/ )
b) making a jar archive
Yes, this is the best way to do it. If your servlet engine can use
exploded webapps it
Don't forget that ant only allows you set a property once and then you
may not override it. So your initial instinct with a system that allows
a new value read in to override an old one (such as Maven itself when it
reads its own property files) is to put the user level file last, with
ant, you
+1
Diego Fernandez wrote:
The eclipse:generate-project generates the .project file and .classpath
files.
But some times is useful to re-generate only the .classpath while
keeping a custom .project.
eclipse --> calls eclipse:generate-project and
eclipse:generate-classpath
eclipse:generate-project
20 matches
Mail list logo
