Re: Publishing...

[Tim Brown]

I believe you're confusing the purposes of repositories and caches.
 Please review the cache concept -
http://ant.apache.org/ivy/history/latest-milestone/concept.html#cache

You should _not_ be using  cache as a repository; don't point both a
resolver and a cache to the same directory structure.  This is called on cache
documentation
.

Selectively killing cache contents sounds useful to me too.


As for your publishing - each time you publish an artifact, is it a new
[different] version - or are you always re-publishing with the same version?



On Thu, Mar 24, 2011 at 6:04 AM, Richard_Senior wrote:

>
> In my opinion, Ivy needs the ability to publish to caches, as well as
> resolvers.
> We also need the ability to wipe individual caches by name.
> Better yet there should be an ant task that allows for dependancies marked
> in a particular way to be wiped from the local cache.
> --
> View this message in context:
> http://old.nabble.com/Publishing...-tp31221641p31228706.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>

Re: ivy:buildlist and parallizing build

[Tim Brown]

Hi Jonathan,

I've messed with this challenge with varying levels of success.

The primary issue is if you're changing a few modules (say A, B, and C) and
those modules have interdependencies (say C depends on A).  If you go
parallel, C is likely to resolve the old version of A.

Not saying it can't be done, but to make things simpler the last build
pipeline I did in this manner: 1) identify changed modules and build/unit
test them in order (serially), 2) identify impacted non-container modules
(jars, etc. that depend on changed modules, directly or indirectly) and
process them fully parallel , 3) identify impacted container modules (war,
ear, etc.) and process them in parallel.  (not using subant, btw -- just
"runtarget" from ant-contrib and overriding a few properties)

However -- if you're still building to or from a standard disk (or SAN, or
NAS) then you're more likely to get a much bigger benefit to moving over to
SSD to RAM than you will from parallelizing individual modules builds - and
much simpler too.

I normally see commit builds in an I/O bound situation which slows them
down. Try running your build from /dev/shm and see what kind of performance
difference you get.

HTH,

~Tim


On Fri, Jul 8, 2011 at 1:40 PM, Jonathan Williams
wrote:

> Hi,
>
> We currently use Ivy:buildlist + subant to build a large multi-module
> project. As the project grows, the topic of parallelization has inevitably
> come up as one of the ways we could speed up compiles. A search on this
> topic has shown some interest in implementing this in the past, but nothing
> recent or concrete as far as results go. Does anyone have a solution for
> this, or are we SOL?
>
> -Jonathan
>

Re: Question about excludes

[Tim Brown]

I think you can use Override to force the transitive dependency to the
higher version.

http://ant.apache.org/ivy/history/2.0.0/ivyfile/override.html

~Sent from my mobile device. Please pardon any oddities :-)

On Jul 27, 2011, at 4:18 AM, David Sills  wrote:

> All:
>
> I have a project that has a dependency on slf4j. I'm generally using
> 1.6.1 (with my own patch to fix a bug), but one of my dependencies has a
> transitive dependency on 1.5.6. I cannot figure out how to get rid of
> this JAR file in the ivyIDE container. I am trying this:
>
>  artifact="com.springsource.slf4j.api-1.5.6.jar" matcher="exact"/>
>
> The org and module correspond exactly to how the offending JAR file is
> stored in my repository. I know I have to be missing something, but I
> simply can't see it. Does anyone?
>
> I have tried:
>
> 
>
> But of course that removes all versions of the JAR file, even the one I
> want to keep. Can someone explain why there is not a "rev" attribute in
> the exclude element? It would seem logical - don't take this revision of
> the library.
>
> Thanks!
>
> David Sills
>

Re: IVYDE, Eclipse 3.5 & WTP

[Tim Brown]

We actually have this working.  Had the same issue, but I don't recall
exactly what the cause was. (it's been a while)

I'll dig into my current setup and see how it differs, perhaps we can sort
it out.

I'm running OSX, Galileo SR2, but with Ivy 2.2.x-local-20091117220235 and
IvyDE 2.1.0.200911161501-hudson-79.

Yes, that's a trunk release.  It was for a bug fix, but I don't remember
which :(.  It's' been stable for us (>100 developers) for months now.

My .classpath entry for Ivy is slightly different:


  
  

  

I also have the Dyanamic Web module and Java facets set on my [war] project.

When I resolve I can expand the Ivy lib reference, revealing resolved
workspace projects and jars.

Deploying to Tomcat 6 via WTP works as expected.


~Tim

On Tue, Apr 13, 2010 at 9:31 PM, Eric Gulatee wrote:

> All,
>
> I've constantly had problems getting my dependencies declared in ivy to be
> published to the tomcat server.
> Before you answer just add the JavaEE module dep, I have already done
> that...
>
> When I check my .metadata where the WebApp is being published, I don't see
> a
> lib directory under WEB-INF.
>
> I am using eclipse 3.5, MaxOSX, IVY 2.1.0 IVYDE 2.0.0 final.
>
>
> Any thoughts?  Any way to debug this?
> I tried a few options:
>
> ivy with all confs
> Wiped our my tomcat, forced a republish...  No effect.
>
>
> To prove I didn't miss the JavaEE module dep:
> Here's my .classpath
>
> ?xml version="1.0" encoding="UTF-8"?>
> > 
> >  > path="src/main/java"/>
> > 
> >  > path="src/test/java"/>
> > 
> >  > path="src/main/resources"/>
> >  >
> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
> >  >
> path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&confs=*">
> > 
> >  > name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>
> > 
> > 
> > 
> > 
> >
>
>
> Tomcat is complaining about a spring web context class..
>
> SEVERE: Error configuring application listener of class
> org.springframework.web.context.ContextLoaderListener
> java.lang.ClassNotFoundException:
> org.springframework.web.context.ContextLoaderListener
>
>
> However...
>
> I do have spring-web-  listed as a dep/jar in ivy.xml
> And the jar does have the missing class...
>
> package org.springframework.web.context;
> >
> > import javax.servlet.ServletContextEvent;
> > import javax.servlet.ServletContextListener;
> >
> > /**
> >  * Bootstrap listener to start up and shut down Spring's root {...@link
> > WebApplicationContext}.
> >  * Simply delegates to {...@link ContextLoader} as well as to {...@link
> > ContextCleanupListener}.
> >  *
> >  * This listener should be registered after
> >  * {...@link org.springframework.web.util.Log4jConfigListener}
> >  * in web.xml, if the latter is used.
> >  *
> >  * @author Juergen Hoeller
> >  * @since 17.02.2003
> >  * @see org.springframework.web.util.Log4jConfigListener
> >  */
> > public class ContextLoaderListener extends ContextLoader implements
> > ServletContextListener {
> >
> >
>
> As I said, I do a few cleans, have wiped out the server.  changed
> workspace.  Issue remains the same...
>
> I never do see WEB-INF/lib get created under the appropriate directory
> under
> .metadata in my workspace.
>
>
> Any thoughts?  I don't think I'm doing anything silly/obviously wrong...
> I have had this flaky behaviour before where publish wouldn't always
> publish...  It did work eventually...  [After cleans, Destroy servers,
> change workspace]
>
> Cheers,
> Eric G.
>

Re: Publishing C-module artifacts from different platforms

[Tim Brown]

I'd vote for Go, but I've been an influence in it's development ;-)  But
yeah, Hudson and such have greatly improved too.

Currently on CruiseControl handling >30,000 builds a month. 68 pipelines,
with continuous deployment etc etc etc.

We'd looked at QB too (ages ago, 3+ years sounds right), but it didn't suit
our needs.

Anyway, that's off-topic.

For the intermediate artifacts we'd started off down the local publish path,
but have since switched to using an integration versions.  The integration
version supersedes the newest "released" version and pops the released off
the stack.

Jacob (cc'ed) can probably give the sorted details if it's of use.


On Thu, Jan 13, 2011 at 8:10 AM, Shawn Castrianni <
shawn.castria...@halliburton.com> wrote:

> I tried Bamboo and Hudson 2 years ago when I was evaluating all of the
> different tools.  I found QuickBuild to be, by far, the easiest to setup my
> complicated build pipeline.  Some systems, I had to resort to writing shell
> commands to do the actual copy of artifacts from one build machine to
> another.  QuickBuild has this concept built in to its default steps.
>  Anyway, I strongly urge everyone to take a look at QuickBuild 3.1.  It is
> free until you start needing lots of build configurations.  Again, sorry for
> the QuickBuild commercial on an IVY mailing list.  Perhaps Bamboo and Hudson
> have made this easier in their newer versions, haven't looked at them
> recently.
>
> ---
> Shawn Castrianni
>
>
> -Original Message-
> From: Tim Brown [mailto:tpbr...@gmail.com]
> Sent: Thursday, January 13, 2011 9:21 AM
> To: ivy-u...@ant.apache.org
> Subject: Re: Publishing C-module artifacts from different platforms
>
> Felix,
>
> But if it's a single source base, for multiple platforms, wouldn't building
> and publishing for a single platform be considered not fully tested?
>
> If the developer wants to share his WIP code with another, why wouldn't he
> just use a patch instead? [or, build it for the other platforms, test it,
> then commit it all so that CI does it's job]
>
> side-note: yeah, you can do the build pipeline similar to Shawn's with
> Hudson [and Go, and Bamboo, etc.]
>
> On Wed, Jan 12, 2011 at 11:23 PM, Felix Drueke  >wrote:
>
> > Shawn, thanks for that valuable input.
> >
> > I assume we're going for a pretty similar procedure.
> > We're using Hudson to verify that the build still works on all platforms
> > and compilers.
> > So I guess it's also possible to have Hudson publish the artifacts right
> > away
> > (didn't try that yet).
> >
> > However there's still one reason why I think that artifacts for just one
> > platform should be publishable (at least for dev-snapshots).
> > That is if a developer wants to publish the results of his latest work
> > in his current workspace. In that case he'll just want to publish for
> > just one platform and that's sufficient in that situation.
> >
> > Felix
> >
> >
> > Shawn Castrianni wrote, on 01/12/2011 05:19 PM:
> >
> >  I can't answer your question, but I can tell you how I handle this.
> >>
> >> I felt it was a bad idea to publish a partial module such that one
> >> platform's artifacts are present and other are not.  If this happens
> because
> >> of a compiler error on one platform but not others, then you can get
> into a
> >> bad situation.  Such as, someone saying that my new feature works on
> linux
> >> but not on windows, not knowing that it works on linux because the new
> >> feature was compiled successfully on that platform and he is using the
> new
> >> published module.  But when he tries on windows, he is picking up on old
> >> published module since a new one with windows artifacts is not present
> due
> >> to the compile error.  Stuff like that.
> >>
> >> Therefore, what I do is just as you describe, using separate
> configuration
> >> for each platform.  But then I use a good automated build system
> (QuickBuild
> >> 3.1) to wrap ivy commands.  So my QB build workflow is:
> >>
> >> 0. randomly select a master build machine from the pool, let's call it
> >> MASTER
> >> 1. MASTER:  checkout source on any machine
> >> 2. MASTER:  tar up source
> >> 3. MASTER:  copy source to other platform build machines
> >> 4. EACH PLATFORM:  untar onto each of those machines
> >> 5. MASTER:  delete tar file
> >> 6. MASTER:  clean.all
> >> 7. MASTER:  ivy dependencies (specifying prop