Hi,
It looks like the Archetype component is pluggable,
since there's one named DefaultArchetype? Is there
any documentation that describes how to make the
substitution happen?
I need to make one that I can substitute for the
default, such that a multi project archetype istance
can be created.
OK - Doh - I was a little quick to just copy and paste
the dependencies from the subversion pom without
adding scope. I added compile and now it tells me
that the project is not available. I'll have a look
around for it or install manually.
--- Ole Ersoy <[EMAIL PROTECTED]> wrote:
> Hey Guys,
what problem(s) did you get?
Dennis Lundberg wrote:
Brett Porter wrote:
Hi Dennis,
These should be inherited from the parent if you set the parent to
2-SNAPSHOT. This will also use a more recent snapshot of the plugin
plugin which has the improved formatting of the goal parameter tables
a
An issue hosting artifacts not on ibiblio is the Maven group has tried to
centralize on ibiblio so we all don't have to have dozens of different repos
in our config.
-Original Message-
From: Mik Kersten [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 9:38 AM
To: 'Tomasz Pik'
Cc: [
Brett Porter wrote:
+1, pending the resolution of MPMD-36 (pom packaging, could be a won't
fix) and MPMD-34 (docs have one failure in docck).
One thing to watch out for - currently the parent is plugin parent
2-SNAPSHOT. We might need to either release that (setting the
plugin-plugin report t
On 7 Jul 06, at 7:27 AM 7 Jul 06, Brett Porter wrote:
+0
Definitely want these, but I was really waiting until traffic
demanded it, as there's none on here at the moment. Is this
primarily about separating the commits?
No, discussions regarding the repository manager itself. FishEye is
Sounds fine... +1!
On 8/07/2006 2:28 AM, Mike Perham wrote:
I've closed MPMD-36 as Won't Fix and just ran docck against the latest
source and it passed.
Its parent is still maven-plugins v1. I'm not sure if someone reverted
it, I'm misunderstanding you or if you were just mistaken. Either way
Committed for review:
http://svn.apache.org/viewvc?view=rev&revision=420011
I have not created a link to this page in the index page yet. Will do
that if review goes well.
Brett Porter wrote:
CTR
On 6/07/2006 7:10 AM, Dennis Lundberg wrote:
Do you prefer
- commit then review
or
- review t
The patch and notes are available on
http://jira.codehaus.org/browse/MASSEMBLY-67
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://jira.codehaus.org/browse/MJAR-28
Summary:
When creating a Jar with a classpath entry, MavenArchive creates the
classpath values using -SNAPSHOT.
When creaing an Assembly the dependencies are copied over as
timestamped snapshot versions.
Either the classpath should use the timestamped vers
Hey Guys,
I'm trying to create a new archetype component,
however I'm having issues loading the the Archetype
interface.
I put the following in the pom dependency list:
org.apache.maven.archetype
maven-archetype-core
1.0-SNAPSHOT
I also tried changing the version to
-Original Message-
> From: Tomasz Pik [mailto:[EMAIL PROTECTED]
...
> Yes. But this brings up a bigger question about providing jars
> in a way that Maven will be able to use (which means a repository
> with given layout of directories/fiels) - is there a way to setup such
> a thing on ecl
Possibly. There's no reason not to offer any jvm whose license will allow
it. Any other can be manually installed.
Eric
On 7/7/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
Yikes. That strikes me as truly scary and assumes that everyone is
running Sun compilers/JVMs. Am I misunderstanding s
On 7/7/06, Mik Kersten <[EMAIL PROTECTED]> wrote:
Eclipse.org provides us with an excellent download infrastructure and
mirroring system, so it's probably simplest to use that. It would make
bundling the JARs and maintaining dependencies Mylar's responsibility.
Anything extra you would need (i.e
Brett Porter wrote:
Hi Dennis,
These should be inherited from the parent if you set the parent to
2-SNAPSHOT. This will also use a more recent snapshot of the plugin
plugin which has the improved formatting of the goal parameter tables
and doesn't overwrite your index.html :)
Sorry about th
Thanks Brett
Brett Porter wrote:
Done
On 6/07/2006 10:11 AM, Dennis Lundberg wrote:
Any chance of me being added to the appropriate group in Confluence,
so that I can edit pages in the MAVEN space.
Brett Porter wrote:
Dennis,
I've put you on this page:
http://docs.codehaus.org/display/MAV
Eclipse.org provides us with an excellent download infrastructure and
mirroring system, so it's probably simplest to use that. It would make
bundling the JARs and maintaining dependencies Mylar's responsibility.
Anything extra you would need (i.e. the poms) would be best as a
contribution you make
Yikes. That strikes me as truly scary and assumes that everyone is
running Sun compilers/JVMs. Am I misunderstanding something?
Regards,
Alan
Carlos Sanchez wrote:
I think we should add the rt.jar and tools.jar to the repo as any
other dependency, to allow building with 1.5 against 1.4 rt.j
I've closed MPMD-36 as Won't Fix and just ran docck against the latest
source and it passed.
Its parent is still maven-plugins v1. I'm not sure if someone reverted
it, I'm misunderstanding you or if you were just mistaken. Either way,
let me know if you want me to hold off on a release or I'll r
I guess I ham-fisted it cause it worked when I tried it just now. Maybe
maven took a smoke break and installed the jar a few minutes later. :-)
-Original Message-
From: jerome lacoste [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006 11:11 AM
To: Maven Developers List
Subject: Re: ru
On 7/7/06, Mike Perham <[EMAIL PROTECTED]> wrote:
Thanks Jerome, but when I try to run that it just gives me the generic
can't find plugin error. I tried building and installing it from the
sandbox but I still got the same error. I tried to deploy a snapshot of
it and got this error:
[INFO] Er
Thanks Jerome, but when I try to run that it just gives me the generic
can't find plugin error. I tried building and installing it from the
sandbox but I still got the same error. I tried to deploy a snapshot of
it and got this error:
[INFO] Error installing artifact's metadata: Error while depl
I remember a while back a discussion about accepting licenses as part of
Maven's downloading artifacts with non-apache constraints (such as sun
jars). Has anything come of this in 2.1? That might be the answer right
there.
Eric
On 7/7/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I think we sh
I think we should add the rt.jar and tools.jar to the repo as any
other dependency, to allow building with 1.5 against 1.4 rt.jar. Of
course we'll hit again the Sun policy about redistribution and people
would have to put it by hand in their repos.
On 7/7/06, Kenney Westerhof <[EMAIL PROTECTED]>
On Fri, 7 Jul 2006, [ISO-8859-1] Trygve Laugstøl wrote:
> Uhm, no. All you have to do to be 100% that it works in a 1.4
> environment is to fork the compiler. AFAIK the Eclipse compiler should
> also be able to build 1.4 code safely against the 1.4 rt.jar
>
> Still this really won't change the cur
On 7/7/06, Mike Perham <[EMAIL PROTECTED]> wrote:
Can someone update this page with instructions on how to run docck on a
plugin?
http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation
I've tried with
mvn docck:plugin
it works on some but not on at least one of my plugins:
See ht
Can someone update this page with instructions on how to run docck on a
plugin?
http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Steve Loughran wrote:
Brett Porter wrote:
Hi,
I wanted to get thoughts on starting to require a Java 5 JVM to run
stuff we build. We currently restrict to 1.4 across the board.
Here's what I'm thinking:
- MRM and Continuum should switch now. Stuff built there is rarely
consumed elsewhere,
Oh, then +1 pending improved historical support!
Brett Porter wrote:
As far as Maven goes, this would only be the JVM used to run it - it
needs to be able to build projects using any JDK available (and the
support for that needs to first be improved).
On 7/07/2006 8:15 PM, Andrew Williams wro
Sounds like a great idea! (not +1'ing since I didn't see an official vote
yet)
The toolchain stuff will be nice for projects with 1.4 vs 1.5 releases in
the mix as well.
On 7/7/06, Fabrice Bellingard <[EMAIL PROTECTED]> wrote:
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> As far as Ma
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
As far as Maven goes, this would only be the JVM used to run it - it
needs to be able to build projects using any JDK available (and the
support for that needs to first be improved).
+1 for Continuum and MRM switching now to Java 5
+1 for M
Brett Porter wrote:
Hi,
I wanted to get thoughts on starting to require a Java 5 JVM to run
stuff we build. We currently restrict to 1.4 across the board.
Here's what I'm thinking:
- MRM and Continuum should switch now. Stuff built there is rarely
consumed elsewhere, and a Java 5 requirement
(user votes)
+1 Starting with Continuum/MRM as it might trigger some issues which
yield experience before doing Maven
+1 On FAQ documentation on how to run maven in JDK 1.5 but compile with
JDK 1.3/1.4 API's (not just -source).
I would really like the ability to write tiger annotated maven
Edwin Punzalan wrote:
You can put any artifact as a dependency (whether it contains classes
or just plain text files doesn't matter ) and then you can get files
from it using the classloader Resource.
This is not solution for me. I'm working on plugin for eclipse builds.
There is set of ant-s
Brett Porter wrote:
This would actually be irrelevant if we supported annotations, though,
since we could use either qdox for 1.4 source or the annotations for 1.5
(similar to how testNG works).
True, but how would you tell the difference between a file using 1.4 and
1.5 sources? I guess a fl
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
This would actually be irrelevant if we supported annotations, though,
since we could use either qdox for 1.4 source or the annotations for 1.5
(similar to how testNG works).
I don't understand why you consider this irrelevant?
--
Whenever yo
Hi!
I want to deploy my artifact via ftp. So this is my command:
mvn -e -Durl=file://ftp://some-server/root-dir/
-Dfile=com.company.models.util_1.2.0.jar
-DrepositoryId=ftp-company-snapshot -DgroupId=com.company.models
-DartifactId=com.company.models.util -Dversion=1.2.0-SNAPSHOT
-Dpackaging=jar
This would actually be irrelevant if we supported annotations, though,
since we could use either qdox for 1.4 source or the annotations for 1.5
(similar to how testNG works).
On 7/07/2006 8:44 PM, Trygve Laugstøl wrote:
Brett Porter wrote:
I believe qdox has been fixed and we just need an upgr
Brett Porter wrote:
I believe qdox has been fixed and we just need an upgrade, but I'm not
sure. AFAIK it doesn't work with the current version.
It does not work in current version of the java plugin tool since qdox
1.5 doesn't support generics.
I tried to upgrade to qdox 1.6-SNAPSHOT and it
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I believe qdox has been fixed and we just need an upgrade, but I'm not
sure. AFAIK it doesn't work with the current version.
Thanks, qdox was the keyward I was missing. QDOX-94 is still open and
without any comments. IMO, this is a big hurdle
OK, this apt file is not in synch with current public maven site, so
searching "You can use any JDK to compile" had no result.
Here is my patch
Brett Porter a écrit :
maven-compiler-plugin/src/site/apt/examples/compile_using_different_jdk.apt
On 7/07/2006 8:29 PM, Nicolas De Loof wrote:
maven-compiler-plugin/src/site/apt/examples/compile_using_different_jdk.apt
On 7/07/2006 8:29 PM, Nicolas De Loof wrote:
Looking in maven-compiler-plugin I don't find the howto document.
Did I miss something ?
Nicolas De Loof a écrit :
I'll checkout maven-compiler-plugin from SVN and prepare
I believe qdox has been fixed and we just need an upgrade, but I'm not
sure. AFAIK it doesn't work with the current version.
On 7/07/2006 8:29 PM, Jochen Wiedmann wrote:
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I wanted to get thoughts on starting to require a Java 5 JVM to run
stuf
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I wanted to get thoughts on starting to require a Java 5 JVM to run
stuff we build. We currently restrict to 1.4 across the board.
I have a question, Brett: Is it currently possible to write Plugins in
Java 5? I remember, that that the annotat
Looking in maven-compiler-plugin I don't find the howto document.
Did I miss something ?
Nicolas De Loof a écrit :
I'll checkout maven-compiler-plugin from SVN and prepare a doc patch.
Brett Porter a écrit :
This is a good alternative. I think it should be added to the
documentation (both ap
+1 if a practical solution to compile pre Java5 code is documented. (I
still use 1.3 on some projects)
There is doc for the compiler plugin, but I don't think the aspectj
plugin has an equivalent for this and uses maven bootclasspath.
Emmanuel Venisse a écrit :
I'm +1 for Continuum/MRM.
Andrew Williams wrote on Friday, July 07, 2006 12:16 PM:
> -1 We have to support 1.4 as we a re rolling into academic
> environments where the upgrade cycle is > 3 years, so many users are
> still
> new to 1.4
> (though they do not know it). And to be honest I just don't trust 1.5
> generating 1.
As far as Maven goes, this would only be the JVM used to run it - it
needs to be able to build projects using any JDK available (and the
support for that needs to first be improved).
On 7/07/2006 8:15 PM, Andrew Williams wrote:
-1 We have to support 1.4 as we a re rolling into academic environm
-1 We have to support 1.4 as we a re rolling into academic environments
where the upgrade cycle is > 3 years, so many users are still new to 1.4
(though they do not know it). And to be honest I just don't trust 1.5
generating 1.4 code...
A
Brett Porter wrote:
Hi,
I wanted to get thoughts on
I'm +1 for Continuum/MRM.
For Maven, I think lot of project use always 1.4. So if we use 1.5, we'll can perhaps create an 1.4
version with RetroWeaver.
Emmanuel
Brett Porter a écrit :
Hi,
I wanted to get thoughts on starting to require a Java 5 JVM to run
stuff we build. We currently restr
I'll checkout maven-compiler-plugin from SVN and prepare a doc patch.
Brett Porter a écrit :
This is a good alternative. I think it should be added to the
documentation (both approaches should be documented).
Can you provide a patch?
Thanks,
Brett
On 5/07/2006 5:33 PM, Nicolas De Loof wrote
+1 on lists
+0 on setting it up
+1 on tinkering with internal docs ;)
A
Brett Porter wrote:
+0
Definitely want these, but I was really waiting until traffic demanded
it, as there's none on here at the moment. Is this primarily about
separating the commits?
The one thing I wanted to avoid
On 7/7/06, Mik Kersten <[EMAIL PROTECTED]> wrote:
Could you please create a bug report for us to indicate how you want to get
this API, e.g. have a downloadable bin+src JAR, separate JARs, build from
source? http://www.eclipse.org/mylar/bugs.php
Ideally I'd like just to define, that my code d
On 7/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I think we need a specific (past) version of the plugins in use in the
parent (it used to work with the plugin-plugin, so this must be possible).
I've tried without success. I wonder if the fact that the
ProjectSorter doesn't care about version
On 6/07/2006 2:19 AM, Mark Hobson wrote:
Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1? So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for reproduc
I think we need the necessary auditing in the repository manager for
this first, but it's worth moving on. I'm trying to get that up and
running right now, and writing some internal docs so others can dig in
and do stuff like this.
The ideal is actually to have those segments of the repository
On 7/07/2006 4:58 PM, Jörg Schaible wrote:
You may also have the need to exclude a version in that range because of a
critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not
with 2.0.1, that one had introduced a major bug, that broke proxytoys.
you can already do that fro
On 7/07/2006 4:51 PM, Milos Kleint wrote:
I think I can forbid installing the netbeans modules when running on
1.4. My concern was how the 1.4-compiled netbeans binaries will play
with the 1.5-compiled binaries of mevenide. (or if I compile mevenide
with 1.4, how wil it play with 1.5-compiled mav
58 matches
Mail list logo
