Thanks, I thought NB had already changed to that requirement (Eclipse
and IDEA have some time ago).
Do you have any indication of how many NB users stick to old versions? I
get the feeling they upgrade pretty fast. I'd also be interested to see
how many NB users still use JDK 1.4 to run the
+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 was the initial ghost town of empty
lists when we're trying to kick it along (even if there
+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 to latest and just
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:
I've read on
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html
the
Currently, I use Netbeans with jdk 1.4 at work (but no Maven) and with
5.0at home.
Raphaël
2006/7/7, Brett Porter [EMAIL PROTECTED]:
Thanks, I thought NB had already changed to that requirement (Eclipse
and IDEA have some time ago).
Do you have any indication of how many NB users stick to
I've applied and published this version. I still had further comments,
but it's a definite improvement (draft2 was applied before the last
release - we'll have a 2.0.2 soon to rectify this and other problems).
Thanks Pete!
Cheers,
Brett
On 7/07/2006 10:08 AM, Pete Marvin King 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 think we should omit the changelog plugin from the proposed doc
standard and the pom for now.
- Brett
On 7/07/2006 5:24 AM, jerome lacoste
On 6/07/2006 3:40 AM, Rinku wrote:
Just wondering if rather than having an exclusion list stuffed in each
of dependency elements, if we could have some sort of compatible
tag that can 'advise' Maven the choosing strategy for conflicting
artifacts (pretty much like version ranges).
For sake
On 7/7/06, Brett Porter [EMAIL PROTECTED] wrote:
Thanks, I thought NB had already changed to that requirement (Eclipse
and IDEA have some time ago).
it did update, however right at the beginning of the next release
cycle (6.0) which is a month or two back. Nb has the policy of
supporting 2
Hi Brett,
Brett Porter wrote on Friday, July 07, 2006 8:49 AM:
On 6/07/2006 3:40 AM, Rinku wrote:
[snip]
The other thing is that when an artifact is published to a repo, the
publisher can add some compatibility meta-data as well to indicate
that the current version is incompatible with
On 6/07/2006 1:32 AM, jerome lacoste wrote:
- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.
Yep, already have that for that very
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
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
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
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
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 versions
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
+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
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
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
-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
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
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.4
+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.
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
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
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
stuff
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
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:
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
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
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
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
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 you
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
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
(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
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
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
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 Maven
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
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,
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:
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
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 current
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]
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
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
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]
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:
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
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
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
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:
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
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.
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
-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
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:
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-core/artifactId
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
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]
Committed for review:
http://svn.apache.org/viewvc?view=revrevision=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
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
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
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
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:
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
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,
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.
69 matches
Mail list logo
