386: Mono FUD

[Casper Bang]

Somehow a minute news item regarding the deprecation of an API in Mono, inflates to the following loaded statements:

1h14m: "What it comes down to...Mono is an ill-informed kind of thing to do..."

1h15m5s: "All it did was to confuse the issue for a while..." 

1h15m28: "They are not going away completely..."

1h16m13: "Where the story falls over, is where you have to write a separate UI for each of the platforms..."

1h18m04: "*Sigh* They'll keep trying... Mono has never been a slam dunk, we'll see if they ever get anything compelling".

Let's address this objectively without any preconceived notions or agendas for a moment, as seen from someone with a leg in both camps:

Fact; Microsoft submitted C# and the runtime spec to Ecma and has never sued anyone implementing on top of these (I.e. Boo, IronPython, Unity etc.). Meanwhile, Sun never submitted Java to any standards org, but instead made all the terms and holds veto power in the JCP. Indeed, it would prove to come at a catastrophic cost to the alternative implementation Apache Harmony. Also, Oracle's attempted to copyright the API's. So tell me, who looks like the bad guys here?!

Moonlight made Linux people able to consume Silverlight content, not unlike IcedTea made Linux people able to consume Java content. The RIA plugin race was a confusing time in general, but is there a particular reason to slander Mono for not foreseeing that none of the RIA technologies, incl. Silverlight, were the way forward?

Xamarin aren't going anywhere, they simply halted development on a deprecated technology. Has this not been known to happen in the Sun camp? (JSR-295, JSR-296 etc.)

If we have learned anything from Java, it is that a cross-platform UI toolkit just doesn't cut it - it will always be the hunt for the lowest common denominator, which is low enough to make crap on all platforms, but not low enough to make quality on any single one of these. Swing took MVC too far, while the true power of this pattern comes from being able to plug-in a new VC layer on top of M. This separation of concerns is hugely successful across the board, indeed today you even find this applying to hardcore game engines (QuakeEngine, UnrealEngine, CryENGINE etc.) which are licenced so that developers may only have to focus on front-end stuff (VC). Giving birth to a whole industry seems like a success criteria right?

As to the "nothing compelling" remark, I think you'd have to be pretty dumb, not to see the advantage of being able to target 3 separate platforms (Android, iOS and WinMobile) from within one unified umbrella when it comes to IDE, language and support. Perhaps not as interesting to a large multi-national corporation, but certainly to smaller teams with a mobile-oriented marked and limited resources or time-to marked requirements.

Look, I get it, Microsoft were a$$es in the past and you can of course spread all the FUD you want on your very own podcast - but realize that it makes you sound like old grumpy men with an agenda, and that some of the greatest leaps forward comes from cross-pollination... even if you are allergic to those pollen.

[Ricky Clarkson]

The little I've used Mono I've been impressed with it.  MonoDevelop is still the fastest IDE I've used at least on tiny projects.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/JDegHA9Z_Q4J.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

Same. Granted, I've only tried it twice in the past years, but every time, it allowed me to run a .net executable on Mac OS without any efforts. I was really impressed.

-- 

Cédric

[clay]

Casper bashes everything Java related: the language, the JVM, Swing, Maven, the IDEs and raves about everything Microsoft related: NET, C#, Mono, Anders is his hero, etc. All this on a Java group. And then complains about bias and FUD because not everyone shares his perspective. The Mono team openly bashes Java, for example, and they are not fair or making the slightest attempt at being balanced or reasonable or respectful. I think this group is far more tactful and respectful about their opinions and innate bias. Maybe because this group doesn't have a product to sell.

Each camp (JVM/.NET) should emulate and learn from the strengths of the other.

JVM needs to catch up with native application deployment that Mono brought to the .NET ecosystem. JavaFX is catching up with native Mac OS deployment and has plans for Linux and iOS. I hope this extends to Java Swing and OpenGL apps and non-Java languages.

[Casper Bang]

On Monday, June 18, 2012 7:42:49 PM UTC+2, clay wrote:

Casper bashes everything Java related: the language, the JVM, Swing, Maven, the IDEs and raves about everything Microsoft related: NET, C#, Mono, Anders is his hero, etc. All this on a Java group. And then complains about bias and FUD because not everyone shares his perspective. 

I work with the JVM, Swing, Maven etc. every day, so I think I am entitled to complain about these (let me do that now in fact, why on earth is a maven release split into two discrete steps?! And don't even get me started on the PermGen). However, I also work with Mono, and simply felt compelled to call out those heavily biased statements from #386 which boils down to "Mono was a bad idea", "Moonlight was a bad idea" and "Mono serves no purpose".

The Mono team openly bashes Java, for example, and they are not fair or making the slightest attempt at being balanced or reasonable or respectful. I think this group is far more tactful and respectful about their opinions and innate bias. Maybe because this group doesn't have a product to sell.

I know what you are referring too [recent micro-benchmarks highlighting new Mono JIT features over JVM and Dalvik], and I think it's fine to do this as long as it's at the technical level with source code and explanations of conditions - which btw. you are free to challenge, have you? It's quite another thing however, to start inferring and inflating facts, driven by some obvious innate hatred.

Each camp (JVM/.NET) should emulate and learn from the strengths of the other.

Exactly; however the problem in much of the hardcore JVM community, for a long time, has been a sense of self-richness and unwillingness to consider anything from the other camp. I've been pointing this out for as long as I've been listening (since JavaPosse 20 or so) while calling for a more nuanced blend. For example, there's a stark contrast from listening to .NET Rocks and JavaPosse, when you look at the people they have interviewed and how they approach the opposite camp. It's not isolated to this podcast though, you'll find the same childish FUD in JavaZone videos, which are fun, but also pointer of a more general problem where mockery takes precedence over machinery.

They both have their strength and weaknesses, but if all you can say is "I don't get why X exists, we have Y" then you just sound dumb and you're probably better off not saying anything at all then.

[Ralph Goers]

On Jun 18, 2012, at 12:47 PM, Casper Bang <caspe...@gmail.com> wrote:

On Monday, June 18, 2012 7:42:49 PM UTC+2, clay wrote:

Casper bashes everything Java related: the language, the JVM, Swing, Maven, the IDEs and raves about everything Microsoft related: NET, C#, Mono, Anders is his hero, etc. All this on a Java group. And then complains about bias and FUD because not everyone shares his perspective. 

I work with the JVM, Swing, Maven etc. every day, so I think I am entitled to complain about these (let me do that now in fact, why on earth is a maven release split into two discrete steps?! And don't even get me started on the PermGen). 

You do know that Maven is an open source project?  If you don't like it then participate and fix it.  Apache is a " do-ocracy" . Those who do the work get what they want. Those who only complain rarely do.

Ralph

[Fabrizio Giudici]

On Mon, 18 Jun 2012 23:34:09 +0200, Ralph Goers <ralph...@gmail.com>
wrote:

> On Jun 18, 2012, at 12:47 PM, Casper Bang <caspe...@gmail.com> wrote:
>
>> On Monday, June 18, 2012 7:42:49 PM UTC+2, clay wrote:
>> Casper bashes everything Java related: the language, the JVM, Swing,
>> Maven, the IDEs and raves about everything Microsoft related: NET, C#,
>> Mono, Anders is his hero, etc. All this on a Java group. And then
>> complains about bias and FUD because not everyone shares his
>> perspective.
>>
>> I work with the JVM, Swing, Maven etc. every day, so I think I am
>> entitled to complain about these (let me do that now in fact, why on
>> earth is a maven release split into two discrete steps?! And don't even
>> get me started on the PermGen).

It's split in two steps because you can first verify whether there are the
prerequisites for the release to be successful. But we can also say that
you can run release:prepare release:perform in the same run, so what we
are talking of? When I need to make a release, I just press a single
button on my Hudson.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Cédric Beust ♔]

On Mon, Jun 18, 2012 at 2:34 PM, Ralph Goers <ralph...@gmail.com> wrote:

If you don't like it then participate and fix it.

I am so tired of hearing this argument.

-- 

Cédric

[Ralph Goers]

Am I supposed to care?

Ralph

[Mark Derricutt]

On 19/06/12 9:34 AM, Ralph Goers wrote:
> You do know that Maven is an open source project? If you don't like
> it then participate and fix it.

And in this instance its not even "Apache Maven" thats the problem, its
the "maven-release-plugin", I always seem people bitch incessantly about
how broken the release plugin, but I still find it to be one of the most
compelling aspects of Maven.

Also, if you don't like the fact it builds/tests everything twice -
change your plugin configuration to not do that ( alter the prepareGoals
setting ) or write your own release plugin.

[Casper Bang]

On Monday, June 18, 2012 11:54:46 PM UTC+2, fabrizio.giudici wrote:

It's split in two steps because you can first verify whether there are the  
prerequisites for the release to be successful. But we can also say that  
you can run release:prepare release:perform in the same run, so what we  
are talking of? When I need to make a release, I just press a single  
button on my Hudson.

That's a decent explanation, except that it's not called "verify" but "prepare" and it pollutes /trunk when fails (POM has been modified and temp files created) requiring manual cleanup. In software API design, we learn about orthogonality and procedural cohesion, which would be nice if it applied to our tools as well. If we had release:verify (that did not screw with /trunk) and release:perform to do the actual release, things would make more sense. Maven is awesome but it has scared many a developer due to these usability things.

[Cédric Beust ♔]

On Mon, Jun 18, 2012 at 11:43 PM, Casper Bang <caspe...@gmail.com> wrote:

That's a decent explanation, except that it's not called "verify" but "prepare" and it pollutes /trunk when fails (POM has been modified and temp files created) requiring manual cleanup.

Couldn't agree more. I tried to convince Jason and the whole crew many times that it's a bad idea but I failed.

I can't count the number of times that my release process failed for some reason (bad connection, stash needed, etc...) and I found myself forced to increment my product version just to please Maven. Very irritating.

-- 

Cédric

[Ralph Goers]

This topic, of course, has nothing to do with the original. 

I would suggest you write down all the steps that have to be performed during a "normal" release - including changing revision numbers and creating tags in source control  - and then identify all the things that can go wrong and recover from them so that the whole thing is atomic or at least recoverable. If you can then create a maven release plugin that does that I'm sure there are a lot of people who would love to adopt it.   I've released software that uses the release plugin and have had to re-release several times and getting the source control system back to its original state can be a pain.

The problem with these criticisms is that these are actually fairly hard problems to solve.   For example, how would you update the versions without modifying the poms in trunk so that they can be committed? By checking out a whole new copy of the project?

Perhaps this discussion should move to the Maven developers list?

Ralph

[Casper Bang]

This topic, of course, has nothing to do with the original. 

Nope, it was a tangent born out of a desire to show clay the difference between "bashing" and complains about things you actually work with on a daily basis.

The problem with these criticisms is that these are actually fairly hard problems to solve.   For example, how would you update the versions without modifying the poms in trunk so that they can be committed? By checking out a whole new copy of the project?

You already have /trunk checked out, so all that wold be required is a local copy operation followed by an update. Bottom line, nobody can use a failed release that leaves /trunk in some unknown mutated state. If something fails, I want the report, I will try to take appropriate actions to correct the problem and try releasing the n+1 version again - hopefully successfully this time around.

[Ralph Goers]

This is really the wrong list to discuss how to address this. However, I don't follow how a local copy followed by an update helps. You have to modify trunk to commit the version change back. If for some reason the release is bad (missing files, bad signature, etc)  you need to roll it all back even though it was already committed to source control and tagged.

Ralph

[Casper Bang]

On Tuesday, June 19, 2012 9:52:25 AM UTC+2, rgoers wrote:

This is really the wrong list to discuss how to address this. However, I don't follow how a local copy followed by an update helps. You have to modify trunk to commit the version change back. If for some reason the release is bad (missing files, bad signature, etc)  you need to roll it all back even though it was already committed to source control and tagged.

Yes, so modify another version of trunk and commit from there upon successful build of artifacts, followed by a copy back to your working trunk. This issue really only comes up in non-distributed SCM's (CVS, SVN etc.) and because snapshotting/versioning filesystems (ZFS, BTRFS etc.) aren't commonplace yet. Regardless of how this is achieved however, that is an implementation detail; I just pointed out a weakness in the usability of Maven and why the learning curve is steeper than it could've been.

[Ricky Clarkson]

I find that plugin to be very good, especially that a problem can be manually fixed and the release resumed.  I've never seen it leave the remote end in a bad state and I've had some odd cases.

I'd like it to check the deploy information at the beginning instead of failing because it's missing at the perform stage, and I'd like it to not create a second copy in target/checkout, especially when that involves cloning an entire git repository and the clone is taken from the server instead of from ../

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Tv8qZjVJIgwJ.

[clay]

"Look, I get it, Microsoft were a$$es in the past and you can of course spread all the FUD you want on your very own podcast - but realize that it makes you sound like old grumpy men with an agenda"

C# was never meant as a platform agnostic language that competed on its merit and could be mixed and matched into any tool chain. So you shouldn't expect people to judge it as such and dismiss Microsoft-phobia as irrelevant brand preference. C# was made as the Microsoft language you use when you want to work with predominantly Microsoft technologies. If people are trying to stay out of that all-Microsoft, Microsoft-everywhere space, it follows logically that they avoid C#. Also, there are plenty of options for a more platform agnostic mix & match Java++ language.

Mono's main mission seems to be championing Microsoft technologies and standards with product innovation and quality serving as a means to that end. So for people who are resistant to that style of Microsoft fanaticism and want to avoid an all-Microsoft, Microsoft-everywhere, avoid Mono is logical.

Oracle may or may not be "nice", I don't feel qualified to make that judgement, but I feel that I can use Java and work within the JVM ecosystem and still retain a high level of technology freedom and autonomy. The JVM ecosystem has a very decentralized nature. It's the norm to use a dozen different JVM technologies in a single tool stack that are each developed by completely unrelated people who don't work for any common organization.

The Microsoft tool ecosystem is completely centralized and all-Microsoft and that's precisely what the Microsoft dev community loves: it's simpler, there is less to learn, there is less time wasted debating about infrastructure, infrastructure integration is more polished, and technical staff is more standardized and interchangeable. Lots of companies adopt all-Microsoft approaches: you can use whatever technology, OS, IDE, programming language, database, and web framework that you want as long as it's Microsoft. And if that's what makes them happy, that's great for them. But I understand those that find that all-Microsoft, Microsoft-everywhere strategy oppressive and resent it.

Something like Python, may be a dictatorship, but it isn't tied to this giant ecosystem of everything Python. You can mix/match Python with whatever other technologies you prefer, so there is generally little resentment towards it.

Additionally, I relistened to the Mono discussion, and it didn't seem emotionally charged at all or heavy handed or unreasonable in the slightest.

"If we have learned anything from Java, it is that a cross-platform UI toolkit just doesn't cut it - it will always be the hunt for the lowest common denominator, which is low enough to make crap on all platform"

Tor was saying this. I really think it depends on the app. For some apps, I absolutely agree. For example, for the typical photo-sharing app, the advantage of being written directly to the platform's native GUI system is important. For something like IntelliJ, I think a cross platform GUI like Swing is best. I can't imagine the IntelliJ guys building separate Mac/Cocoa, Windows/WPF, and Linux/GTK versions. The thought is ridiculous. Also, some apps work better on cross platform HTML/JS.

Casper, why don't you just get an all-Microsoft job? I can understand the bitter Scala or Haskell enthusiast because it's rare to find an employer who will pay for that type of work, but Microsoft technologies dominate the traditional paid job space.

[Casper Bang]

C# was never meant as a platform agnostic language that competed on its merit and could be mixed and matched into any tool chain. So you shouldn't expect people to judge it as such and dismiss Microsoft-phobia as irrelevant brand preference. C# was made as the Microsoft language you use when you want to work with predominantly Microsoft technologies. If people are trying to stay out of that all-Microsoft, Microsoft-everywhere space, it follows logically that they avoid C#. Also, there are plenty of options for a more platform agnostic mix & match Java++ language.

Yes, that's the world view some seems determined to paint. However, the truth is that nothing in the Ecma specs contain anything Microsoft/Windows specific. Ignoring for a moment who's behind the standard, C# is for all practical purposes, a super-set of Java catering to that same developer group. It then seems silly to have giant discussions about the demise of legacy Java (no closures, no extension methods, no decimal literal etc.) and a next gen Java like Scala (which seems to attract the top 20% while scaring the remaining 80%).

 

Oracle may or may not be "nice", I don't feel qualified to make that judgement, but I feel that I can use Java and work within the JVM ecosystem and still retain a high level of technology freedom and autonomy. The JVM ecosystem has a very decentralized nature. It's the norm to use a dozen different JVM technologies in a single tool stack that are each developed by completely unrelated people who don't work for any common organization.

Yes, which is the cause of many interoperability problems across the stack and leads to the paradox of choice [http://www.youtube.com/watch?v=VO6XEQIsCoM]. Choice is good, but too much choice is bad as it shifts the focus from the problem to the tools.

The Microsoft tool ecosystem is completely centralized and all-Microsoft and that's precisely what the Microsoft dev community loves: it's simpler, there is less to learn, there is less time wasted debating about infrastructure, infrastructure integration is more polished, and technical staff is more standardized and interchangeable. Lots of companies adopt all-Microsoft approaches: you can use whatever technology, OS, IDE, programming language, database, and web framework that you want as long as it's Microsoft. And if that's what makes them happy, that's great for them. But I understand those that find that all-Microsoft, Microsoft-everywhere strategy oppressive and resent it.

But dude, I am not talking about all-Microsoft anything, *you* are - hell I run Linux all over, even on my Macbook Air, so whenever I need Windows I simply log on to the corporate Citrix solution. I simply started this thread purely because Dick kept extrapolating to the point of non-sense, which doesn't suit him.

 

Casper, why don't you just get an all-Microsoft job? I can understand the bitter Scala or Haskell enthusiast because it's rare to find an employer who will pay for that type of work, but Microsoft technologies dominate the traditional paid job space.

Because I don't pretend to live in a black or white world. Sure, it would be easier (take your pick between "Java sucks" or ".NET sucks"), but call me crazy, I'd just like to see the full spectrum out there - and my manager expect no less, since few products/services lives in total isolation.

[clay]

On Tuesday, June 19, 2012 4:45:07 PM UTC-5, Casper Bang wrote:

Yes, that's the world view some seems determined to paint. However, the truth is that nothing in the Ecma specs contain anything Microsoft/Windows specific. Ignoring for a moment who's behind the standard, C# is for all practical purposes, a super-set of Java catering to that same developer group.

As a language syntax, Java and C# are extremely similar, the practical benefits between them are small, and in the cases where I do want something more expressive and elegant, I would still prefer Scala, Haskell, F#, or even Kotlin. Who cares about the ECMA spec and the legal rights it affords, when there are better languages readily available without any legal obstacles to their usage? Secondly, language syntax is usually not the primary concern.

I also disagree that C# and Java cater to the same type of developer. The C# developer has more in common with a PHP developer in terms of a very practical, business value driven mindset, while the Java developers often have a more academic, theoretical, research mindset.

Because I don't pretend to live in a black or white world. Sure, it would be easier (take your pick between "Java sucks" or ".NET sucks"), but call me crazy, I'd just like to see the full spectrum out there - and my manager expect no less, since few products/services lives in total isolation.

I'm just saying, do what you want. Get the job that fulfills your passion. You consistently bring up C#, Mono, and Microsoft related technologies. That seems to be your interest and you should chase that.

For me, I consistently find awesome things coming out of the JVM ecosystem. A few years back it was Hadoop and NoSQL and Maven. Today it's Gradle and the Scala ecosystem. But, honestly, most new learning I am excited about isn't related to the JVM or .NET.

[Fabrizio Giudici]

On Tue, 19 Jun 2012 08:46:49 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> On Mon, Jun 18, 2012 at 11:43 PM, Casper Bang <caspe...@gmail.com>
> wrote:
>
>> That's a decent explanation, except that it's not called "verify" but
>> "prepare" and it pollutes /trunk when fails (POM has been modified and
>> temp
>> files created) requiring manual cleanup.
>
>

Sorry for the late response...

> Couldn't agree more. I tried to convince Jason and the whole crew many
> times that it's a bad idea but I failed.
>
> I can't count the number of times that my release process failed for some
> reason (bad connection, stash needed, etc...) and I found myself forced
> to
> increment my product version just to please Maven. Very irritating.
>

... because you don'k know the release plugin. With a bit of configuration
and Git or Mercurial it doesn't pollute *anything*. My standard releases
are totally performed on the local disk in an atomic fashion (both the
pushes to Git/Mercurial and the deployment of artifacts). Only at the end,
when everything went fine, the stuff get published. If there has been an
error, nothing goes out of my computer (and can be thrown away, then a fix
is applied and the release is retried).

With subversion, unfortunately, it's impossible to prevent a commit from
going out immediately, and this happens during the process. But - apart
from the fact that Subversion is an old fashion to do things - mvn
release:rollback resets everything as it were before the release, with a
compensating commit. No version number is lost. Because of a bug, you only
have to manually delete the tag.

[Ricky Clarkson]

How do you have your release plugin/scm plugin configured, Fabrizio,
for that to work from git? I saw that various things had changed to
make that possible due to a number of complaints but haven't tried
them out.

Also, does that work for you from Windows? And if so, from paths with
spaces in them?

> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.

[Cédric Beust ♔]

On Wed, Jun 20, 2012 at 2:11 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

How do you have your release plugin/scm plugin configured, Fabrizio,
for that to work from git?  I saw that various things had changed to
make that possible due to a number of complaints but haven't tried
them out.

I'm curious to hear the details as well.

Here is a very simple situation where I end up having to bump my project version because the release plug-in has already created a tag and then fails to push: start a release with files modified but not added to the index.

-- 

Cédric

[Fabrizio Giudici]

On Wed, 20 Jun 2012 23:11:04 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> How do you have your release plugin/scm plugin configured, Fabrizio,
> for that to work from git? I saw that various things had changed to
> make that possible due to a number of complaints but haven't tried
> them out.
>
> Also, does that work for you from Windows? And if so, from paths with
> spaces in them?

My setup has been tested extensively with Mercurial on Linux boxes and
(recently) with Subversion with both Linux and Windows boxes. I've also
gave it to a customer who's using Git, who has necessarily applied some
patch, but I've never assisted to a release by him so far. So I can't
speak for Git at the moment, but given the similarity with Mercurial I
don't see any issue.

As I said, with Subversion I can't avoid having some intermediate commits
in the middle. All the setup is coded in my superpom and all of my
projects use it. Everything can be found e.g. here:

http://hudson.tidalwave.it/hudson/job/TheseFoolishThings_Release/

(sources are in the workspace, or you can follow the bitbucket URL; the
job configuration, which should be publicly readable, contains the
sequence of operations to perform the release). The latest version of the
superpom, which contains the Windows fixes, hasn't been used for a late
release of this specific project, so I believe that if Murphy is around
something could break. But I need just the time to relax a bit (I've been
travelling as a shuttle recently) and retry everything.

For the record, the Hudson job has a parameter: "release commit" if you
want to really make a release, or "release cancel" which just tries
everything and then throws away the results. Usually releases go ok, but
when I feel I've made some risky changes I run a "release cancel" so I can
anticipate any problem and save time.

The basic trick is simple: in the release profile, two settings override
1) the URL of the SCM repo, pointing to a local repo created under target,
so when Maven pushes it pushes to it; and 2) the URL of the target Maven
repo, which againt points to a local directory. At the very end, a third
Maven run is performed which pushes the locally created SCM repo to the
remote and copies the artifacts to the remote repository. This has been
blogged about quite a time ago, but I can't recall the URL.

Note that the whole stuff can be simplified, for instance there are
multiple invocations of the antrun plugin to create directories and
initialize the local Mercurial repo. It could be probably done with the
gmaven plugin in Groovy and less lines of code, plus it would easily fit a
conditional for creating instead a Git repo. Also, I developed it a few
years ago and at the time I had to work around a bug in the Mercurial
support from the release plugin, which I believe that in the meantime has
been fixed; probably the trickery about pushing to a local repository
could be dropped today. I've planned to review it sooner or later, but as
far as it's working I don't feel urged to.





For what concerns spaces in paths, I've been bitten so hard in the past
that I'm not considering any more the option of having spaces in a
directory where there's some Java source or code (the problems typically
happen with Windows). That's truly a Java failure, or Windows, or both -
or my faulty understanding of how to quote paths. But it's a minor issue,
really.

[Cédric Beust ♔]

On Wed, Jun 20, 2012 at 2:50 PM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

So I can't speak for Git at the moment

Well, that explains it :-)

-- 

Cédric

[Ricky Clarkson]

True but the release profile specifying an alternative scm location is a good idea.

Spaces in paths crop up much less often for people using Windows > XP, but people still make that mistake.

Fabrizio, thanks for the ideas!  That indirectly helps me with a different problem that needs solving.

[Mark Derricutt]

In my own git based projects:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<!--<preparationGoals>clean verify
youtrack:update-version youtrack:merge-changes
changes:announcement-mail</preparationGoals>-->
<preparationGoals>clean install</preparationGoals>
<autoVersionSubmodules>true</autoVersionSubmodules>
<goals>deploy</goals>
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
</configuration>
</plugin>

Here I configured that the release plugin should NOT push changes during
release ( I don't want my release branches escaping to the remote
repository ), and to use local checkout/clone from the local repository.

There -was- a bug in the last release plugin that under certain crashes
it wasn't cleaning up release.properties properly which has since been
fixed.

One main issue to be aware of with git ( and I assume mercurial ) is
that you HAVE to release from the root of your repository, which pushes
you to a single module/artifact per repository.

[Fabrizio Giudici]

On Thu, 21 Jun 2012 03:24:01 +0200, Mark Derricutt <ma...@talios.com> wrote:

> One main issue to be aware of with git ( and I assume mercurial ) is
> that you HAVE to release from the root of your repository, which pushes
> you to a single module/artifact per repository.

I assume this is not a SCM problem, rather a release-plugin constraints: I
define this saying that a master pom defines the "atomicity" of a release
(my rules are a repo root for each master pom). This doesn't mean you need
to put only a single module instead. This means that you need to release
all of the underlying modules at the same time. Which often makes sense by
design reasons (e.g. the modules are cohese, etc...). So it all boils down
to breaking the project into sub-project partitions, each one with a
master pom and a repo root, in an appropriate way.

[Mark Derricutt]

On 21/06/12 6:50 PM, Fabrizio Giudici wrote:
> On Thu, 21 Jun 2012 03:24:01 +0200, Mark Derricutt <ma...@talios.com>
> wrote:
>
>> One main issue to be aware of with git ( and I assume mercurial ) is
>> that you HAVE to release from the root of your repository, which
>> pushes you to a single module/artifact per repository.
>
> I assume this is not a SCM problem, rather a release-plugin
> constraints: I define this saying that a master pom defines the
> "atomicity" of a release (my rules are a repo root for each master
> pom). This doesn't mean you need to put only a single module instead.
> This means that you need to release all of the underlying modules at
> the same time. Which often makes sense by design reasons (e.g. the
> modules are cohese, etc...). So it all boils down to breaking the
> project into sub-project partitions, each one with a master pom and a
> repo root, in an appropriate way.
>

It's a combination - a big part that is definitely git/mercurial based
is that unlike subversion - git tags/branches are repository wide rather
than at a directory level. If you have n projects in a repository and
you want to work on different branches of each project, then you need to
make SEPARATE checkouts of the entire repository.

[RobZ]

I just listened to #390.

I love the show, been listening for years and years. You even read one of my emails once.

But dear god you start to sound like babbling idiots when you talk about Microsoft. You don't know what you're talking about and it is deeply embarrassing. Please just avoid the topic!

Thank you!

[Casper Bang]

I just listened to #390.

I love the show, been listening for years and years. You even read one of my emails once.

But dear god you start to sound like babbling idiots when you talk about Microsoft. You don't know what you're talking about and it is deeply embarrassing. Please just avoid the topic!

I just listened to #390 as well, and what surprises me is that, rather than trying to go back to what was actually said ("I haven't been back to listen to it") and correct some of this, Dick tries to redefine it while arguing the critique was taken out of context (by definition, his very own context from #386)?! Carl and Tor actually has some lucid and valid arguments and as I've said before, it's *fine* to be critical at Microsoft and related technologies - but don't cook up a fake reality as if you're some republican congressman from Missouri - makes you look really dumb.

Rather than subjective gut feelings and make-belief conspiracies, ask yourself the following questions:

Why did Microsoft cook up Silverlight?

[As Carl says, to have a horse in the RIA race that nobody knew the importance of at the time.]

Can you consume JavaFX/WebStart RIA stuff on a fresh Ubuntu install? 

[Not without first installing the IcedTea Java plugin from the community much like one has to install the Moonlight plugin for Silverlight.]

Why did NetFlix go with Silverlight rather than Java/Flash for their 25 mio. subscribers?

[Because Linux is a minority, and both the JRE and Flash lacks codecs and DRM support.]

Why is Microsoft now abandoning Silverlight?

[Much like Oracle is abandoning JavaFX and Adobe is abandoning Flash, the general consensus is that the future is HTML5 and MPEG DASH.]

Why is Moonlight being abandoned?

[It would be pretty dumb for the Mono community to invest more of their previous resources in Moonlight, when Microsoft is abandoning Silverlight.]

Perhaps a bit boring compared to the soap-opera hodgepodge in the podcast, but I'd argue, more accurate.

[Russel Winder]

On Tue, 2012-08-21 at 02:53 -0700, Casper Bang wrote:
[…]

> [Much like Oracle is abandoning JavaFX and Adobe is abandoning Flash, the

So Oracle putting JavaFX2 into the standard JavaSE distribution is
abandoning it?

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Hayden Jones]

I too balked when I saw Caspar's comment.  Being generous I thought he probably meant using JavaFX as a mobile solution.  (I guess we'll see what happens with Project Avatar)

On Tuesday, August 21, 2012 2:03:15 PM UTC-4, Russel wrote:

On Tue, 2012-08-21 at 02:53 -0700, Casper Bang wrote:
[…]
> [Much like Oracle is abandoning JavaFX and Adobe is abandoning Flash, the

So Oracle putting JavaFX2 into the standard JavaSE distribution is
abandoning it?

--
Russel.
=============================================================================

Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russ...@ekiga.net

[Casper Bang]

So Oracle putting JavaFX2 into the standard JavaSE distribution is
abandoning it?

That should've been JavaFX Script - the RIA platform Sun/Oracle launched in 2007 to compete with Flex and Silverlight. I sometimes mix the two (as do many) due to their glorious naming scheme.

[Russel Winder]

Works for me :-)

Tying JavaFX to a specific (functional) programming language did seem
wrong. Having JavaFX2 as an API seems very much a more sane idea. It
enables GroovyFX, which is (of course) serriously cool.

[Reinier Zwitserloot]

The fact that microsoft is willing to abandon silverlight so soon does indeed have a mundane and reasonable explanation: They wanted a horse in the RIA race 'just incase'.

But this is where it falls down:

They didn't say that. They sold it like it was the greatest thing since elvis. Which is fine, I guess, I mean, it's a business marketing its own product, what else would we expect?

Still, clearly it is very smart for me to abhor anything microsoft builds, especially if it is not _usefully_ open (with 'usefully' defined as: You can get your support and library needs from all over, and the odds of being incapable of finding a thing that is compatible with everything you build in the future is large). They will just plain drop whatever the heck they please, with nary a thought for all those poor shops that are now stuck having expended all this research and training on a product that is now basically DOA.

Is Microsoft the only company that does this? Heck no, so many do. But microsoft does it too, and that's the important part.

NB: I don't advise people to go with JavaFX either. HTML. Been saying it for years.