[jira] Created: (MNG-1958) we need a var that always points to the root direcotry in multi module builds
we need a var that always points to the root direcotry in multi module builds
-
Key: MNG-1958
URL: http://jira.codehaus.org/browse/MNG-1958
Project: Maven 2
Type: Improvement
Reporter: Mark Proctor
Fix For: 2.1
${basedir} always points to the local module. There are cases, when having a
local relative repository, when it would be usefull to have a var that always
pointed to the root project, ${rootdir}.
In such a case you may want to think of having the names ${rootdir} ${moduledir}
--
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-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=comments#action_52114 ] Mark Proctor commented on MNG-1694: --- skipping is fine by me, as long as its fast. Thats what I did for M1, I implemented my own build goal that iterates the reactor and calls jar:jar if a jar doesn't exist. > Build execution order control in fine grained projects. > --- > > Key: MNG-1694 > URL: http://jira.codehaus.org/browse/MNG-1694 > Project: Maven 2 > Type: Wish > Components: Reactor and workspace > Reporter: Mark Proctor > > > Currently in multi module projects you can only work in 2 modes. > 1) Build everything > 2) Build a single module, IF you have built and installed all its dependency > modules > I would like to be able to work the following way: > 1) Build everything > 2) Build an individual module, will build all the modules prior to it in the > reactor list. > 3) Build a module module and all modules after it in the reactor list, will > build missing prior modules. > Use Case > 1) perform checkout and build > 2) module fails > 3) keep fixing module and running just its unit tests > 3) once all its unit tests pass build it and all modules after it in the > reactor list. I don't need to build ones prior as they are unnaffected by the > changes. > In large mutli module projects this will save a LOT of time especially when > you are gearing up for deployment and want to check that everything works - > currently this is time consuming and repetitive, with much of the repetition > uneeded. -- 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-1694) Build execution order control in fine grained projects.
Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: maven-compiler-plugin Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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-1692) Project scoped Repository
Project scoped Repository - Key: MNG-1692 URL: http://jira.codehaus.org/browse/MNG-1692 Project: Maven 2 Type: Wish Components: Artifacts and Repositories Reporter: Mark Proctor Fix For: 2.1 In multi module builds I would like jars to not instally locally until I instruct it and still be able to build individual modules. At the moment if I try and build an invidiual module it insists on looking in the local repo. In Maven 1 we worked around this by using jar override. The use case for this is for when you are messing around with multiple checkouts of the same version and don't want them to interact with each other. With current M2 I either have to create different versions in the pom for each checkout, when all changes are likely to end up in the "master" checkout for a specific verison. Or I can specify the repo to be in the project, but that means I have to checkout everything each time I want to build something. This could be achieve by using root/target as a project level repo for the produced jars which would use the local repo for anything that it can't find it the project repo. Only when I tell it to install will it copy the jars from the project repo to the local repo. -- 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-441) surefire plugin needs to be able to fork tests
[ http://jira.codehaus.org/browse/MNG-441?page=comments#action_52064 ] Mark Proctor commented on MNG-441: -- Is that .java and .pom working? If so any chance we could have a surefire snapshot release? We are currently blocked from moving Drools to M2 as maven tests for jython fail if we can't fork. > surefire plugin needs to be able to fork tests > -- > > Key: MNG-441 > URL: http://jira.codehaus.org/browse/MNG-441 > Project: Maven 2 > Type: Improvement > Components: maven-surefire-plugin > Reporter: Brett Porter > Fix For: 2.0.1 > Attachments: SurefirePlugin.java, pom.xml > > > they can leak memory, so a "fork once for all" option would be good. -- 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-710) Add ability to fork the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MNG-710?page=comments#action_52044 ] Mark Proctor commented on MNG-710: -- Will this allow different java versions to be specified on a per module basis, in a multi module build? > Add ability to fork the maven-compiler-plugin > - > > Key: MNG-710 > URL: http://jira.codehaus.org/browse/MNG-710 > Project: Maven 2 > Type: Improvement > Reporter: Rod Coffin > Assignee: Trygve Laugstol > Fix For: 2.0-beta-1 > Attachments: maven-compiler-plugin.diff.txt, > maven-compiler-plugin.diff3.txt, plexus-compiler-api.diff.txt, > plexus-compiler-api.diff3.txt, plexus-compiler-javac.diff.txt, > plexus-compiler-javac.diff2.txt, plexus-compiler-javac.diff3.txt > > > Add the ability to fork the maven-compiler-plugin. This would allow projects > to be compiled with a JDK other than the one used to run Maven from. -- 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: (MAVEN-1545) Specify target jdk per project in multibuild
[ http://jira.codehaus.org/browse/MAVEN-1545?page=comments#action_38729 ] Mark Proctor commented on MAVEN-1545: - I'm adding this converation bob and I had with trygvis, to see if it sheds any more light: [13:35] why didn't brett's solution fix your problem conan? [13:37] trygvis: because groovy would not work with jdk1.5, not matter what you set the comile source and target to [13:37] "not work", how? [13:37] trygvis: let me find the groovy jira [13:37] trygvis: groovy has bugs [13:38] well, that's not new is it? :p [13:38] nope, but something we have to work around [13:40] http://jira.codehaus.org/browse/GROOVY-280 http://jira.codehaus.org/browse/GROOVY-520 http://jira.codehaus.org/browse/GROOVY-477 [13:40] trygvis: no its not new barry originally opened the jira some time ago, brett closed it off as a "wont fix" - I dont think he fully understood the situation. [13:41] no, and neither did I [13:41] trygvis: we could not compile drools with jdk1.5 because groovy would not work - groovy broke the jdk1.5 verifier. [13:42] yes it was a fault of groovy, not jdk/maven, but maven did not facilitate an easy workaround. [13:42] sounds like the code/bytecode that you're generating is no good, don't see the relation to maven [13:43] what more did you want from maven? you tell it the source level for you code and it'll use that as a argument to javac [13:43] trygvis: no that didn't work with the groovy issue. [13:43] use a different javac I'd think [13:43] ie, set java.home per project [13:44] trygvis: thats what I'm saying if a project like Groovy/ASM does something silly that worked with jdk1.4 but not with jdk1.5 it screws over projects like drools. [13:44] why would you want to do that? if you build with a 1.5 jdk that would contain everything you need [13:44] trygvis: which means we either have to hack maven, or switch to ant. [13:44] trygvis: but we could not build with jdk1.5, thats the point. [13:45] using jdk1.5 with source-level 1.4 still buggers groovy [13:45] aha [13:46] sure, blame groovy, ultimately [13:46] or the jdk [13:47] trygvis: but ultimately specifying not only compile src and target but also a jdk home would be a good thing - this keeps maven inline with how eclipse and intellij work too. > Specify target jdk per project in multibuild > > > Key: MAVEN-1545 > URL: http://jira.codehaus.org/browse/MAVEN-1545 > Project: maven > Type: Improvement > Versions: 1.0.2 > Reporter: Barry Kaplan > > > We have a project (Drools) in which some modules require compilation with > jdk5 and requires pre-jdk5. Both these modules cannot exists in the overall > multi-project build. > Maybe some type of property which indicates the JAVA_HOME to be used for a > project can be added. I suppose this might mean forking off a new maven when > the jdk changes from that of the top-level multi-build project. -- 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: (MAVEN-1545) Specify target jdk per project in multibuild
[ http://jira.codehaus.org/browse/MAVEN-1545?page=comments#action_38728 ] Mark Proctor commented on MAVEN-1545: - I forgot to mention that b) would not solve the groovy issue. b) set maven.compile.source, maven.compile.target appropriately for subprojects We tried that, didn't work, so we had to compile everything under jdk1.4 and then fork off a separate javac task to compile the jdk1.5 projects. > Specify target jdk per project in multibuild > > > Key: MAVEN-1545 > URL: http://jira.codehaus.org/browse/MAVEN-1545 > Project: maven > Type: Improvement > Versions: 1.0.2 > Reporter: Barry Kaplan > > > We have a project (Drools) in which some modules require compilation with > jdk5 and requires pre-jdk5. Both these modules cannot exists in the overall > multi-project build. > Maybe some type of property which indicates the JAVA_HOME to be used for a > project can be added. I suppose this might mean forking off a new maven when > the jdk changes from that of the top-level multi-build project. -- 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: (MAVEN-1545) Specify target jdk per project in multibuild
[ http://jira.codehaus.org/browse/MAVEN-1545?page=comments#action_38727 ] Mark Proctor commented on MAVEN-1545: - Brett, Not quite so simple. Groovy would not compiled under jdk1.5, so we had to do our own custom jdk forking within maven, not nice, as we have pure jdk1.5 modules as well. Luckily groovy has fixed this issue now and we have returned to standard multiproject builds. However for maven2.0 you might want to give this serious consideration; if Groovy or another project breaks under a future jdk version you end up with really messy build scripps - would be much easier if you can just specify JDK homes per project, like you can with eclipse. > Specify target jdk per project in multibuild > > > Key: MAVEN-1545 > URL: http://jira.codehaus.org/browse/MAVEN-1545 > Project: maven > Type: Improvement > Versions: 1.0.2 > Reporter: Barry Kaplan > > > We have a project (Drools) in which some modules require compilation with > jdk5 and requires pre-jdk5. Both these modules cannot exists in the overall > multi-project build. > Maybe some type of property which indicates the JAVA_HOME to be used for a > project can be added. I suppose this might mean forking off a new maven when > the jdk changes from that of the top-level multi-build project. -- 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]
