You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Jesse McConnell (JIRA)" <ji...@codehaus.org> on 2005/09/07 22:04:02 UTC
[jira] Created: (MNG-849) plugins that add source roots ignored under certain circumstances
plugins that add source roots ignored under certain circumstances
-----------------------------------------------------------------
Key: MNG-849
URL: http://jira.codehaus.org/browse/MNG-849
Project: Maven 2
Type: Bug
Reporter: Jesse McConnell
kenney and I talked about this on irc for a while...here is a rundown..
Use Case 1:
when working on my file activator for profiles I use the idea of checking for a file that is missing and if it is missing then activate the profile, which contains a plugin that generates the source file I want to compile...originally I was pointing at the generated java file
so for the initial execution the profile is activated and the compile source root is added to the mix of things to compile
however, after that should the build have failed and that file not have been compiled it will not be compiled from that point forward since that the file the profile was checking for did exist, just not the compiled class file version of it.
so I switched it over to activate if the classfile didn't exist.
well at that point I was just running > m2 compiler:compile which ends up bypassing the profile activation and not adding the compile source root....and since the original source files require that generated class to compile against the build is broken until there is a clean:clean and that profile is activated again.
Use Case 2:
this cropped up right after the discussion on the profile activation...dozer was using >m2 javadoc:javadoc to generate javadocs for a mess of generated classes but they were not getting picked up...since that generated source root was not readily apparent to the javadoc plugin when it was executed directly outside of the context of the normal lifecycle where such things ought to be set in the normal course of events.
Breakdown:
the thought here is that when a plugin is executed outside of the normal lifecycle it doesn't have the full context of the lifecycle in terms of compile source roots
now it could be that this isn't something that m2 should deal with, instead leaving the onus onto the plugin writers to provide configuration options to the plugins to support the users mentioning what source roots to use here and there...and at least in the example of the profile there are lots of different ways I could have done it...I chose that route to give profiles a bit of a workout.
--
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-849) plugins that add source roots ignored under certain circumstances
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-849?page=all ]
Brett Porter closed MNG-849:
----------------------------
Assign To: Brett Porter
Resolution: Won't Fix
Fix Version: (was: 2.0-beta-2)
at this point, reports requiring sources should:
@execute phase="generate-sources"
This might be horribly inefficient, but we've already got a review of this scheduled for 2.1 and beyond.
> plugins that add source roots ignored under certain circumstances
> -----------------------------------------------------------------
>
> Key: MNG-849
> URL: http://jira.codehaus.org/browse/MNG-849
> Project: Maven 2
> Type: Bug
> Reporter: Jesse McConnell
> Assignee: Brett Porter
>
>
> kenney and I talked about this on irc for a while...here is a rundown..
> Use Case 1:
> when working on my file activator for profiles I use the idea of checking for a file that is missing and if it is missing then activate the profile, which contains a plugin that generates the source file I want to compile...originally I was pointing at the generated java file
> so for the initial execution the profile is activated and the compile source root is added to the mix of things to compile
> however, after that should the build have failed and that file not have been compiled it will not be compiled from that point forward since that the file the profile was checking for did exist, just not the compiled class file version of it.
> so I switched it over to activate if the classfile didn't exist.
> well at that point I was just running > m2 compiler:compile which ends up bypassing the profile activation and not adding the compile source root....and since the original source files require that generated class to compile against the build is broken until there is a clean:clean and that profile is activated again.
> Use Case 2:
> this cropped up right after the discussion on the profile activation...dozer was using >m2 javadoc:javadoc to generate javadocs for a mess of generated classes but they were not getting picked up...since that generated source root was not readily apparent to the javadoc plugin when it was executed directly outside of the context of the normal lifecycle where such things ought to be set in the normal course of events.
> Breakdown:
> the thought here is that when a plugin is executed outside of the normal lifecycle it doesn't have the full context of the lifecycle in terms of compile source roots
> now it could be that this isn't something that m2 should deal with, instead leaving the onus onto the plugin writers to provide configuration options to the plugins to support the users mentioning what source roots to use here and there...and at least in the example of the profile there are lots of different ways I could have done it...I chose that route to give profiles a bit of a workout.
--
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-849) plugins that add source roots ignored under certain circumstances
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-849?page=all ]
Brett Porter updated MNG-849:
-----------------------------
Fix Version: 2.0-beta-2
> plugins that add source roots ignored under certain circumstances
> -----------------------------------------------------------------
>
> Key: MNG-849
> URL: http://jira.codehaus.org/browse/MNG-849
> Project: Maven 2
> Type: Bug
> Reporter: Jesse McConnell
> Fix For: 2.0-beta-2
>
>
> kenney and I talked about this on irc for a while...here is a rundown..
> Use Case 1:
> when working on my file activator for profiles I use the idea of checking for a file that is missing and if it is missing then activate the profile, which contains a plugin that generates the source file I want to compile...originally I was pointing at the generated java file
> so for the initial execution the profile is activated and the compile source root is added to the mix of things to compile
> however, after that should the build have failed and that file not have been compiled it will not be compiled from that point forward since that the file the profile was checking for did exist, just not the compiled class file version of it.
> so I switched it over to activate if the classfile didn't exist.
> well at that point I was just running > m2 compiler:compile which ends up bypassing the profile activation and not adding the compile source root....and since the original source files require that generated class to compile against the build is broken until there is a clean:clean and that profile is activated again.
> Use Case 2:
> this cropped up right after the discussion on the profile activation...dozer was using >m2 javadoc:javadoc to generate javadocs for a mess of generated classes but they were not getting picked up...since that generated source root was not readily apparent to the javadoc plugin when it was executed directly outside of the context of the normal lifecycle where such things ought to be set in the normal course of events.
> Breakdown:
> the thought here is that when a plugin is executed outside of the normal lifecycle it doesn't have the full context of the lifecycle in terms of compile source roots
> now it could be that this isn't something that m2 should deal with, instead leaving the onus onto the plugin writers to provide configuration options to the plugins to support the users mentioning what source roots to use here and there...and at least in the example of the profile there are lots of different ways I could have done it...I chose that route to give profiles a bit of a workout.
--
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org