Re: need help
Well.. I must say I am not sure I understood the questions fully, but I give it a try... Hi, Its regarding identifiyng the plugin name. We are using Maven in my project. i have small doubt. I need to identify the "aspectj-maven-plugin" if we are using in our project. if it is found then we need to project nature according to that. This does the trick (at least on a descent system) find . -name "pom.xml" | xargs "grep aspectj-maven-plugin" All the poms containing the plugin should then be found. then add the xml below to your build section of the poms found, and all your aspectJ projects now should have aspectJ nature in eclipse. org.apache.maven.plugins maven-eclipse-plugin org.eclipse.ajdt.ui.ajnature org.eclipse.ajdt.core.ajbuilder Can you please let me know where i can find that information in the source code. or how to do it? This is very urgent. Thanks in advance. Regards, pulla reddy.R - Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Continuum 1.0.3
On 19/04/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Tue, 2006-04-18 at 20:31 +0200, Kaare Nilsen wrote: > > The speed improvements are impressive.. thanx for that !! > > I still would like to have my instance running for a couple of days to > > test the memoryleak in more detail, and also i have found a bug that > > when importing a multiproject one or more of the modules are added > > twice (dupplicates), and then it is not possible to delete one of them > > (I am going to file a jira issue tomorrow when i have the stacktrace > > available). > > I'm voting -0 on this release as there seems to be new issue that has > come up lately which I at least would like Emmanuel to take a look at > before continuing with the release. > > The issue is the one reported by Kaare Nilsen and Jorg (and possibly > related to 641[1]). That would be http://jira.codehaus.org/browse/CONTINUUM-660 > > [1] http://jira.codehaus.org/browse/CONTINUUM-641 > > -- > Trygve > >
Re: [vote] Release Continuum 1.0.3
Well.. based on the rc snapshot I also have alot problems with out of memory stuff. I run solaris10 jdk 1.5.0_04 eagerly awaiting the next rc On 10/04/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > Windows XP > JDK 1.4.2 > > If it runs (the projects list shouldn't be empty), you can take a look at it > here : > http://heritier.homeip.net/continuum/ > > Arnaud > > On 4/10/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > > > What is your OS? > > > > Emmanuel > > > > Arnaud HERITIER a écrit : > > > I also have a lot of OutOfMemory errors > > > http://jira.codehaus.org/browse/CONTINUUM-653 > > > I have to reboot my continuum server sevaral times per day :-( > > > > > > Arnaud > > > > > > On 4/10/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > > > > >> > > >> > > >>Arnaud HERITIER a écrit : > > >> > > >>>I just tested it. > > >>> > > >>>+0 actually > > >>> > > >>>What I noticed : > > >>> > > >>>1) Is it normal that I can't edit/remove the default notification for > > m1 > > >>>projects ? > > >>>It's really annoying. I don't want to spam > > >>>[EMAIL PROTECTED] the build is successfull (just the > > >>>first time after a failure). > > >> > > >>You can't because it's a project notifier and not a notifier defined by > > >>the user. If you don't want > > >>to spam the list, you can turn off your smtp server or configure a bad > > >>address in application.xml. > > >> > > >>I think i'll add, in 1.1, an authorized sender in project notifier. > > >> > > >> > > >>>2) It seems also that I have a problem with the build number when the > > >> > > >>build > > >> > > >>>fails : > > >>> > > >> > > >> > > http://heritier.homeip.net/continuum/servlet/continuum/target/ProjectBuilds.vm/view/ProjectBuilds/id/1 > > >> > > >>The build number is incremented only when the build is in success, so > > you > > >>don't have a problem there. > > >> > > >>Emmanuel > > >> > > >> > > >>>cheers > > >>> > > >>>Arnaud > > >>> > > >>>On 3/17/06, Punkin Head <[EMAIL PROTECTED]> wrote: > > >>> > > >>> > > +1 > > > > On 3/16/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > >I've been testing and its looking great, but can we hold off voting > > >until the final RC is ready? I'd like to follow the lead taken with > > the > > >Maven core which has resulted in us delaying the release due to bugs > > >that otherwise would have got by unnoticed. > > > > > >- Brett > > > > > >Emmanuel Venisse wrote: > > > > > > > > >>Hi, > > >> > > >>I think it's time to release Continuum 1.0.3. This release will > > >>incorporate 65 issues, including some critical fixes. The full > > listing > > >>of fixes can be found here: > > >> > > >> > > > > > >> > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=12330 > > >> > > >>If you're interested, you can take the current release candidate for > > a > > >>test drive. The RC tarball is at: > > >> > > >> > > > > > >> > > http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060316.173001.tar.gz > > >> > > >>I'll leave the vote open for the customary 72 hours before > > > > summarizing. > > > > > > >>Please cast your vote as: > > >> > > >>[ ] +1 Yes, release > > >>[ ] 0 No opinion > > >>[ ] -1 No, don't release > > >> > > >>Here's my +1. > > >> > > >>Cheers, > > >> > > >>Emmanuel > > >> > > > > > > > -- > > www.punkinshred.net // punkin'head official homepage > > > > www.myspace.com/punkinhead <-- for true shred > > > > > > >>> > > >>> > > >> > > > > > > > > >
Re: [vote result] release maven 2 eclipse plugin 2.2
A litte to late but anyhow +1 from me /Kaare On 10/04/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: > Vote result: > 3 binding +1 (me, Emmanuel, John) > I will take care of publishing the release shortly > > fabrizio > > > On 4/6/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: > > Based on: > > maven-eclipse-plugin-2.2-20060406.203721-2.jar > > I would like to release version 2.2 of the maven 2 eclipse plugin. > > This release introduces several changes in the artifact resolution > > code (it doesn't require anymore to have installed artifacts for > > referenced reactor projects) and reverts the change discussed in > > MECLIPSE-37 (that forced to have compiling projects). > > > > There are still open issues (mainly enhancements) but these changes > > are important and surely worth a release. > > The full list of fixed bugs and improvements can be found at > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11133&styleName=Html&version=12364 > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > vote is open for the usual 72 hours, my +1 > > fabrizio > > > > - > 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 2 eclipse plugin 2.2
Hi.. stupid question, but... Where is the snapshot repos, so that I can test it ? /Kaare On 07/04/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > +1 > > Emmanuel > > Fabrizio Giustina a écrit : > > Based on: > > maven-eclipse-plugin-2.2-20060406.203721-2.jar > > I would like to release version 2.2 of the maven 2 eclipse plugin. > > This release introduces several changes in the artifact resolution > > code (it doesn't require anymore to have installed artifacts for > > referenced reactor projects) and reverts the change discussed in > > MECLIPSE-37 (that forced to have compiling projects). > > > > There are still open issues (mainly enhancements) but these changes > > are important and surely worth a release. > > The full list of fixed bugs and improvements can be found at > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11133&styleName=Html&version=12364 > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > vote is open for the usual 72 hours, my +1 > > fabrizio > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven application launcher?
It's not maven, but you could use classworlds to launch your app. used by continuum at least, and I use it for running my binary distributions. So in the development environment we use exec:java to launch a module, and in the test and production we use classworlds.. works like a charm classworlds :http://classworlds.codehaus.org/ /Kaare On 07/04/06, Brian E. Fox <[EMAIL PROTECTED]> wrote: > Cause ant is icky... ;-) > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 06, 2006 8:11 PM > To: Maven Developers List > Subject: Re: Maven application launcher? > > why not use ant:run with java task? > > -D > > > On 4/6/06, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > > > There is something but it's hosted outside of the maven or mojo domain > > > and I can't remember what it's called. Try searching the archives of > > the user group, I know it was posted there. > > > > -Original Message- > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jochen Kuhnle > > Sent: Thursday, April 06, 2006 12:55 PM > > To: dev@maven.apache.org > > Subject: Maven application launcher? > > > > Hi, > > > > is there a component that can be used to launch application JARs > > generated with maven, i.e. that allows me to run "java -jar > > myapp.jar", which automatically downloads all dependencies, adds them > > to the classpath and runs the application? > > > > Regards, > > Jochen > > > > > > - > > 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] > > > > > > > > - > 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: JUnit 4.0
Hi all..
Though i did not test this using surefire (yet), I am almost certain
that it would work..
the followng testcode, and notice the inner suite() method.
package no.objectware.test.junit4;
import junit.framework.JUnit4TestAdapter;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
public class Junit4Test {
@BeforeClass
public static void doSomeInitialSetup() {
System.out.println("Before a clazz");
}
@Before
public void beforeATest(){
System.out.println("\tBefore a testMethod");
}
@Test
public void doATest(){
System.out.println("\t\tYohoo");
}
@Test
public void anoterTest(){
System.out.println("\t\tAnother test");
}
@After
public void afterATest(){
System.out.println("\tAfter a testMethod");
}
@AfterClass
public static void doSomeCleanup() {
System.out.println("After a clazz");
}
/**
* Wrap the new junit4 testcase in a 3.x style suite
* to be recognized by eclipse runner and maven surefire.
* @return
*/
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(Junit4Test.class);
}
}
Of course you would need java 5, but hey.. who doesn't ;)
/Kaare
On 19/02/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Feb 2006, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
>
> > Yes but It seems that JUnit 4 works only with Java 5 ??
>
> It requires Java 5 to compile and annotations for JUnit 4 style
> tests. JUnit 3 style tests are still supported (so you can run your
> old tests against JUnit 4) and don't require Java 5 at runtime. There
> also is a compatibility layer that allows JUnit 4 style tests to run
> against JUnit 3 test runners (like Ant's) which would again require
> Java 5 at runtime.
>
> I did some tests with Ant's JUnit task when JUnit 4 stabilized in
> CVS. I guess much of it applies to Maven as well.
>
> http://stefan.samaflost.de/blog/en/Apache/Ant/junit4_and_ant.writeback
> http://stefan.samaflost.de/blog/en/Apache/Ant/junit4_and_ant_no_problem.html
>
> Stefan
>
> -
> 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]
[jira] Commented: (CONTINUUM-501) It should be possible to add a project with sub modules without adding all the sub modules
[ http://jira.codehaus.org/browse/CONTINUUM-501?page=comments#action_53126 ] Kaare Nilsen commented on CONTINUUM-501: Well. In my eyes that is a workaround for a missing feature more than a long term solution. > It should be possible to add a project with sub modules without adding all > the sub modules > -- > > Key: CONTINUUM-501 > URL: http://jira.codehaus.org/browse/CONTINUUM-501 > Project: Continuum > Type: Improvement > Reporter: Kaare Nilsen > > > When adding a url to a maven2 pom there sould be a checkbox to indicate if > you would like to import projects recursivly or just the one pom. > e.g. "add sub modules" true/false > In some cases i would see the benifit of adding the top pom, and removing the > --non-recursive flag for doing a full build. > this is somewhat difficult today, when if e.g you have 20 modules you would > add the top pom,. and then you would have to delete all the children manually. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-501) It should be possible to add a project with sub modules without adding all the sub modules
It should be possible to add a project with sub modules without adding all the sub modules -- Key: CONTINUUM-501 URL: http://jira.codehaus.org/browse/CONTINUUM-501 Project: Continuum Type: Improvement Reporter: Kaare Nilsen When adding a url to a maven2 pom there sould be a checkbox to indicate if you would like to import projects recursivly or just the one pom. e.g. "add sub modules" true/false In some cases i would see the benifit of adding the top pom, and removing the --non-recursive flag for doing a full build. this is somewhat difficult today, when if e.g you have 20 modules you would add the top pom,. and then you would have to delete all the children manually. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1482) aspectj plugin
[ http://jira.codehaus.org/browse/MNG-1482?page=comments#action_53050 ] Kaare Nilsen commented on MNG-1482: --- Implementation currently in the MOJO sandbox. to file issues please use the aspectj component in http://jira.codehaus.org/browse/MOJO > aspectj plugin > -- > > Key: MNG-1482 > URL: http://jira.codehaus.org/browse/MNG-1482 > Project: Maven 2 > Type: New Feature > Components: Plugin Requests > Reporter: Jason van Zyl > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1482) aspectj plugin
[ http://jira.codehaus.org/browse/MNG-1482?page=comments#action_51140 ] Kaare Nilsen commented on MNG-1482: --- i have added a plugin implementation in the mojo jira here : http://jira.codehaus.org/browse/MOJO-118 > aspectj plugin > -- > > Key: MNG-1482 > URL: http://jira.codehaus.org/browse/MNG-1482 > Project: Maven 2 > Type: New Feature > Components: plugin-ideas > Reporter: Jason van Zyl > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
Ok.. after some thought I need to reevaluate my opinion on this. I have now played a little with the eclipse plugin, and well.. i must admit that i like the way it behaves. So using project references for projects in the same reactor build where the version of the project in the reactor, and the version of the dependency seems like a good default behaviour to me. On 14/11/05, Kaare Nilsen <[EMAIL PROTECTED]> wrote: > My mistake > You are right Mark. So it seems like the eclipse plugin does it alot > like what Brett are describing.. But again.. this is to automagically > for me ;) > > > > On 14/11/05, Mark Hobson <[EMAIL PROTECTED]> wrote: > > The eclipse plugin *does* create different project files depending on > > where it's run. It uses project references if the other projects are > > within the reactor build. It's also very particular regarding > > versions, as this thread details: > > > > http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272 > > > > I agree we need to be consistent across IDEs and would like things to > > be simplified and configurable. > > > > Cheers, > > > > Mark > > > > On 14/11/05, Kaare Nilsen <[EMAIL PROTECTED]> wrote: > > > Well, no.. > > > I think that what you are describing is somewhat to magical for me ;) > > > You say that the idea plugin creates different projects depending on > > > where you run the command, i personally finds that very confusing. In > > > my opinion a plugin after configured in the module pom (or a parent) > > > should behave consistently, and create equivalent projects on every > > > run, not depending on where the command is executed. > > > > > > The eclipse plugin creates project references if they share the same > > > parent pom (i have seen there are ppl out there struggeling with that, > > > but in my experience it works) no matter if you run the plugin from > > > the root or in a subdirectory. > > > Personally i find this to be a more consise solution. > > > > > > hehe, i litteraly can se my self trying to explain it to a coworker. > > > "Oh.. yeah.. by the way. please do remember to check where your run > > > your project generation. The result may vary", and then i can imagine > > > the look of confusion i would get back ;) > > > > > > So If an IDE project is generated for a module in a multimodule > > > project, it should always by default use project references. > > > > > > But then again. perhaps the notion of project generation strategy > > > would be a cool common setting. > > > like this (using one of the values inside[] ) > > > ... > > > > > > > > > [direct,directIfSameVersion,repsitory,snapshot-repository] > > > > > > ... > > > > > > > > > > > > On 14/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > Yes, I definitely agree with that. This discussion should be about the > > > > default, but be configurable. > > > > > > > > So, you say the eclipse plugin does well - is it the same or different > > > > to the idea plugin as I described it? > > > > > > > > - Brett > > > > > > > > Kaare Nilsen wrote: > > > > > Then supply good default behaviour (where i really do think the > > > > > current eclipseplugin does a good job). And finally let the users > > > > > choose how they want to use it. > > > > > > > > - > > > > 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] > > > > > > > > > > - > > 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: making behaviour of ide plugins consistent
My mistake You are right Mark. So it seems like the eclipse plugin does it alot like what Brett are describing.. But again.. this is to automagically for me ;) On 14/11/05, Mark Hobson <[EMAIL PROTECTED]> wrote: > The eclipse plugin *does* create different project files depending on > where it's run. It uses project references if the other projects are > within the reactor build. It's also very particular regarding > versions, as this thread details: > > http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272 > > I agree we need to be consistent across IDEs and would like things to > be simplified and configurable. > > Cheers, > > Mark > > On 14/11/05, Kaare Nilsen <[EMAIL PROTECTED]> wrote: > > Well, no.. > > I think that what you are describing is somewhat to magical for me ;) > > You say that the idea plugin creates different projects depending on > > where you run the command, i personally finds that very confusing. In > > my opinion a plugin after configured in the module pom (or a parent) > > should behave consistently, and create equivalent projects on every > > run, not depending on where the command is executed. > > > > The eclipse plugin creates project references if they share the same > > parent pom (i have seen there are ppl out there struggeling with that, > > but in my experience it works) no matter if you run the plugin from > > the root or in a subdirectory. > > Personally i find this to be a more consise solution. > > > > hehe, i litteraly can se my self trying to explain it to a coworker. > > "Oh.. yeah.. by the way. please do remember to check where your run > > your project generation. The result may vary", and then i can imagine > > the look of confusion i would get back ;) > > > > So If an IDE project is generated for a module in a multimodule > > project, it should always by default use project references. > > > > But then again. perhaps the notion of project generation strategy > > would be a cool common setting. > > like this (using one of the values inside[] ) > > ... > > > > > > [direct,directIfSameVersion,repsitory,snapshot-repository] > > > > ... > > > > > > > > On 14/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Yes, I definitely agree with that. This discussion should be about the > > > default, but be configurable. > > > > > > So, you say the eclipse plugin does well - is it the same or different > > > to the idea plugin as I described it? > > > > > > - Brett > > > > > > Kaare Nilsen wrote: > > > > Then supply good default behaviour (where i really do think the > > > > current eclipseplugin does a good job). And finally let the users > > > > choose how they want to use it. > > > > > > - > > > 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] > > > > > > - > 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: making behaviour of ide plugins consistent
Well, no.. I think that what you are describing is somewhat to magical for me ;) You say that the idea plugin creates different projects depending on where you run the command, i personally finds that very confusing. In my opinion a plugin after configured in the module pom (or a parent) should behave consistently, and create equivalent projects on every run, not depending on where the command is executed. The eclipse plugin creates project references if they share the same parent pom (i have seen there are ppl out there struggeling with that, but in my experience it works) no matter if you run the plugin from the root or in a subdirectory. Personally i find this to be a more consise solution. hehe, i litteraly can se my self trying to explain it to a coworker. "Oh.. yeah.. by the way. please do remember to check where your run your project generation. The result may vary", and then i can imagine the look of confusion i would get back ;) So If an IDE project is generated for a module in a multimodule project, it should always by default use project references. But then again. perhaps the notion of project generation strategy would be a cool common setting. like this (using one of the values inside[] ) ... [direct,directIfSameVersion,repsitory,snapshot-repository] ... On 14/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Yes, I definitely agree with that. This discussion should be about the > default, but be configurable. > > So, you say the eclipse plugin does well - is it the same or different > to the idea plugin as I described it? > > - Brett > > Kaare Nilsen wrote: > > Then supply good default behaviour (where i really do think the > > current eclipseplugin does a good job). And finally let the users > > choose how they want to use it. > > - > 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: making behaviour of ide plugins consistent
In my opinion, giving the choise to the individual developer would be the best solution. When plugins tries to get "too smart" they often fail, and a lot of discussions appear. It should not be the responsibility of the plugin writer to tell people how they must manage their IDE's projects. Rather the plugin writers should provide good default behaviour and then allow the users of the plugin to change that behaviour if it does not suit their needs. Lets take a project i am in as an example: We have currently 22 modules/projects in our reactor, and our developers works on one or possible 2 or 3 concurrently. Due to how the eclipse plugin currently works each developer needs to have their workspace cluttered with 20 projects they are not working on, and really don't care about. As the one respopnsible of introducing maven to the team, I do come short of explaining to them why they have to have all the projects open. And if some of you out there could come up with the answer here, then honestly you are not really listening to what they are saying. And as i am sayning in the issue http://jira.codehaus.org/browse/MNG-955 Why do we really need to make this so difficult. So to make a long story short. My opinion is: Yes it would be a good idea to have the plugins behave consistenly, they perhaps could share a configuration object that holds the common settings. Then supply good default behaviour (where i really do think the current eclipseplugin does a good job). And finally let the users choose how they want to use it. On 14/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi, > > Can we discuss how to make the ide plugins behave consistently? It > appears that, in particular, there are a lot of discussions about > Eclipse and direct project references, and as I'm not a user I don't > really follow them - but I'm concerned that they might be arriving at a > different solution to what is already in place for the idea plugin. > > So, could folks provide feedback on this strategy, and if there are any > other places that might differ (eg source/javadoc binding), please > comment on that. > > For project references: the idea plugin uses a reference if and only if > the project exists in the reactor - ie, you run it from the root and it > creates all the files and the single project file. If run from a > subdirectory later, it will not create a link, but use the JAR from the > repository. > > I think I'd want to enhance that to use a reference if it is found in > the USD/workspace - but that's not there just yet as there isn't an API > for the USD, it's only used in finding parent POMs. > > Thoughts? > > - 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]
[jira] Commented: (MNG-955) There should be possible to use artifacts instead of project references in multi module projects
[ http://jira.codehaus.org/browse/MNG-955?page=comments#action_49891 ] Kaare Nilsen commented on MNG-955: -- hia. i really don't see why we have to make this so difficult. Let ut realize that there are people out there with different requirements. I think letting the user decide using a configurationoption like the one i have proposed in the issue is the best solution. then people who think it is critically important that one could navigate between projects directly do so, and the one of us who would like to do so most of the time, but also have the need of totally decoupling the project some times, do so also. At least for this plugin then the discussion about to use references or not, the answer then simply would be.. well anyway you like it my friend ;) > There should be possible to use artifacts instead of project references in > multi module projects > > > Key: MNG-955 > URL: http://jira.codehaus.org/browse/MNG-955 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Reporter: Kaare Nilsen > Assignee: Edwin Punzalan > Fix For: 2.0.1 > Attachments: MNG-955-maven-eclipse-plugin.patch > > > One of the fine things with maven is that one can have several modules in a > project. > But in the eclipse plugin all dependent modules in the project is added as a > project reference instead of using the delivered artifact. > As a result i have to have all my modules (eclipse projects) opened just to > compile in eclipse. > I think this should be an option. e.g. > true > with this set to true as default, but when false, the classpath should use a > reference to the jar in local repos as all other artifacts -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-705) Declared dependency is not included when there exist an exclusion of the artifact in another dependency
[ http://jira.codehaus.org/browse/MNG-705?page=comments#action_46926 ] Kaare Nilsen commented on MNG-705: -- ahh.. i see.. then it was all StupidUserException in my case ;) sorry for that > Declared dependency is not included when there exist an exclusion of the > artifact in another dependency > --- > > Key: MNG-705 > URL: http://jira.codehaus.org/browse/MNG-705 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: Maven version: 2.0-beta-1-SNAPSHOT, Revision: 227347 > Reporter: Kristian Nordal > Assignee: Brett Porter > Priority: Minor > Fix For: 2.0-beta-2 > > Original Estimate: 1 hour > Remaining: 1 hour > > I have declared a dependency (commons-collections), but I also have an > exclusion of commons-collections in another dependency. In this case > commons-collection is not added to the classpath. Part of my POM: > > ... > > ... > > > hibernate > hibernate > 3.0.5 > > ... > > commons-collections > commons-collections > > ... > > ... > > commons-collections > commons-collections > 3.1 > > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-956) There sould be possible to add additional classpath entry in plugin configuration
There sould be possible to add additional classpath entry in plugin configuration - Key: MNG-956 URL: http://jira.codehaus.org/browse/MNG-956 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Reporter: Kaare Nilsen In the case of using a code generation plugin like e.g. XmlBeans. There should be a way of adding the generated artifact as an additional classpath entry in the eclipse project. As it is today no projects using xmlbeans will be a valid eclipse project due to some files are just in the generated jar. Hopefully this will be fixed in the xmlbeans plugin, but it would anyhow be a nice feature to the eclipseplugins. example : ... target/schemas.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-955) There should be possible to use artifacts instead of project references in multi module projects
There should be possible to use artifacts instead of project references in multi module projects Key: MNG-955 URL: http://jira.codehaus.org/browse/MNG-955 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Reporter: Kaare Nilsen One of the fine things with maven is that one can have several modules in a project. But in the eclipse plugin all dependent modules in the project is added as a project reference instead of using the delivered artifact. As a result i have to have all my modules (eclipse projects) opened just to compile in eclipse. I think this should be an option. e.g. true with this set to true as default, but when false, the classpath should use a reference to the jar in local repos as all other artifacts -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-705) Declared dependency is not included when there exist an exclusion of the artifact in another dependency
[ http://jira.codehaus.org/browse/MNG-705?page=comments#action_46908 ] Kaare Nilsen commented on MNG-705: -- Well.. it is not always pointless. Because of this bug in combination with errors in activemq poms. i could not use dependencyManagement to remove all the errors in the activemq pom, and resolve it in my own. So when one comes across an invalid pom it could be very usefull to exclude it in the pom with error, and add the right one in your own pom > Declared dependency is not included when there exist an exclusion of the > artifact in another dependency > --- > > Key: MNG-705 > URL: http://jira.codehaus.org/browse/MNG-705 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: Maven version: 2.0-beta-1-SNAPSHOT, Revision: 227347 > Reporter: Kristian Nordal > Assignee: Brett Porter > Priority: Minor > Fix For: 2.0-beta-2 > > Original Estimate: 1 hour > Remaining: 1 hour > > I have declared a dependency (commons-collections), but I also have an > exclusion of commons-collections in another dependency. In this case > commons-collection is not added to the classpath. Part of my POM: > > ... > > ... > > > hibernate > hibernate > 3.0.5 > > ... > > commons-collections > commons-collections > > ... > > ... > > commons-collections > commons-collections > 3.1 > > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-81) Pom for jgraph 5.5.1 references an invalid jar
Pom for jgraph 5.5.1 references an invalid jar -- Key: MEV-81 URL: http://jira.codehaus.org/browse/MEV-81 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Kaare Nilsen The jgraph jar with version 5.5.1 has it's java classes in a internal jar instead of having them directly at the root of the jar. this makes building somewhat difficult ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
