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..
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..
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..
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: 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..
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: 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
michael.guy...@gmail.com 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
