Archetype Component Development Questions
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. So it will create both the parent project and the child projects. Is anyone working on something like this already? I tried using the same dependencies as the maven-archetype-core project, but they are not fetchable from the repository. Should I just install them manually? Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Archetype Component - Dependency Issue
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, > > 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 2.0, but as far > as I can tell by looking at Subversion, the version > is > still 1.0-SNAPSHOT. > > When I run eclipse:eclipse I don't get any > complaints, > just build successful. > > However the api is still not available. The eclipse > plugin usually complains if it can't download a > dependency. > > Is the maven-archetype-core project not available to > maven via repositories yet? > > Thanks, > - Ole > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r419367 - /maven/plugins/trunk/maven-jar-plugin/pom.xml
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 and doesn't overwrite your index.html :) Sorry about that, I'll fix it ASAP. I just copied it from maven-javadoc-plugin :) When I tried to bump the parent to SNAPSHOT-2, I ran into strange behavior. To be able to get this to work I put the ASF snapshot repo in a profile. But now I have to supply -P on every run. There must be a better way. Cheers, Brett On 6/07/2006 8:32 AM, [EMAIL PROTECTED] wrote: + + + +maven-javadoc-plugin + + +maven-jxr-plugin + + +maven-changelog-plugin + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common API for issue tracking systems
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: [EMAIL PROTECTED]; 'Maven Developers List' Subject: RE: Common API for issue tracking systems 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 to the Ant build script. Would that work? Note that 0.6.0 is not ready for being used in this way because it has the Tasks API in the mylar.tasklist, which is coupled into the UI. Bug for that is: 149981: extract tasks framework from mylar.tasklist https://bugs.eclipse.org/bugs/show_bug.cgi?id=149981 Mik > -Original Message- > From: Tomasz Pik [mailto:[EMAIL PROTECTED] > Sent: Friday, July 07, 2006 1:45 AM > To: Mik Kersten > Cc: [EMAIL PROTECTED]; Maven Developers List > Subject: Re: Common API for issue tracking systems > > 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 depends on mylar > libraries and maven will download them from ibblio mirrors. > But this comes down to disussion about maintaining libraries on > ibiblio, I don't know if mylar team is interested in providing jars > and poms in a needed form. > Please, let me know this, otherwise I'll try to prepare such set based > on mylar 0.6.0 distribution and open an issue for adding them to > ibiblio (perhaps asking Mylar team to review dependencies and other > things first). > > Regards, > Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-pmd-plugin 2.1
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 to latest and just ensuring 2.0.5-SNAPSHOT is installed to get the latest site), or roll back to 1 if there is a problem with the circular dependencies. Shouldn't we also lock the versions of the plugins used in the plugin parent? Both maven-jxr-plugin and maven-javadoc-plugin are unversioned in it. It took me a while, and some -X running, before I realized that Maven was using 2.0-beta-2 of the maven-javadoc-plugin although 2.0 is available in my local repo. -- Dennis Lundberg - Brett On 7/07/2006 5:30 AM, Mike Perham wrote: I think PMD is in good shape. We've upgraded to PMD 3.7, added a bunch of tests and upgraded the documentation. Can someone tell me how to run the docck checker so I can verify the docs before publishing the site? The RC snapshot binary is maven-pmd-plugin-2.1-20060706.192528-1.jar. Roadmap with closed issues: http://jira.codehaus.org/browse/MPMD?report=com.atlassian.jira.plugin.sy stem.project:roadmap-panel +1 from me. mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Manager Lists
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 setup for MRM so I can easily see the commits from there. It's here if anyone else is interested: http://fisheye.maven.org/browse/MRM 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 isn't much discussion now, I'd hope there will be after a release when people can tinker and there is some internal arch docs). It's not going to be a ghost town list in the near future and before any real discussion starts we should have the lists setup. Don't see any downside to setting up the lists. Even if lists like SCM are quiet it's still nice having them separated. - Brett On 7/07/2006 8:58 AM, Jason van Zyl wrote: Hi, How about we setup some lists for the repository manager? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-pmd-plugin 2.1
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, let me know if you want me to hold off on a release or I'll release it as is after the 72 hour vote window closes. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 1:32 AM To: Maven Developers List Subject: Re: [vote] release maven-pmd-plugin 2.1 +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 ensuring 2.0.5-SNAPSHOT is installed to get the latest site), or roll back to 1 if there is a problem with the circular dependencies. - Brett On 7/07/2006 5:30 AM, Mike Perham wrote: I think PMD is in good shape. We've upgraded to PMD 3.7, added a bunch of tests and upgraded the documentation. Can someone tell me how to run the docck checker so I can verify the docs before publishing the site? The RC snapshot binary is maven-pmd-plugin-2.1-20060706.192528-1.jar. Roadmap with closed issues: http://jira.codehaus.org/browse/MPMD?report=com.atlassian.jira.plugin.sy stem.project:roadmap-panel +1 from me. mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Guide for relocating artifacts from one groupId to another
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 then commit on stuff like this? Brett Porter wrote: +1 On 5/07/2006 10:37 AM, Dennis Lundberg wrote: Hi I'm in the process of relocating Jakarta commons components from groupID commons- to org.apache.commons. To be able to do this correctly I've had much help from Carlos. As this might be something that others will face, I thought it would be a good idea to create some documentation for it. Is this something that would be appropriate for maven-site? If so where should I put it? I was thinking maybe http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MJAR-28 Advice from dev: Mainfest.mf/Class-Path entries by MavenArchiver, Assembly and Jar
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]
MJAR-28 Advice from dev: Mainfest.mf/Class-Path entries by MavenArchiver, Assembly and Jar
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 versions, or the assembly should create -SNAPSHOT versions. Since SNAPSHOT would likely be only used for development either approach seems reasonably. My preference would be to use the timestamped version so you have explicit knowledge of what was in the build. Request for Advice: Could someone with knowledge of MavenArchiver, Assembly or Jar have a look at MJAR-28 and my notes (along with integration test cases provided as a patch) and provide feedback as to which approach is preferred. I am not sure how to sumbit changes to MavenArchiver as the only version I could find in SCM was under the 2.0.4 tagged release. Thanks Bae - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Archetype Component - Dependency Issue
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 2.0, but as far as I can tell by looking at Subversion, the version is still 1.0-SNAPSHOT. When I run eclipse:eclipse I don't get any complaints, just build successful. However the api is still not available. The eclipse plugin usually complains if it can't download a dependency. Is the maven-archetype-core project not available to maven via repositories yet? Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common API for issue tracking systems
-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 eclipse.org infrastructure? > I don't know if this thread is a good place to start such a discussion. There should be no problem. Just file a Mylar bug report with the structure you want and we can iterate from there. If the easiest way to do that is for us to build those JARs via Maven instead of plain Ant I'm happy to do that too. > I remember that somebody (Brett?) was talking with one of eclipse > projects (PDE?) about switching their builds to maven so maybe > in future this project will provide it's jars in maven way 'out of the > box'. That could be interesting, and the right place to prototype it seems like the Eclipse Maven Plug-in and then try to get it pulled up to PDE. But note that the PDE's build is tightly coupled to the plugin.xml/OSGi model that Eclipse uses, so that might need to be made reusable or re-implemented in Maven. Either way it's orthogonal to this effort, but it would be great to see more cooperation between Maven and Eclipse projects. > Pehaps we should move disussion about this to more appopriate place, > mylar newsgroup or 'dev' list? Yes, we have most of our interaction on bug reports so please file one, anyone interested can add themselves as a CC. Once you do that I'll ping mylar-dev in case others are interested in the discussion. Mik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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.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]> wrote: >> 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 situation as you have the >> > same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5 >> JDK >> > which I'm sure many people do. >> >> The -target and -source only checks the current sources, unfortunately. >> >> The compiler should ideally also check if the imported classes have the >> correct format (< 48 or something), and it should check the @since >> javadoc tags in the API to warn against usage of unavailable >> classes/methods in the target environment. >> >> Frankly, the -target and -source compiler options are quite useless. >> >> So yes, the only way to be sure is to fork the correct jdk. >> >> But I don't see a problem in having a jdk for maven itself and one >> for the >> target environment. They should be split up anyway. The only problem is >> that both the compilers and the plugins need to know this (surefire >> for instance, or possibly class-enhancing plugins etc.). >> >> Seems like a lot of work to get this perfect. >> >> Too bad, I really want to switch to Java 5 for Maven (especially for the >> generics and annotations!) >> >> And yes, java 5 plugins work like a charm. Haven't tried enumerations >> yet, >> though. >> >> -- Kenney >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common API for issue tracking systems
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. the poms) would be best as a contribution you make to the Ant build script. Would that work? 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 eclipse.org infrastructure? I don't know if this thread is a good place to start such a discussion. I remember that somebody (Brett?) was talking with one of eclipse projects (PDE?) about switching their builds to maven so maybe in future this project will provide it's jars in maven way 'out of the box'. Note that 0.6.0 is not ready for being used in this way because it has the Tasks API in the mylar.tasklist, which is coupled into the UI. Bug for that is: 149981: extract tasks framework from mylar.tasklist https://bugs.eclipse.org/bugs/show_bug.cgi?id=149981 Pehaps we should move disussion about this to more appopriate place, mylar newsgroup or 'dev' list? Regards, Tomek Mik > -Original Message- > From: Tomasz Pik [mailto:[EMAIL PROTECTED] > Sent: Friday, July 07, 2006 1:45 AM > To: Mik Kersten > Cc: [EMAIL PROTECTED]; Maven Developers List > Subject: Re: Common API for issue tracking systems > > 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 depends on mylar libraries > and maven will download them from ibblio mirrors. > But this comes down to disussion about maintaining libraries on > ibiblio, I don't know if mylar team is interested in providing jars > and poms in a needed form. > Please, let me know this, otherwise I'll try to prepare such set > based on mylar 0.6.0 distribution and open an issue for adding them > to ibiblio (perhaps asking Mylar team to review dependencies and other > things first). > > Regards, > Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r419367 - /maven/plugins/trunk/maven-jar-plugin/pom.xml
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 that, I'll fix it ASAP. I just copied it from maven-javadoc-plugin :) When I tried to bump the parent to SNAPSHOT-2, I ran into strange behavior. To be able to get this to work I put the ASF snapshot repo in a profile. But now I have to supply -P on every run. There must be a better way. Cheers, Brett On 6/07/2006 8:32 AM, [EMAIL PROTECTED] wrote: + + + +maven-javadoc-plugin + + +maven-jxr-plugin + + +maven-changelog-plugin + + + -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's the status of the maven-jar-plugin [m2]
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/MAVEN/Maven+Plugin+Documentation I spoke to John T today and he put this together so we can see how we are going towards getting all the plugins done. - Brett On 5/07/2006 10:28 AM, Dennis Lundberg wrote: Hi I thought that I'd have a go at restructuring/expanding the docs for the maven-jar-plugin, according to the new guidelines for plugins. Before I dive in, I thought it would be best to ask if somebody else is working on this. This would include fixing MJAR-46 and MJAR-47 in some way. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common API for issue tracking systems
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 to the Ant build script. Would that work? Note that 0.6.0 is not ready for being used in this way because it has the Tasks API in the mylar.tasklist, which is coupled into the UI. Bug for that is: 149981: extract tasks framework from mylar.tasklist https://bugs.eclipse.org/bugs/show_bug.cgi?id=149981 Mik > -Original Message- > From: Tomasz Pik [mailto:[EMAIL PROTECTED] > Sent: Friday, July 07, 2006 1:45 AM > To: Mik Kersten > Cc: [EMAIL PROTECTED]; Maven Developers List > Subject: Re: Common API for issue tracking systems > > 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 depends on mylar libraries > and maven will download them from ibblio mirrors. > But this comes down to disussion about maintaining libraries on > ibiblio, I don't know if mylar team is interested in providing jars > and poms in a needed form. > Please, let me know this, otherwise I'll try to prepare such set > based on mylar 0.6.0 distribution and open an issue for adding them > to ibiblio (perhaps asking Mylar team to review dependencies and other > things first). > > Regards, > Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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.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]> wrote: 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 situation as you have the > same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5 JDK > which I'm sure many people do. The -target and -source only checks the current sources, unfortunately. The compiler should ideally also check if the imported classes have the correct format (< 48 or something), and it should check the @since javadoc tags in the API to warn against usage of unavailable classes/methods in the target environment. Frankly, the -target and -source compiler options are quite useless. So yes, the only way to be sure is to fork the correct jdk. But I don't see a problem in having a jdk for maven itself and one for the target environment. They should be split up anyway. The only problem is that both the compilers and the plugins need to know this (surefire for instance, or possibly class-enhancing plugins etc.). Seems like a lot of work to get this perfect. Too bad, I really want to switch to Java 5 for Maven (especially for the generics and annotations!) And yes, java 5 plugins work like a charm. Haven't tried enumerations yet, though. -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] release maven-pmd-plugin 2.1
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 release it as is after the 72 hour vote window closes. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 1:32 AM To: Maven Developers List Subject: Re: [vote] release maven-pmd-plugin 2.1 +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 ensuring 2.0.5-SNAPSHOT is installed to get the latest site), or roll back to 1 if there is a problem with the circular dependencies. - Brett On 7/07/2006 5:30 AM, Mike Perham wrote: > I think PMD is in good shape. We've upgraded to PMD 3.7, added a bunch > of tests and upgraded the documentation. Can someone tell me how to run > the docck checker so I can verify the docs before publishing the site? > > The RC snapshot binary is maven-pmd-plugin-2.1-20060706.192528-1.jar. > > Roadmap with closed issues: > http://jira.codehaus.org/browse/MPMD?report=com.atlassian.jira.plugin.sy > stem.project:roadmap-panel > > +1 from me. > > mike > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: running docck
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: running docck deploy won't work, for sure. Install in your local repos. should work. It dit for me. Sure you don't typo your command line ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running docck
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] Error installing artifact's metadata: Error while deploying metadata: SCP terminated with error: 'scp: /www/cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/m aven-docck-plugin/1.0-SNAPSHOT/maven-metadata.xml: Permission denied' I'm having no luck today I guess. deploy won't work, for sure. Install in your local repos. should work. It dit for me. Sure you don't typo your command line ? jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: running docck
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 deploying metadata: SCP terminated with error: 'scp: /www/cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/m aven-docck-plugin/1.0-SNAPSHOT/maven-metadata.xml: Permission denied' I'm having no luck today I guess. -Original Message- From: jerome lacoste [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 9:37 AM To: Maven Developers List Subject: Re: running docck 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 http://jira.codehaus.org/browse/MNG-2421 Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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]> wrote: > 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 situation as you have the > > same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5JDK > > which I'm sure many people do. > > The -target and -source only checks the current sources, unfortunately. > > The compiler should ideally also check if the imported classes have the > correct format (< 48 or something), and it should check the @since > javadoc tags in the API to warn against usage of unavailable > classes/methods in the target environment. > > Frankly, the -target and -source compiler options are quite useless. > > So yes, the only way to be sure is to fork the correct jdk. > > But I don't see a problem in having a jdk for maven itself and one for the > target environment. They should be split up anyway. The only problem is > that both the compilers and the plugins need to know this (surefire > for instance, or possibly class-enhancing plugins etc.). > > Seems like a lot of work to get this perfect. > > Too bad, I really want to switch to Java 5 for Maven (especially for the > generics and annotations!) > > And yes, java 5 plugins work like a charm. Haven't tried enumerations yet, > though. > > -- Kenney > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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]> wrote: 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 situation as you have the > same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5 JDK > which I'm sure many people do. The -target and -source only checks the current sources, unfortunately. The compiler should ideally also check if the imported classes have the correct format (< 48 or something), and it should check the @since javadoc tags in the API to warn against usage of unavailable classes/methods in the target environment. Frankly, the -target and -source compiler options are quite useless. So yes, the only way to be sure is to fork the correct jdk. But I don't see a problem in having a jdk for maven itself and one for the target environment. They should be split up anyway. The only problem is that both the compilers and the plugins need to know this (surefire for instance, or possibly class-enhancing plugins etc.). Seems like a lot of work to get this perfect. Too bad, I really want to switch to Java 5 for Maven (especially for the generics and annotations!) And yes, java 5 plugins work like a charm. Haven't tried enumerations yet, though. -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 situation as you have the > same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5 JDK > which I'm sure many people do. The -target and -source only checks the current sources, unfortunately. The compiler should ideally also check if the imported classes have the correct format (< 48 or something), and it should check the @since javadoc tags in the API to warn against usage of unavailable classes/methods in the target environment. Frankly, the -target and -source compiler options are quite useless. So yes, the only way to be sure is to fork the correct jdk. But I don't see a problem in having a jdk for maven itself and one for the target environment. They should be split up anyway. The only problem is that both the compilers and the plugins need to know this (surefire for instance, or possibly class-enhancing plugins etc.). Seems like a lot of work to get this perfect. Too bad, I really want to switch to Java 5 for Maven (especially for the generics and annotations!) And yes, java 5 plugins work like a charm. Haven't tried enumerations yet, though. -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running docck
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 http://jira.codehaus.org/browse/MNG-2421 Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
running docck
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 PROTECTED]
Re: [discuss] Java 5
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, and a Java 5 requirement outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? if you build on java5, you cannot be 100% sure that you will run on java1.4, as various classes added new overloaded methods. Your java5-compiled code will be bound to the new methods, not the older stuff. So either you embrace j5 fully, or you split stuff up and build downlevel-targeted stuff on older JDKs. at work I run some projects java1.5 only, with the core still 1.4. its painful having a split, as you cannot move 1.5 stuff into the core (even implement Closeable, Appendable or Iterable), and the generics is a major language change. Personally, I like the new stuff, the concurrency things, QName and other bits, varargs and don't regret the switch. Its just a big transition. If maven goes java5 only, unless it can build against different JDKs, you are forcing all users to embrace java1.5 too, which implicitly stops their code working on java1.4, 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 situation as you have the same issue today if you build against 1.2 or 1.3. Or 1.4 with a 1.5 JDK which I'm sure many people do. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 wrote: -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 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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 Maven 2.1, provided that it is sure that using any JDK is perfectly implemented and usable (Sun is gonna release more often, so this functionality is essential) Fabrice. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: [discuss] 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 Maven 2.1, provided that it is sure that using any JDK is perfectly implemented and usable (Sun is gonna release more often, so this functionality is essential) Fabrice.
Re: [discuss] Java 5
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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? if you build on java5, you cannot be 100% sure that you will run on java1.4, as various classes added new overloaded methods. Your java5-compiled code will be bound to the new methods, not the older stuff. So either you embrace j5 fully, or you split stuff up and build downlevel-targeted stuff on older JDKs. at work I run some projects java1.5 only, with the core still 1.4. its painful having a split, as you cannot move 1.5 stuff into the core (even implement Closeable, Appendable or Iterable), and the generics is a major language change. Personally, I like the new stuff, the concurrency things, QName and other bits, varargs and don't regret the switch. Its just a big transition. If maven goes java5 only, unless it can build against different JDKs, you are forcing all users to embrace java1.5 too, which implicitly stops their code working on java1.4, -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
(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 plugins... but as I understand that the minimum JDK for plugins is the same as the minimum JDK for maven itself. That's probably a good thing, so: +1 for maven, in a few months. For NetBeans: would it be possible to say "Netbeans works on 1.4 but the netbeans maven plugin only works if you are using JDK 1.5"? To compare: "Acegi works on 1.4 but the acegi-tiger module only works if you are using JDK 1.5". 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reference to plugin's pom.xml during build.
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-scripts and jars that have to be put in correct place before I start build. What I expect to have is dependency definition in my plugin's pom. M2 will care to satisfy this dependency and I want to read this dependency information during the build. After then I can expand this dependency and put it's contents in correct place. "assembly:unpack" is something that I want to do. But dependencies have to be read from plugin's pom. Regards, Marcin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 flag on the mojo would do it, but I would like to have an upgraded qdox to make it more seamless. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deploy:deploy-file
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 -DgeneratePom=true deploy:deploy-file This the result: ... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp ... How to register wagon for ftp transport when using command line deployment as shown above? Thanks, Marcin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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 works for some stuff. It does not support enumerations which I tried to add to the grammar file with some success. Does anyone know if there is anyone maintaining the qdox project that we can contact? -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 works for some stuff. It does not support enumerations which I tried to add to the grammar file with some success. Does anyone know if there is anyone maintaining the qdox project that we can contact? -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 to take, unless you are right and the issue simply isn't closed. Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiler plugin "how to use"
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:
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 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 "official" way to compile a Java1.3 application.
I think this solution isn't the best/easier as this requires the
target environment to have the expected JDK installed and the
correct properties set, with no standard naming for it.
I myself get troubles with it as I can run JDK1.3 on my nightly
build server (Linux Ubuntu : requires some "stdlibc++libc6")
I'm using an alternative solution that has less expectation on the
compilation environment :
- Add a dependency to target runtime in the compiler plugin
configuration
- Set the compiler bootclasspaht to use it
org.apache.maven.plugins
maven-compiler-plugin
1.3
1.3
${settings.localRepository}/com/sun/rt/1.3.1_08/rt-1.3.1_08.jar
com.sun
rt
1.3.1_08
This solution only requires the to install first the expected
rt.jar in repo, as any others java API jars (com.sun:rt POM is in
maven2 repo).
Don't you think this solution may be promoted on compiler plugin
documentation ?
Niso.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are
not the intended recipient, you are not authorized to read,
print, retain, copy, disseminate, distribute, or use this message
or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
Index: compile_using_different_jdk.apt
===
--- compile_using_different_jdk.apt (revision 419851)
+++ compile_using_different_jdk.apt (working copy)
@@ -33,4 +33,32 @@
[...]
-+---
\ No newline at end of file
++---
+
+
+ An alternative is to install the rt.jar from your target JRE in your local
repo using
+ standardized maven groupId "com.sun", and configure the compiler plugin to
use it
+ as bootclasspath for javac using <<>> :
+
++---
+
+ org.apache.maven.plugins
+ maven-compiler-pl
Re: compiler plugin "how to use"
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 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:
I've read on
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html
the "official" way to compile a Java1.3 application.
I think this solution isn't the best/easier as this requires the
target environment to have the expected JDK installed and the
correct properties set, with no standard naming for it.
I myself get troubles with it as I can run JDK1.3 on my nightly
build server (Linux Ubuntu : requires some "stdlibc++libc6")
I'm using an alternative solution that has less expectation on the
compilation environment :
- Add a dependency to target runtime in the compiler plugin
configuration
- Set the compiler bootclasspaht to use it
org.apache.maven.plugins
maven-compiler-plugin
1.3
1.3
${settings.localRepository}/com/sun/rt/1.3.1_08/rt-1.3.1_08.jar
com.sun
rt
1.3.1_08
This solution only requires the to install first the expected rt.jar
in repo, as any others java API jars (com.sun:rt POM is in maven2
repo).
Don't you think this solution may be promoted on compiler plugin
documentation ?
Niso.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential
and is the property of the Capgemini Group. It is intended only for the
person to whom it is addressed. If you are not the intended recipient,
you are not authorized to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive
this message in error, please notify the sender immediately and delete
all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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 annotation parser barked over Java 5 constructs. (Sorry, no bug number or something like that available.) Jochen -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 annotation parser barked over Java 5 constructs. (Sorry, no bug number or something like that available.) Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiler plugin "how to use"
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 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 "official" way to compile a Java1.3 application.
I think this solution isn't the best/easier as this requires the
target environment to have the expected JDK installed and the
correct properties set, with no standard naming for it.
I myself get troubles with it as I can run JDK1.3 on my nightly
build server (Linux Ubuntu : requires some "stdlibc++libc6")
I'm using an alternative solution that has less expectation on the
compilation environment :
- Add a dependency to target runtime in the compiler plugin
configuration
- Set the compiler bootclasspaht to use it
org.apache.maven.plugins
maven-compiler-plugin
1.3
1.3
${settings.localRepository}/com/sun/rt/1.3.1_08/rt-1.3.1_08.jar
com.sun
rt
1.3.1_08
This solution only requires the to install first the expected rt.jar
in repo, as any others java API jars (com.sun:rt POM is in maven2
repo).
Don't you think this solution may be promoted on compiler plugin
documentation ?
Niso.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
+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. 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 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [discuss] Java 5
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 code... Well, when Sun released 1.5 they also proposed, that a new JDK version will now follow every year (and Sun will phase out the support for the old ones therefore much earlier). If they really mange to do so, you will get really out of sync. Meanwhile even some of our customers of the financial business realized this and they already start to upgrade (although they are traditionally *very* conservative). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
-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 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 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 outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiler plugin "how to use"
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:
I've read on
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html
the "official" way to compile a Java1.3 application.
I think this solution isn't the best/easier as this requires the
target environment to have the expected JDK installed and the correct
properties set, with no standard naming for it.
I myself get troubles with it as I can run JDK1.3 on my nightly build
server (Linux Ubuntu : requires some "stdlibc++libc6")
I'm using an alternative solution that has less expectation on the
compilation environment :
- Add a dependency to target runtime in the compiler plugin
configuration
- Set the compiler bootclasspaht to use it
org.apache.maven.plugins
maven-compiler-plugin
1.3
1.3
${settings.localRepository}/com/sun/rt/1.3.1_08/rt-1.3.1_08.jar
com.sun
rt
1.3.1_08
This solution only requires the to install first the expected rt.jar
in repo, as any others java API jars (com.sun:rt POM is in maven2 repo).
Don't you think this solution may be promoted on compiler plugin
documentation ?
Niso.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Manager Lists
+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 was the initial ghost town of empty lists when we're trying to kick it along (even if there isn't much discussion now, I'd hope there will be after a release when people can tinker and there is some internal arch docs). - Brett On 7/07/2006 8:58 AM, Jason van Zyl wrote: Hi, How about we setup some lists for the repository manager? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common API for issue tracking systems
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 depends on mylar libraries and maven will download them from ibblio mirrors. But this comes down to disussion about maintaining libraries on ibiblio, I don't know if mylar team is interested in providing jars and poms in a needed form. Please, let me know this, otherwise I'll try to prepare such set based on mylar 0.6.0 distribution and open an issue for adding them to ibiblio (perhaps asking Mylar team to review dependencies and other things first). Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cyclic dependency in maven-plugins ??
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 is the reason. Furthermore, the problem should be non-existant as the reports are supposed to be used after the artifacts have been built, so this dependency check seems bogus to me. But I guess I am the only one using maven 2.0.4 to build the current plugin trunk, right ? Commenting out the whole reporting section under the root pom doesn't even solve it for me as some plugins depend on version 1 of the root pom and thus the change doesn't propagate to all sub-modules... I think we should omit the changelog plugin from the proposed doc standard and the pom for now. Yep. The docck plugin is also referenced in the CI profile... Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
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 reproducable builds they could use the 3.7-1 syntax. The release plugin could fully-qualify any version numbers of the form 3.7 to the currently-used revision, e.g. 3.7-1, at release time. This is actually how I'd originally designed it to work (using newest instead of nearest, with ranges much more common). Will have to come back to that in 2.1 :) Anyway, I think it's currently debatable whether a -1 release is enough for this case. I'd really like to investigate a "vendor" element of the version that allows people that aren't the original project to modify/repackage their releases without screwing up the dependency model. - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
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 managed by the projects themselves, of course. - Brett On 6/07/2006 2:32 AM, Alexandre Poitras wrote: +1, really great idea. On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote: On 05/07/06, Arik Kfir <[EMAIL PROTECTED]> wrote: > Hello all, > > A while back I suggested that the Maven team delegate some of the > reponsibility of maintaining the ibiblio repo to volunteers (as in the linux > equivalent, as Jerome has noted earlier in the thread). Each such voluteer > can maintain a specific area in the repo; so, someone who uses hibernate > frequently can maintain its poms, until the hibernate team agrees to do it > for us. > > The idea was generally accepted by brett, with a slight modification that > volunteers go through a screening process, just like normal commit access is > provisioned (someone who submits enough pom patches will slowly be given > commit access to ibiblio). > > for more info, see > http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495 > > perhaps it is time to move this forward? Definitely +1 to seeing the ibiblio repostory devolving responsibility to smaller, more managable, repositories - ideally maintained by developers closer to the hosted projects. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
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 from the dependees end: [2.0],[2.0.2,) or [2.0],[2.0.2],[2.1,) depending on if 2.0.3 <= x < 2.1 are any good. From a releasers end, I'm inclined to say they should pull the release, but since some people may have already gotten it metadata that says "this release is totally broken" that warns new users might be better. - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
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 maven embedder.) Anyone has experience with such a setup? Right... it would only matter if the embedder forced you to use 1.5 features yourself which I don't see happening for a while (changing the requirement still takes a while for it to filter through the API). Another alternative might be some sort of little bootstrapper/verifier thing that could check the java.version system property before attempting to run the other. Anyway, no need to rush into this - something to keep in the back of our minds if we decide it's worthwhile doing and then can go and investigate all the consequences :) Thanks, Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
