Re: Auth for Buildr repositories.remote
On Thu, Mar 17, 2011 at 2:38 PM, Michael Guymon wrote: > > I created a patch so that > > > repositories.remote << { :url => 'https://a.secure.repo/maven2', :username > => 'blah', :password => 'blah' } > > will work for http basic auth. When an artifact is downloaded, the auth > information is passed to the HTTP transport. > > https://issues.apache.org/jira/browse/BUILDR-577 Excellent! Thank you! > There might be an issue with the patch, since it changes the format of > repositories.remote. Instead of just being a String, it is stored as a hash > {:url => URI} or with optional auth {:url => URI, :username => String, > :password => String}. How horrible is this for backwards compatibility? > Personally, I'm not too worried about it since it's an "opt-in" feature -- existing builds are not affected unless they use the feature. Plugins may need to be adapted to support the hash but that's usually a trivial change and I don't know of any plugin that uses repositories.remote to access URLs and such. alex
Re: Auth for Buildr repositories.remote
I created a patch so that repositories.remote << { :url => 'https://a.secure.repo/maven2', :username => 'blah', :password => 'blah' } will work for http basic auth. When an artifact is downloaded, the auth information is passed to the HTTP transport. https://issues.apache.org/jira/browse/BUILDR-577 There might be an issue with the patch, since it changes the format of repositories.remote. Instead of just being a String, it is stored as a hash {:url => URI} or with optional auth {:url => URI, :username => String, :password => String}. How horrible is this for backwards compatibility? thanks, Michael On 03/10/2011 12:43 PM, Alex Boisvert wrote: Hi Michael, I think it's a good idea and I don't think it would be that much work. Use of repositories.remote for actual downloading seems to be fairly localized in buildr/packaging/artifact.rb. alex On Thu, Mar 10, 2011 at 8:56 AM, Michael Guymon mailto:michael.guy...@gmail.com>> wrote: So I am interested in getting repositories.remote to support auth. The goal is to have buildr deploy to private maven repo's I have a work. What I would like to do is have the following be valid: repositories.remote << 'https://a.secure.repo/maven2' repositories.remote << { :url => 'https://a.secure.repo/maven2' } repositories.remote << { :url => 'https://a.secure.repo/maven2', :username => 'blah', :password => 'blah' } and possibly repositories.remote << { :url => 'https://a.secure.repo/maven2', :priv_key => 'file' } I have sourced dived a little to see how repositories.remote is used, but I am not sure if this change would be a colossal PITA. If someone has a better/easier solution I would love to hear it. thanks, Michael
Re: junit default version
On 17/03/2011 15:51, Alex Boisvert wrote: I'll take care of it. Thanks for the feedback. ok thanks. I opened https://issues.apache.org/jira/browse/BUILDR-576 -- Jean-Philippe Caruana -- sorry for the crap that will be appended here: Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'attention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender..
Re: idea task
On 17/03/2011 15:32, Rhett Sutphin wrote: I didn't realize that IDEA supported dependency scope now. That's good to know. (Apparently[1] it was added in IDEA 9.) To track this request, you should open an issue in buildr's JIRA. If you want to supply a patch you attach it there. (This process is required by the ASF.) I haven't looked at your patch, so I'm not sure if it's the right solution. ok : my patch is attached to this email and to JIRA too : see https://issues.apache.org/jira/browse/BUILDR-574 Also, a remark. The CLI API changed : in the past, a simple "buildr idea" was ok to generated idea files, but now we have to do a "buildr idea:generate". This is inconsistent with the eclipse plugin (still "buildr eclipse"), makes me think of the infamous "mvn eclipse:eclipse" (argh ! eclipse twice !) and shows implementation details to the final user. What do you think about it ? Should I file a bug for that too ? I agree that it should be possible to do just "buildr idea". You should open another issue for this request. ok: https://issues.apache.org/jira/browse/BUILDR-575 As a workaround (and this is what I've been doing), you can add an idea task at the top level of your buildfile: task :idea => "idea:generate" I did the same :-) Rhett -- Jean-Philippe Caruana -- sorry for the crap that will be appended here: Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'attention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.. lib/buildr/ide/idea.rb | 13 +++-- spec/ide/idea_spec.rb |6 +++--- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/lib/buildr/ide/idea.rb b/lib/buildr/ide/idea.rb index a820d1c..3f199bf 100644 --- a/lib/buildr/ide/idea.rb +++ b/lib/buildr/ide/idea.rb @@ -192,6 +192,7 @@ module Buildr protected + # Note: Use the test classpath since IDEA compiles both "main" and "test" classes using the same classpath def test_dependency_details main_dependencies_paths = main_dependencies.map(&:to_s) target_dir = buildr_project.compile.target.to_s @@ -206,7 +207,6 @@ module Buildr end [dependency_path, export, source_path] end - end def base_directory @@ -246,7 +246,6 @@ module Buildr generate_initial_order_entries(xml) project_dependencies = [] - # Note: Use the test classpath since IDEA compiles both "main" and "test" classes using the same classpath self.test_dependency_details.each do |dependency_path, export, source_path| project_for_dependency = Buildr.projects.detect do |project| [project.packages, project.compile.target, project.resources.target, project.test.compile.target, project.test.resources.target].flatten. @@ -254,12 +253,12 @@ module Buildr end if project_for_dependency if project_for_dependency.iml? && !project_dependencies.include?(project_for_dependency) -generate_project_dependency(xml, project_for_dependency.iml.name, export) +generate_project_dependency(xml, project_for_dependency.iml.name, export, !export) end project_dependencies << project_for_dependency next else - generate_module_lib(xml, url_for_path(dependency_path), export, (source_path ? url_for_path(source_path) : nil)) + generate_module_lib(xml, url_for_path(dependency_path), export, (source_path ? url_for_path(source_path) : nil), !export) end end @@ -338,15 +337,17 @@ module Buildr xml.orderEntry :type => "inheritedJdk" end - def generate_project_dependency(xml, other_project, export = true) + def generate_project_dependency(xml, other_project, export, test = false) attribs = {:type => 'module', "module-name" => other_project} attribs[:exported] = '' if export +attribs[:scope] = 'TEST' if test xml.orderEntry attribs end -
Re: junit default version
I'll take care of it. Thanks for the feedback. alex On Thu, Mar 17, 2011 at 7:35 AM, Jean-Philippe Caruana < jeanphilippe1.caru...@orange-ftgroup.com> wrote: > Hi, > > the junit default version in buildr is still 4.7. This version is bogus (it > plays the @Rules after the @Before methods where you might want to use your > defined rules). The very last version (4.8.2) works very fine : we've used > it every day on our project for months now. I would love to delete my > "junit: 4.8.2" line in my build.yaml file. > > Should I open a bug under JIRA for this ? > > ps : no test failed when I changed the default junit version in > lib/buildr/java/tests.rb > > -- > Jean-Philippe Caruana > -- > sorry for the crap that will be appended here: > > Ce message et toutes les pieces jointes (ci-apres le "message") sont > confidentiels et etablis a l'attention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. Multimedia Business > Services decline > toute responsabilite au titre de ce message s'il a ete altere, deforme > ou falsifie. > Si vous n'etes pas destinataire de ce message, merci de le detruire > immediatement et d'avertir l'expediteur. > * > This message and any attachments (the "message") are confidential and > intended solely for the addressees. Any unauthorised use or > dissemination is prohibited. > Messages are susceptible to alteration. Multimedia Business Services shall > not be liable for the > message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender.. > >
junit default version
Hi, the junit default version in buildr is still 4.7. This version is bogus (it plays the @Rules after the @Before methods where you might want to use your defined rules). The very last version (4.8.2) works very fine : we've used it every day on our project for months now. I would love to delete my "junit: 4.8.2" line in my build.yaml file. Should I open a bug under JIRA for this ? ps : no test failed when I changed the default junit version in lib/buildr/java/tests.rb -- Jean-Philippe Caruana -- sorry for the crap that will be appended here: Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'attention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender..
Re: idea task
Hi, On Mar 17, 2011, at 9:01 AM, Jean-Philippe Caruana wrote: > Hi, > > We recently switched to buildr 1.4.5 and it's working very fine. Thanks > everyone for all your work on buildr : I am very happy with it. > > I have a few questions/remarks about the new idea task. First, it seems to > work better than the previous one, so good job ! > > I found problems with managing test dependencies : they should be marked as > scope='TEST' in the idea file ; in my code base, it made my whole project not > compiling. I have written a spec and implemented it, but I'm not very happy > with my coding : I found that changing the idea.rb wasn't easy (xml is > changed by reference - side effects, confusion between main dependencies and > test dependancies) and I made a choice (test = ! export) that is not correct. > If I want to be more precise in my implementation, I would be obliged to > rewrite the test_dependency_details method, but I might need some help for > that (I'm not a rubyist). I don't know how to add this as a test, since my > implementation passes all tests. > Should I open a bug under JIRA ? Should I propose a patch or should I make a > pull request under github ? I didn't realize that IDEA supported dependency scope now. That's good to know. (Apparently[1] it was added in IDEA 9.) To track this request, you should open an issue in buildr's JIRA. If you want to supply a patch you attach it there. (This process is required by the ASF.) I haven't looked at your patch, so I'm not sure if it's the right solution. > Please review my commit here : > https://github.com/jpcaruana/buildr/commit/7acd5f7fb68ddde9705e4ea8a366147fe358bf25 > This is working fine for our code base, but might not be correct for other > situations (since I made a drastic choice, as I explained earlier). > > Also, a remark. The CLI API changed : in the past, a simple "buildr idea" was > ok to generated idea files, but now we have to do a "buildr idea:generate". > This is inconsistent with the eclipse plugin (still "buildr eclipse"), makes > me think of the infamous "mvn eclipse:eclipse" (argh ! eclipse twice !) and > shows implementation details to the final user. What do you think about it ? > Should I file a bug for that too ? I agree that it should be possible to do just "buildr idea". You should open another issue for this request. As a workaround (and this is what I've been doing), you can add an idea task at the top level of your buildfile: task :idea => "idea:generate" That will only work for the top-level task (i.e., if you want to just regenerate one iml, you'll still have to use idea:generate in the submodule directory). Rhett [1]: http://www.jetbrains.com/idea/webhelp/dependencies-tab.html > > Thanks. > > -- > Jean-Philippe Caruana > -- > sorry for the crap that will be appended here: > > Ce message et toutes les pieces jointes (ci-apres le "message") sont > confidentiels et etablis a l'attention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. Multimedia Business > Services decline > toute responsabilite au titre de ce message s'il a ete altere, deforme > ou falsifie. > Si vous n'etes pas destinataire de ce message, merci de le detruire > immediatement et d'avertir l'expediteur. > * > This message and any attachments (the "message") are confidential and > intended solely for the addressees. Any unauthorised use or > dissemination is prohibited. > Messages are susceptible to alteration. Multimedia Business Services shall > not be liable for the > message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender.. >
Re: Maven SNAPSHOT timestamps
On 12/03/2011 03:42, Peter Donald wrote: I'm tempted to turn the feature on by default since I believe it's the right thing to do (compatibility-wise) on Maven repos. However, it could be a breaking change if people currently depend on SNAPSHOTs being updated in-place instead of uploading a new artifact with a timestamp. Anybody has a strong opinion about this? I think we should do the "right" thing and be compatibile with Maven. I think the default should stay the same in the 1.4.x branch, but could be changed for the next major release (>=1.5.0). And, it is easy to add this to the build with the Buildr.application.options.unique_version option in the buildfile, so it is okay for me. Great job anyway ! my 2cts -- Jean-Philippe Caruana -- sorry for the crap that will be appended here: Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'attention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender..
idea task
Hi, We recently switched to buildr 1.4.5 and it's working very fine. Thanks everyone for all your work on buildr : I am very happy with it. I have a few questions/remarks about the new idea task. First, it seems to work better than the previous one, so good job ! I found problems with managing test dependencies : they should be marked as scope='TEST' in the idea file ; in my code base, it made my whole project not compiling. I have written a spec and implemented it, but I'm not very happy with my coding : I found that changing the idea.rb wasn't easy (xml is changed by reference - side effects, confusion between main dependencies and test dependancies) and I made a choice (test = ! export) that is not correct. If I want to be more precise in my implementation, I would be obliged to rewrite the test_dependency_details method, but I might need some help for that (I'm not a rubyist). I don't know how to add this as a test, since my implementation passes all tests. Should I open a bug under JIRA ? Should I propose a patch or should I make a pull request under github ? Please review my commit here : https://github.com/jpcaruana/buildr/commit/7acd5f7fb68ddde9705e4ea8a366147fe358bf25 This is working fine for our code base, but might not be correct for other situations (since I made a drastic choice, as I explained earlier). Also, a remark. The CLI API changed : in the past, a simple "buildr idea" was ok to generated idea files, but now we have to do a "buildr idea:generate". This is inconsistent with the eclipse plugin (still "buildr eclipse"), makes me think of the infamous "mvn eclipse:eclipse" (argh ! eclipse twice !) and shows implementation details to the final user. What do you think about it ? Should I file a bug for that too ? Thanks. -- Jean-Philippe Caruana -- sorry for the crap that will be appended here: Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'attention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Multimedia Business Services decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. Multimedia Business Services shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender..