Re: Recursive maven projects
Actually, this isn't a bad idea - looking at modules and including all things that aren't in the module spec. At least in theory. Where it breaks down is that modules can be of the form: ../sibling-child-project Though you could just construct the relevant canonical path and determine if the canonical path is still under the current project, and if so - exclude it. As to how, if your scm doesn't support an exclusion, then you'd have to find all children, do an SCM -N on the parent, then iterate through all non-excluded children and do an update on those. The problem isn't (likely) one of unfeasibility, it's one of making it relatively clean. If it's too messy, then it can be a bear for the user to configure. Christian. On 23-Jan-08, at 13:37 , Patrick Shea wrote: Well, it's pretty similar, it means don't run the command (maven: compile,deploy, etc and subversion: co,up etc) recursively. If there was a way to exclude from the scm command all sub projects declared in the section that would do the trick. anything else left would be considered legitimate. Patrick -Original Message- From: Wendy Smoak <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 10:27am To: continuum-users@maven.apache.org, [EMAIL PROTECTED] Subject: Re: Recursive maven projects On Jan 23, 2008 10:51 AM, Patrick Shea <[EMAIL PROTECTED]> wrote: I'm not sure I follow you, In my case I don't use the maven scm plugin to synchronize the source code, continuum dos this for me (which is the default behavior). The maven build is fine, the non-recursive parameter is used by default, it's just that the scm command is not doing the same. Non-recursive means something different to Maven and Subversion. If you check out with -N, you only get "the directory" not "the project" (which as Christian already mentioned may include src/site.) Still, I'm not opposed to adding a way to supply parameters for the scm command, to give people the option. -- Wendy
Re: Recursive maven projects
Yes. And many people do it that way. However in my case, they are not only grouping poms, but also have overall scoping documentation, since mostly they're not just "collections of subprojects" but groups that you could say have a product definition. So we document stuff at that level, since it's the logical parent of its child components. So in our case, pom projects (with some exceptions) have more semantics than merely "a bunch of stuff in modules" Christian. On 23-Jan-08, at 13:32 , Patrick Shea wrote: When you say "Almost every one of my pom projects has a /src/site" do you mean maven projects with packaging of type "pom" ? Because apart from the top pom.xml the other ones (non jar/war/ear etc) are usually just there to group sub projects under the module section and have no other use. These are the ones I don't want to be checked-out recursively. Patrick
Re: Recursive maven projects
But doesn't continuum use the plexus and maven SCM stuff under the hood? I haven't browsed the source or really watched the commits for several months, but I thought it used some of the same infrastructure for SCM handling. I could be wrong. Regardless, that really is more of a comment for the continuum-dev list, not here. As to your points below, I'm not sure that "pom projects scm calls are non-recursive by default" is really valid. Almost every one of my pom projects has a /src/site folder with content that I want to build in the nightly. But also, a lot of Maven projects are mid-migration from older build approaches, so being able to be more specific about what's pulled in and what's not is critical until a proper "maven- approved" structure is achieved. Christian. On 23-Jan-08, at 12:51 , Patrick Shea wrote: I'm not sure I follow you, In my case I don't use the maven scm plugin to synchronize the source code, continuum dos this for me (which is the default behavior). The maven build is fine, the non-recursive parameter is used by default, it's just that the scm command is not doing the same. So just adding an option (checkbox) on the build definition to prevent recursive checkout would be nice. A good bet would be that maven projects of type "pom" should be non recursive in regards to source code. You could override this later with the above option. The other way around (sync all then restrict) would leave your build workspace polluted with unnecessary files. Patrick -Original Message- From: Christian Edward Gruber <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 9:37am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Part of the problem, of course, is that this is delegated to the maven SCM stuff, so this may force a lot of feature-requests back into that project. Not a bad thing, but it's very very easy to over-specify if this isn't thought through carefully. christian On 23-Jan-08, at 12:34 , Patrick Shea wrote: Yes that would be good. In a sense what we what is a way to control the scm command string per project or add a checkbox on the build definition for non recursive. Patrick -Original Message- From: Christian Edward Gruber <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 9:19am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Actually, you don't want this, because a parent project may have / src/ site/*, so you actually want slightly more granularity on this than just "recursive pull or not" Christian. On 23-Jan-08, at 12:05 , Patrick Shea wrote: Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 8:54am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea <[EMAIL PROTECTED]> wrote: Yes that's for maven, but continuum will still call "svn up" on the entire branch. What I'm trying to avoid is to have multiple "checked out" projects with the same code. I need to pass "-N" to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
Re: Recursive maven projects
Part of the problem, of course, is that this is delegated to the maven SCM stuff, so this may force a lot of feature-requests back into that project. Not a bad thing, but it's very very easy to over-specify if this isn't thought through carefully. christian On 23-Jan-08, at 12:34 , Patrick Shea wrote: Yes that would be good. In a sense what we what is a way to control the scm command string per project or add a checkbox on the build definition for non recursive. Patrick -Original Message----- From: Christian Edward Gruber <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 9:19am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Actually, you don't want this, because a parent project may have /src/ site/*, so you actually want slightly more granularity on this than just "recursive pull or not" Christian. On 23-Jan-08, at 12:05 , Patrick Shea wrote: Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 8:54am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea <[EMAIL PROTECTED]> wrote: Yes that's for maven, but continuum will still call "svn up" on the entire branch. What I'm trying to avoid is to have multiple "checked out" projects with the same code. I need to pass "-N" to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
Re: Recursive maven projects
Actually, you don't want this, because a parent project may have /src/ site/*, so you actually want slightly more granularity on this than just "recursive pull or not" Christian. On 23-Jan-08, at 12:05 , Patrick Shea wrote: Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2008 8:54am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea <[EMAIL PROTECTED]> wrote: Yes that's for maven, but continuum will still call "svn up" on the entire branch. What I'm trying to avoid is to have multiple "checked out" projects with the same code. I need to pass "-N" to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
Re: Problem in 1.1-beta-4
Hmm. further to this, it works on my Mac, and doesn't on my OpenBSD box, running jdk 1.5.0. Before I had some problems with hte database not being created, which turned out to be related simply to available file descriptors. At this point, I have pushed every ulimit category to its maximum, and I get no actual errors or problems that wuould indicate why it's not accepting the login. I tried more ways, and explicitly tried bad passwords and bad usernames to ensure that it does, indeed, fail in more obvious ways in those cases. It does. In this case, it take it, accepts the password, but fails to set soemthing somewhere that is necessary for it to determine that the user IS logged in. Maybe it's not creating a session properly? I'm not sure. Can I run continuum such that I get the debug output? I'm sure I can, but I'm not sure what files to edit to do so. Maybe something's showing in the logs. Btu there are no ERROR logs showing at all. Very frustrating. It's probably configuration of the user, but I can't see what, since I've maxed it all out. Christian. On 30-Oct-07, at 4:29 PM, Christian Edward Gruber wrote: Hi, I've unzipped beta4, run it, and it asks to create the admin user. I do that, and it goes to what seems like it should be system configuration, but it requires login. I then attempt to login as admin (which was just created) and for a minute it looks like it was about to succeed, but then returns to the login screen. This is distinct from a bad username/password, which show an error. this just goes there like if you go to any url and you haven't been authenticated. No matter what, whether I login or go elsewhere it just sends me back to the login page. The log doesn't say much - just: 2007-10-30 11:37:45,428 [SocketListener0-0] INFO com.opensymphony.xwork.Action:redback-admin-account - user = UserCredentials[username=admin,fullName=Build User,[EMAIL PROTECTED] ,password=<***>,confirmPassword=<***>] 2007-10-30 11:37:46,123 [SocketListener0-0] INFO com .opensymphony .xwork.interceptor.Interceptor:redbackForceAdminUserInterceptor - Admin user found. No need to configure admin user. 2007-10-30 11:37:47,172 [SocketListener0-0] INFO com.opensymphony.xwork.Action:configuration - baseUrl='http://207.188.87.165:8080/continuum' 2007-10-30 11:38:17,102 [SocketListener0-0] INFO com.opensymphony.xwork.Action:configuration - baseUrl='http://207.188.87.165:8080/continuum' These last two are the results of logging in as admin in the subsequently delivered login screens. Any thoughts? Christian.
Problem in 1.1-beta-4
Hi, I've unzipped beta4, run it, and it asks to create the admin user. I do that, and it goes to what seems like it should be system configuration, but it requires login. I then attempt to login as admin (which was just created) and for a minute it looks like it was about to succeed, but then returns to the login screen. This is distinct from a bad username/password, which show an error. this just goes there like if you go to any url and you haven't been authenticated. No matter what, whether I login or go elsewhere it just sends me back to the login page. The log doesn't say much - just: 2007-10-30 11:37:45,428 [SocketListener0-0] INFO com.opensymphony.xwork.Action:redback-admin-account - user = UserCredentials[username=admin,fullName=Build User,[EMAIL PROTECTED] ,password=<***>,confirmPassword=<***>] 2007-10-30 11:37:46,123 [SocketListener0-0] INFO com .opensymphony .xwork.interceptor.Interceptor:redbackForceAdminUserInterceptor - Admin user found. No need to configure admin user. 2007-10-30 11:37:47,172 [SocketListener0-0] INFO com.opensymphony.xwork.Action:configuration - baseUrl='http://207.188.87.165:8080/continuum' 2007-10-30 11:38:17,102 [SocketListener0-0] INFO com.opensymphony.xwork.Action:configuration - baseUrl='http://207.188.87.165:8080/continuum' These last two are the results of logging in as admin in the subsequently delivered login screens. Any thoughts? Christian.
Re: Project Notifier removed when editing build definitions
Yes. Happened after Rahul's notification re-work. Jesse McConnell wrote: > This was on trunk, correct? > > > rahul, this might be an issue in the notifier actions > > jesse > > On 11/7/06, Emmanuel Hugonnet <[EMAIL PROTECTED]> wrote: >> Hi, >> I have edited my build definition since I have to pass some parameters >> via -D. After that my notifier which was imported from my POM was >> removed :(. It looks like updating the project configuration updates >> everything based on submit and not on previous configuration + changes. >> In the database all is removed :( >> > > -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: Performance collapse when logged as admin
Hmm. It would probably be wise to fetch the logo upon configuration change, and drop it in the local database, then serve it from the db (cached in memory after first load, of course). It's only one image, and I think having it locally available might be useful. regards, Christian. P.S. There might be licensing/copyright issues, but that's really the problem of the administrator. I suppose a check-box to say "cache logo locally" would be a good way to keep maximal choice. -cg Carlos Sanchez wrote: > I saw that problem when the logo is not available and times out, the > page looks slow. > > On 11/7/06, Artamonov, Juri <[EMAIL PROTECTED]> wrote: >> What I did is just installed Maestro 1.1 and created admin user. Then I >> just added simple single module project and defined several goals for >> it. That's all. After I saw that it's slow comparing with Maestro 1.0.1 >> and I couldn't start any goal I created except default goal I decided to >> move back to Maestro 1.0.1. >> >> Please let me know if you have more questions. >> >> Best regards, >> Juri. >> >> -Original Message- >> From: Jesse McConnell [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, November 07, 2006 3:55 PM >> To: continuum-users@maven.apache.org >> Subject: Re: Performance collapse when logged as admin >> >> >> k, then my bet is its something up with that authz behavior there. >> >> do you have any custom roles? >> >> what is the name of the project in question? (ie, The Doxia Project) >> you can make something up that follows the same naming structure >> >> thanks, and I'll try and nail this down in continuum >> jesse >> >> On 11/7/06, Artamonov, Juri <[EMAIL PROTECTED]> wrote: >> > I believe the same that goes with Continuum, yea I suppose this is >> > derby. >> > >> > -Original Message- >> > From: Jesse McConnell [mailto:[EMAIL PROTECTED] >> > Sent: Tuesday, November 07, 2006 3:48 PM >> > To: continuum-users@maven.apache.org >> > Subject: Re: Performance collapse when logged as admin >> > >> > >> > hm, that sounds to me like it would be an issue with the speed of >> > authz activities on those pages, they had been really slow until I put >> >> > in abit of per page caching in the session to speed it up...and it was >> >> > a lot faster from then on...but this could be something related to >> > that. >> > >> > what database are you guys using for this? the derby one with the >> > release? >> > >> > jesse >> > >> > On 11/7/06, Artamonov, Juri <[EMAIL PROTECTED]> wrote: >> > > Yes, I had the same and also I see th bug which not allowing me to >> > > start every created goal for project. I also decided to return to >> > > 1.0.1. >> > > >> > > Best regards, >> > > Juri. >> > > >> > > -Original Message- >> > > From: Samuel Langlois [mailto:[EMAIL PROTECTED] >> > > Sent: Tuesday, November 07, 2006 12:28 PM >> > > To: continuum-users@maven.apache.org >> > > Subject: Performance collapse when logged as admin >> > > >> > > >> > > Hello, >> > > >> > > I find Continuum web console very slow, especially when logged as >> > > admin, and I think there is something wrong. >> > > >> > > For instance, to display the summary page of a project group >> > > containing 3 projects, it takes a few seconds when not logged in, >> > > and 20s when logged as admin. For a project group containing 58 >> > > projects, it goes from 15s (which is already quite long...) to an >> > > amazing 130s when logged as admin. >> > > >> > > I use Continuum 1.0.3-maestro-1.1 with all default settings. I have >> > > the feeling (but cannot confirm) that the version shipped with >> > > Maestro >> > >> > > 1.0.1 did not show this problem. My server is a Pentium4, 1.5GHz >> > > under >> > >> > > Fedora Core 5. Not really a speed king, but still... I recently >> > > upgraded it to 1Go RAM without much effect. >> > > >> > > Am I the only one in this situation? >> > > How can I help diagnose the problem further? >> > > >> > > Thanks for your help >> > > >> > > Samuel >> > > >> > > >> > > >> > >> > >> > -- >> > jesse mcconnell >> > [EMAIL PROTECTED] >> > >> >> >> -- >> jesse mcconnell >> [EMAIL PROTECTED] >> > > -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: [Multiple modules]
Yeah. There's a ticket in the maven JIRA about it, proposing that
${parentSCMUrl}/${modulePath} be used instead of
${parentSCMUrl}/${artifactId}. No notion of whether it will be actually
accepted and implemented.
The proper workaround is to explicitly define SCM urls in each child
project, as I believe was mentioned earlier, or to make your sub-project
modules under the parent and make the folder name equal to the artifactId.
This is, however, really problematic for working with maven and eclipse
simultaneously, as you can't get the full project set, including parent,
loaded in eclipse, because eclipse cannot support sub-projects nested in
other projects.
Cheers,
Christian.
David Roussel wrote:
> That does seem to be the convention in Maven (it's not a continuum
> thing), that the modules are most often in subfolders of the parent
> project, and have folder names the same as the project name.
>
> On Mon, 25 Sep 2006 14:07:01 +0200, "Francois Le Fevre"
> <[EMAIL PROTECTED]> said:
>
>> Dear all,
>>
>> I have identified my error: it seems that module and parent artifact id
>> have to match to the folder name when using subversion and continuum!
>> Could you please confirm the convention?
>>
>> Francois
>>
>> snip
>>>
>>>
>>>
>>
--
*christian** gruber + process coach and architect*
*Israfil Consulting Services Corporation*
*email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
