Comments for Software is too expensive to build cheaply... http://twasink.net/blog Robert's Rambling Ruminations Regarding Reality Fri, 26 Feb 2010 03:06:58 -0500 http://wordpress.org/?v=2.8.4 hourly 1 Comment on Maven – still giving me the shits by John http://twasink.net/blog/2010/02/maven-still-giving-me-the-shits/comment-page-1/#comment-1030 John Fri, 26 Feb 2010 03:06:58 +0000 http://twasink.net/blog/?p=723#comment-1030 Out of curiosity, have you tried m2eclipse? I haven't used the eclipse plugin for probably 2 years since switching. It's definitely not perfect, but works MUCH better than the bad old way, IMO Out of curiosity, have you tried m2eclipse? I haven’t used the eclipse plugin for probably 2 years since switching. It’s definitely not perfect, but works MUCH better than the bad old way, IMO

]]> Comment on This is why Maven gives me the shits… by Maven – still giving me the shits | Software is too expensive to build cheaply… http://twasink.net/blog/2009/06/this-is-why-maven-gives-me-the-shits/comment-page-1/#comment-1028 Maven – still giving me the shits | Software is too expensive to build cheaply… Thu, 25 Feb 2010 23:51:02 +0000 http://twasink.net/blog/?p=647#comment-1028 [...] Some months ago, I wrote about how the Maven Eclipse Plugin 2.7 release didn’t fix a bug introduced in 2.6 [...] [...] Some months ago, I wrote about how the Maven Eclipse Plugin 2.7 release didn’t fix a bug introduced in 2.6 [...]

]]> Comment on M2Eclipse Plugin is not for me by Robert http://twasink.net/blog/2009/06/m2eclipse-plugin-is-not-for-me/comment-page-1/#comment-1027 Robert Thu, 25 Feb 2010 22:14:35 +0000 http://twasink.net/blog/?p=650#comment-1027 Like this: <pre> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-eclipse-plugin</artifactId> <version>2.5.1</version> <configuration> <downloadSources>true</downloadSources><!-- Having source code references is a "Good Thing" (tm) --> <downloadJavadocs>true</downloadJavadocs><!-- Having source code references is a "Good Thing" (tm) --> <buildOutputDirectory>${eclipse.classes.dir}</buildOutputDirectory><!-- Not having to re-compile everything inside Eclipse just because you've done a Maven clean is also a "Good Thing" (tm), but not everyone likes it, so it's configurable (and off by default) --> <useProjectReferences>true</useProjectReferences> </configuration> </plugin> </pre> Like this:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-eclipse-plugin</artifactId>
    <version>2.5.1</version>
    <configuration>
        <downloadSources>true</downloadSources><!-- Having source code references is a "Good Thing" (tm) -->
        <downloadJavadocs>true</downloadJavadocs><!-- Having source code references is a "Good Thing" (tm) -->
        <buildOutputDirectory>${eclipse.classes.dir}</buildOutputDirectory><!-- Not having to re-compile everything inside Eclipse just because you've done a Maven clean is also a "Good Thing" (tm), but not everyone likes it, so it's configurable (and off by default) -->
        <useProjectReferences>true</useProjectReferences>
    </configuration>
</plugin>
]]> Comment on M2Eclipse Plugin is not for me by EDH http://twasink.net/blog/2009/06/m2eclipse-plugin-is-not-for-me/comment-page-1/#comment-1017 EDH Thu, 11 Feb 2010 17:08:19 +0000 http://twasink.net/blog/?p=650#comment-1017 Are you sure about "Of course you can change the output-folder by modifying your pom.xml to have separate output-folders for your class-files". My experience is that a lot of Maven plugin cannot be configured to produce their output in a particular non-default location. 80 of your output will be produced in a separate folder, but 20 will still be produced in the same target folder, resulting in an even bigger nightmare. Or am I wrong ? I hope so. Are you sure about “Of course you can change the output-folder by modifying your pom.xml to have separate output-folders for your class-files”.
My experience is that a lot of Maven plugin cannot be configured to produce their output in a particular non-default location. 80 of your output will be produced in a separate folder, but 20 will still be produced in the same target folder, resulting in an even bigger nightmare.
Or am I wrong ? I hope so.

]]> Comment on M2Eclipse Plugin is not for me by Ustaman http://twasink.net/blog/2009/06/m2eclipse-plugin-is-not-for-me/comment-page-1/#comment-1016 Ustaman Tue, 09 Feb 2010 16:59:57 +0000 http://twasink.net/blog/?p=650#comment-1016 @Benedict 1. Of course you can change the output-folder by modifying your pom.xml to have separate output-folders for your class-files. U mean the output folder for eclipse could be configured to be different than the one in the pom.xml? How? @Benedict
1. Of course you can change the output-folder by modifying your pom.xml to have separate output-folders for your class-files.
U mean the output folder for eclipse could be configured to be different than the one in the pom.xml? How?

]]> Comment on ehcache dissected by Brian H http://twasink.net/blog/2005/10/ehcache-dissected/comment-page-1/#comment-1013 Brian H Thu, 28 Jan 2010 23:13:17 +0000 http://twasink.net/wp/?p=174#comment-1013 Hello again. It took a long time to get the time for it, but I've finally implemented an ExpiredBetterThanNullSelfPopulatingCache and some other features. I've started a SourceForge project: http://sourceforge.net/projects/ehcache-zen/ @VA, @Robert, @oby1, @Lee, and others, please check it out and let me know on the forums there your feedback. Hello again. It took a long time to get the time for it, but I’ve finally implemented an ExpiredBetterThanNullSelfPopulatingCache and some other features.

I’ve started a SourceForge project: http://sourceforge.net/projects/ehcache-zen/

@VA, @Robert, @oby1, @Lee, and others, please check it out and let me know on the forums there your feedback.

]]> Comment on ehcache dissected by Robert Nicholson http://twasink.net/blog/2005/10/ehcache-dissected/comment-page-1/#comment-948 Robert Nicholson Mon, 23 Nov 2009 03:35:14 +0000 http://twasink.net/wp/?p=174#comment-948 In your earlier post you suggest that ehcache isn't a distributed cache and back then it may not have been but is there any opinions on how well it operates as a distributed cache? In my environment we have n processes that each have their own in memory and diskstore ehcache's. It's possible we could benefit from collapsing the overlap we have across these caches but to be honest memory isn't a problem and doing so would result in more contention across these processes. In your earlier post you suggest that ehcache isn’t a distributed cache and back then it may not have been but is there any opinions on how well it operates as a distributed cache? In my environment we have n processes that each have their own in memory and diskstore ehcache’s. It’s possible we could benefit from collapsing the overlap we have across these caches but to be honest memory isn’t a problem and doing so would result in more contention across these processes.

]]> Comment on OSGi Diaries – Creating A Bundle by Robert http://twasink.net/blog/2009/09/osgi-diaries-creating-a-bundle/comment-page-1/#comment-884 Robert Wed, 23 Sep 2009 01:36:42 +0000 http://twasink.net/blog/?p=691#comment-884 Thanks, Sahoo. That's basically what I thought, but I didn't want to commit to that. I will be covering hybrid applications in a few entries - I've been spending a lot of time reading your blog recently, and would highly recommend it to others. Thanks, Sahoo. That’s basically what I thought, but I didn’t want to commit to that.

I will be covering hybrid applications in a few entries – I’ve been spending a lot of time reading your blog recently, and would highly recommend it to others.

]]> Comment on OSGi Diaries – Creating A Bundle by Sahoo http://twasink.net/blog/2009/09/osgi-diaries-creating-a-bundle/comment-page-1/#comment-883 Sahoo Wed, 23 Sep 2009 01:34:16 +0000 http://twasink.net/blog/?p=691#comment-883 GlassFish does not resolve any version conflicts in this case; it makes available all exported packages to all Java EE applications. If you want explicit control over dependencies, you can deploy your web application as an OSGi bundle. I call this a hybrid application. Take a look at http://weblogs.java.net/blog/2009/06/14/developing-hybrid-osgi-java-ee-applications-glassfish GlassFish does not resolve any version conflicts in this case; it makes available all exported packages to all Java EE applications. If you want explicit control over dependencies, you can deploy your web application as an OSGi bundle. I call this a hybrid application. Take a look at http://weblogs.java.net/blog/2009/06/14/developing-hybrid-osgi-java-ee-applications-glassfish

]]> Comment on OSGi Diaries – A short series by Robert http://twasink.net/blog/2009/09/osgi-diaries-a-short-series/comment-page-1/#comment-878 Robert Tue, 22 Sep 2009 13:33:43 +0000 http://twasink.net/blog/?p=684#comment-878 These days, I'm using Maven, at least at work and I don't do enough personal coding to bother looking elsewhere. Sigil sounds interesting - using OSGi runtime data about dependencies would probably solve the worst of the dependency nightmares you get with Maven (which are mostly caused by the over-eager transitive dependencies). For the purposes of these examples, I intend to keep very tool free - anyone should be able to follow even if they use a tool besides Maven. No plugin magic for now. Eventually, I'll expand outwards to tool support - I will see if I can fit in an Ant example with Sigil then. These days, I’m using Maven, at least at work and I don’t do enough personal coding to bother looking elsewhere. Sigil sounds interesting – using OSGi runtime data about dependencies would probably solve the worst of the dependency nightmares you get with Maven (which are mostly caused by the over-eager transitive dependencies).

For the purposes of these examples, I intend to keep very tool free – anyone should be able to follow even if they use a tool besides Maven. No plugin magic for now. Eventually, I’ll expand outwards to tool support – I will see if I can fit in an Ant example with Sigil then.

]]>