Example Projects for turnkey Scala IDE setup? (aka. for dummies)

On Thu, Apr 23, 2009 at 3:05 AM, Aldo Bucchi <aldo.bucchi@gmail.com> wrote:

Hi,

For a week I've been trying different setups to get a sufficiently
stable Scala IDE for a relatively big project.

FWIW, I find that IntelliJ's Scala and Maven support are as easy as checking a few checkboxes and things work.  Is IntelliJ an option for you?  I have not had a failure setting up IntelliJ 8 to run Scala and I've done it on 6 different machines with Linux, Windows and Mac OS X.  I have had issues with IntelliJ running on Linux, but that's a global issue (e.g., it fails to allow me to open Java code, too) and nothing to do with Scala... once IntelliJ runs, it works fine with Scala, too.
 

Partial luck so far. (
inconsistent is a better word ). What I have managed to do with great
success though, is to scan through tons of discussions, posts,
comments, etc about this very same issue.

And I've noticed that this scares some people away.

I know building tools for this is really, really hard. And I also
suppose that things are actually quite better than what I have managed
to produce for me and my team. But truth is I am growing a bit nervous
as overall productivity is not good at all.
So, here's a pragmatic idea.

Could someone create a repository of ready to use common project
layouts + settings?

The rationale is this: Most developers will fit in one or two
profiles. For example, this is a very common profile.
* Maven
* Eclipse 3.4/5
* SVN
* Java + Scala mixed sources
* Scala 2.7.4.RC1

That could be boiled down to a .classpath, .project, skeleton.

In our case we have something different but we could adapt/rearrange
our setup to fit this "common" usecase. It would certainly cost less
than the trial and error phase we've been going through. Now, for
those in need of something more specific, then we can assume that they
will have the time and/or expertise to adventure into the wild.

80/20.

I have tried the Scala IDE for Eclipse plugin in at least 10 different
setups, for example, and I have not yet found the perfect one (
although I really like it! ). Perhaps I am being too demanding, but I
would like to be assured that I am effectively seeing the "cutting
edge" and let go that feeling that I might still be missing a tweak.

I think Scala is great but I have heard the same comments over and over.

BTW. We also tried IDEA and Netbeans. Different versions, different
setups, different machines. Results are amazingly inconsistent. I
understand there are many collateral settings in all these IDEs that
make it really hard to figure out what went wrong. Therefore, I
strongly believe that isolating these ( natural ) errors so they can
at least be more manageable and predictable would really help
(commercial/massive) early adopters.

What do you think?

Thanks,
A




--
Aldo Bucchi
U N I V R Z
Office: +56 2 795 4532
Mobile:+56 9 7623 8653
skype:aldo.bucchi
http://www.univrz.com/
http://aldobucchi.com/

PRIVILEGED AND CONFIDENTIAL INFORMATION
This message is only for the use of the individual or entity to which it is
addressed and may contain information that is privileged and confidential. If
you are not the intended recipient, please do not distribute or copy this
communication, by e-mail or otherwise. Instead, please notify us immediately by
return e-mail.
INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL
Este mensaje está destinado sólo a la persona u organización al cual está
dirigido y podría contener información privilegiada y confidencial. Si usted no
es el destinatario, por favor no distribuya ni copie esta comunicación, por
email o por otra vía. Por el contrario, por favor notifíquenos inmediatamente
vía e-mail.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Who's your audience? Is it Eclipse users possibly adopting Scala,
or Scala users possibly adopting Eclipse?

I think it is easier to start with Eclipse, and add Scala, than it is
to start with Scala (especially, a non-trivial mixed Scala/Java project)
and add Eclipse, mostly because it can be tedious to map a project's
directory structure and build process into Eclipse (or into NetBeans).
I've done it several times myself, each project is different in its
own screwy way.

On 2009-04-23, at 6:05 AM, Aldo Bucchi wrote:
> Could someone create a repository of ready to use common project
> layouts + settings?

We're in a similar situation, in that we would like for our project
(projectfortress) to work "out of the box" with at least Eclipse and
NetBeans. Some of us use Eclipse often, some occasionally. We want
anyone who uses Eclipse or NetBeans, who wants to play with our stuff,
to have an easy test-drive (or at least as easy as can be managed).

Currently, our Scala/Eclipse integration is broken, but we're working
on it.

In practice, this is hard:

- It requires a dedicated user of the IDE to keep using the project,
and to keep up-to-date with plugin changes. In our case, that means
that whatever IDEs we work well with, have to have someone using them
often. In your case, of building the plug-and-play system, that means
you need to keep track of the plugins.

- We haven't figured out how to lick the plugins problem. Whoever does
this, still has to go get the plugins and install them, and (I think)
this changes slightly from Eclipse version to Eclipse version. In
particular, in the latest version (3.5) of Eclipse it looks like the
plugins like to be installed one at a time, with Eclipse recommending
a restart each time (there seems to be a new method for doing this,
because I recall previously adding a bunch of plugins in one step, then
restarting). This is a bunch of tedious steps that get in the way of
actually using the IDE.

Is it possible for Eclipse to work with its plugins checked into a
repository, instead of "installed" in Eclipse proper? (I'm a many-years
multi-platform Eclipse user, but I have not explored all of its twisty
passages.)

- How about non-IDE users? I don't know enough about Maven (I know it
is supposed to deal with versions of this and that), but one problem
we have run into is the "command line" side of the build using their
copies of the jar files, and the Eclipse side of the build using their
copies of the plugins, and there being notable differences between the
two. The non-IDE guys will do stuff that causes problems for Eclipse
(e.g., adding tools, upgrading tools, adding multiple build.xml files)
and other IDEs.

I think this is again "can Eclipse run against plugins checked into
a repository?", because if you could get that right, and if the plugins
contained the bits necessary for command line use (the one time that I
looked, they did, though the jar files had funny names), then things
would work ok, at least until the non-IDE users went and installed a
non-plugin version of the jar on top of it. (If "eclipse compatibility"
is not part of your unit tests, this can happen.)

- Plugins can be surprisingly brittle. For example, We use ASM, we
like it very much, but with Eclipse 3.4+, you have to go to one site
to get the basic ASM tools, and to another site to get the compatible
version of Bytecode outliner. You might be tempted to think you could
get them all at the ASM site, but (for whatever reason) that doesn't
work (at least, it didn't work earlier this week).

- We've run into one particular, annoying problem, that is Scala-
related.
Scalac can make unusual demands on a VM, so the heap and stack sizes
need to be bigger, and neither ant nor Eclipse makes it especially
easy to deal with this for a new or casual user, especially not in a
way that you can check in to a repository in a platform-independent way.
Eclipse requires editing of a file buried in its "application" (how this
looks is platform-specific). Ant can be tweaked by setting environment
variables, but those are not always re-set for you when it is run within
an IDE (or rather, you may need to set them a second time within the
IDE).
The Eclipse editing is "bad" because if you do it wrong, you can make
Eclipse be un-startable.

- As a Sun employee, I think I'm supposed to say "hey, what about
NetBeans",
but as an Eclipse addict who has been unable to break the habit, I can
understand only dealing with one IDE, and choosing the one that you like
best.

On the plus side, we did get it down to one page of instructions, it's
just
that each step requires a bunch of mousing around and waiting. This
is the
sort of thing where it would really be much nicer to have it all be do-
able
from the command line, so that someone who was interested could just
swipe
some text, copy, paste in a shell window, and go get coffee.

> The rationale is this: Most developers will fit in one or two
> profiles. For example, this is a very common profile.
> * Maven
> * Eclipse 3.4/5
> * SVN
> * Java + Scala mixed sources
> * Scala 2.7.4.RC1
>
> That could be boiled down to a .classpath, .project, skeleton.
>
> BTW. We also tried IDEA and Netbeans. Different versions, different
> setups, different machines. Results are amazingly inconsistent. I
> understand there are many collateral settings in all these IDEs that
> make it really hard to figure out what went wrong.

On Thu, Apr 23, 2009 at 11:05 AM, Aldo Bucchi wrote:
> The rationale is this: Most developers will fit in one or two
> profiles. For example, this is a very common profile.
> * Maven
> * Eclipse 3.4/5
> * SVN
> * Java + Scala mixed sources
> * Scala 2.7.4.RC1
>
> That could be boiled down to a .classpath, .project, skeleton.

With the exception of Maven, this setup should work out of the box
without any need for templates of any sort.

Maven, apparently, does all kinds of bad things with Eclipse's
internal metadata. You might find this thread, especially the comments
from Josh Suereth, helpful,

http://groups.google.com/group/liftweb/browse_thread/thread/3dac7002f9e5...

I'd appreciate it if people would direct their venting at the
developers of the maven-eclipse-plugin because it seems that it's at
the root of a lot of the issues that people have been having with the
Scala IDE for Eclipse in general, and Lift developement in particular.

Cheers,

Miles

Hi David,

On Thu, Apr 23, 2009 at 9:00 AM, David Pollak
wrote:
>
>
> On Thu, Apr 23, 2009 at 3:05 AM, Aldo Bucchi wrote:
>>
>> Hi,
>>
>> For a week I've been trying different setups to get a sufficiently
>> stable Scala IDE for a relatively big project.
>
> FWIW, I find that IntelliJ's Scala and Maven support are as easy as checking
> a few checkboxes and things work.  Is IntelliJ an option for you?  I have
> not had a failure setting up IntelliJ 8 to run Scala and I've done it on 6
> different machines with Linux, Windows and Mac OS X.  I have had issues with
> IntelliJ running on Linux, but that's a global issue (e.g., it fails to
> allow me to open Java code, too) and nothing to do with Scala... once
> IntelliJ runs, it works fine with Scala, too.

For our devs it is an option, albeit not for all.
IntelliJ has a tradition of quickly jumping in with a solid offer. I
suppose this is a strategy to gain market. For example, I moved to
Intellij recently due to it providing early JavaFX support. So they
effectively gained a new customer because of this.

I agree with you here. It is probably the safest bet. But it has a price ;)
The "it just works" feature is the scarce resource at this point.

However, for the rest of my team ( and customer's developers ) I
*need* to find a free alternative as fallback.

Regards,
A

>
>>
>> Partial luck so far. (
>> inconsistent is a better word ). What I have managed to do with great
>> success though, is to scan through tons of discussions, posts,
>> comments, etc about this very same issue.
>>
>> And I've noticed that this scares some people away.
>>
>> I know building tools for this is really, really hard. And I also
>> suppose that things are actually quite better than what I have managed
>> to produce for me and my team. But truth is I am growing a bit nervous
>> as overall productivity is not good at all.
>> So, here's a pragmatic idea.
>>
>> Could someone create a repository of ready to use common project
>> layouts + settings?
>>
>> The rationale is this: Most developers will fit in one or two
>> profiles. For example, this is a very common profile.
>> * Maven
>> * Eclipse 3.4/5
>> * SVN
>> * Java + Scala mixed sources
>> * Scala 2.7.4.RC1
>>
>> That could be boiled down to a .classpath, .project, skeleton.
>>
>> In our case we have something different but we could adapt/rearrange
>> our setup to fit this "common" usecase. It would certainly cost less
>> than the trial and error phase we've been going through. Now, for
>> those in need of something more specific, then we can assume that they
>> will have the time and/or expertise to adventure into the wild.
>>
>> 80/20.
>>
>> I have tried the Scala IDE for Eclipse plugin in at least 10 different
>> setups, for example, and I have not yet found the perfect one (
>> although I really like it! ). Perhaps I am being too demanding, but I
>> would like to be assured that I am effectively seeing the "cutting
>> edge" and let go that feeling that I might still be missing a tweak.
>>
>> I think Scala is great but I have heard the same comments over and over.
>>
>> BTW. We also tried IDEA and Netbeans. Different versions, different
>> setups, different machines. Results are amazingly inconsistent. I
>> understand there are many collateral settings in all these IDEs that
>> make it really hard to figure out what went wrong. Therefore, I
>> strongly believe that isolating these ( natural ) errors so they can
>> at least be more manageable and predictable would really help
>> (commercial/massive) early adopters.
>>
>> What do you think?
>>
>> Thanks,
>> A
>>
>>
>>
>>
>> --
>> Aldo Bucchi
>> U N I V R Z
>> Office: +56 2 795 4532
>> Mobile:+56 9 7623 8653
>> skype:aldo.bucchi
>> http://www.univrz.com/
>> http://aldobucchi.com/
>>
>> PRIVILEGED AND CONFIDENTIAL INFORMATION
>> This message is only for the use of the individual or entity to which it
>> is
>> addressed and may contain information that is privileged and confidential.
>> If
>> you are not the intended recipient, please do not distribute or copy this
>> communication, by e-mail or otherwise. Instead, please notify us
>> immediately by
>> return e-mail.
>> INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL
>> Este mensaje está destinado sólo a la persona u organización al cual está
>> dirigido y podría contener información privilegiada y confidencial. Si
>> usted no
>> es el destinatario, por favor no distribuya ni copie esta comunicación,
>> por
>> email o por otra vía. Por el contrario, por favor notifíquenos
>> inmediatamente
>> vía e-mail.
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>

On Thu, Apr 23, 2009 at 1:16 PM, Aldo Bucchi <aldo.bucchi@gmail.com> wrote:

Hi David,

On Thu, Apr 23, 2009 at 9:00 AM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
>
>
> On Thu, Apr 23, 2009 at 3:05 AM, Aldo Bucchi <aldo.bucchi@gmail.com> wrote:
>>
>> Hi,
>>
>> For a week I've been trying different setups to get a sufficiently
>> stable Scala IDE for a relatively big project.
>
> FWIW, I find that IntelliJ's Scala and Maven support are as easy as checking
> a few checkboxes and things work.  Is IntelliJ an option for you?  I have
> not had a failure setting up IntelliJ 8 to run Scala and I've done it on 6
> different machines with Linux, Windows and Mac OS X.  I have had issues with
> IntelliJ running on Linux, but that's a global issue (e.g., it fails to
> allow me to open Java code, too) and nothing to do with Scala... once
> IntelliJ runs, it works fine with Scala, too.

For our devs it is an option, albeit not for all.
IntelliJ has a tradition of quickly jumping in with a solid offer. I
suppose this is a strategy to gain market. For example, I moved to
Intellij recently due to it providing early JavaFX support. So they
effectively gained a new customer because of this.

I agree with you here. It is probably the safest bet. But it has a price ;)
The "it just works" feature is the scarce resource at this point.

However, for the rest of my team ( and customer's developers ) I
*need* to find a free alternative as fallback.

The cost of setting up NetBeans is a bit higher... you have to download the Scala plugin from source forge (although you could put it in a known location on your network.)

My experience with NetBeans has been very, very positive.  It's my primary IDE, although I use IntelliJ and Eclipse for at least one day a month to "get the flavor" of those IDEs.  So, the NetBeans setup cost is about 15 minutes more than IntelliJ.  The overall NetBeans offering is very good.

I expect that I will spend more time in Eclipse once 2.7.4 is out and Lift moves to 2.7.4.  The major blocker for me and Eclipse was the differences in Scala versions.
 

Regards,
A

>
>>
>> Partial luck so far. (
>> inconsistent is a better word ). What I have managed to do with great
>> success though, is to scan through tons of discussions, posts,
>> comments, etc about this very same issue.
>>
>> And I've noticed that this scares some people away.
>>
>> I know building tools for this is really, really hard. And I also
>> suppose that things are actually quite better than what I have managed
>> to produce for me and my team. But truth is I am growing a bit nervous
>> as overall productivity is not good at all.
>> So, here's a pragmatic idea.
>>
>> Could someone create a repository of ready to use common project
>> layouts + settings?
>>
>> The rationale is this: Most developers will fit in one or two
>> profiles. For example, this is a very common profile.
>> * Maven
>> * Eclipse 3.4/5
>> * SVN
>> * Java + Scala mixed sources
>> * Scala 2.7.4.RC1
>>
>> That could be boiled down to a .classpath, .project, skeleton.
>>
>> In our case we have something different but we could adapt/rearrange
>> our setup to fit this "common" usecase. It would certainly cost less
>> than the trial and error phase we've been going through. Now, for
>> those in need of something more specific, then we can assume that they
>> will have the time and/or expertise to adventure into the wild.
>>
>> 80/20.
>>
>> I have tried the Scala IDE for Eclipse plugin in at least 10 different
>> setups, for example, and I have not yet found the perfect one (
>> although I really like it! ). Perhaps I am being too demanding, but I
>> would like to be assured that I am effectively seeing the "cutting
>> edge" and let go that feeling that I might still be missing a tweak.
>>
>> I think Scala is great but I have heard the same comments over and over.
>>
>> BTW. We also tried IDEA and Netbeans. Different versions, different
>> setups, different machines. Results are amazingly inconsistent. I
>> understand there are many collateral settings in all these IDEs that
>> make it really hard to figure out what went wrong. Therefore, I
>> strongly believe that isolating these ( natural ) errors so they can
>> at least be more manageable and predictable would really help
>> (commercial/massive) early adopters.
>>
>> What do you think?
>>
>> Thanks,
>> A
>>
>>
>>
>>
>> --
>> Aldo Bucchi
>> U N I V R Z
>> Office: +56 2 795 4532
>> Mobile:+56 9 7623 8653
>> skype:aldo.bucchi
>> http://www.univrz.com/
>> http://aldobucchi.com/
>>
>> PRIVILEGED AND CONFIDENTIAL INFORMATION
>> This message is only for the use of the individual or entity to which it
>> is
>> addressed and may contain information that is privileged and confidential.
>> If
>> you are not the intended recipient, please do not distribute or copy this
>> communication, by e-mail or otherwise. Instead, please notify us
>> immediately by
>> return e-mail.
>> INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL
>> Este mensaje está destinado sólo a la persona u organización al cual está
>> dirigido y podría contener información privilegiada y confidencial. Si
>> usted no
>> es el destinatario, por favor no distribuya ni copie esta comunicación,
>> por
>> email o por otra vía. Por el contrario, por favor notifíquenos
>> inmediatamente
>> vía e-mail.
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>



--
Aldo Bucchi
U N I V R Z
Office: +56 2 795 4532
Mobile:+56 9 7623 8653
skype:aldo.bucchi
http://www.univrz.com/
http://aldobucchi.com/

PRIVILEGED AND CONFIDENTIAL INFORMATION
This message is only for the use of the individual or entity to which it is
addressed and may contain information that is privileged and confidential. If
you are not the intended recipient, please do not distribute or copy this
communication, by e-mail or otherwise. Instead, please notify us immediately by
return e-mail.
INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL
Este mensaje está destinado sólo a la persona u organización al cual está
dirigido y podría contener información privilegiada y confidencial. Si usted no
es el destinatario, por favor no distribuya ni copie esta comunicación, por
email o por otra vía. Por el contrario, por favor notifíquenos inmediatamente
vía e-mail.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Hi David ( Chase ),

On Thu, Apr 23, 2009 at 9:17 AM, David Chase wrote:
>
> Who's your audience?  Is it Eclipse users possibly adopting Scala,
> or Scala users possibly adopting Eclipse?

Very good question!
Definitely "Java/Eclipse users moving to Scala".
And the profile I outlined before is what I see more often in
customer's (R&D) teams: Java1.6 + Maven + Eclipse 3.4/5

As you say, having an IDE is crucial because it is a very good way to
learn the language by exploration.

>
> I think it is easier to start with Eclipse, and add Scala, than it is
> to start with Scala (especially, a non-trivial mixed Scala/Java project)
> and add Eclipse, mostly because it can be tedious to map a project's
> directory structure and build process into Eclipse (or into NetBeans).
> I've done it several times myself, each project is different in its
> own screwy way.

Yes, but if you do it once for a whole team, the cost is marginal. The
point is that, for management reasons, you need to "know" what the
outcome will be.
So far Maven seems to introduce all sorts of surprises ( as Miles
notes below ) .

>
> On 2009-04-23, at 6:05 AM, Aldo Bucchi wrote:
>>
>> Could someone create a repository of ready to use common project
>> layouts + settings?
>
> We're in a similar situation, in that we would like for our project
> (projectfortress) to work "out of the box" with at least Eclipse and
> NetBeans.  Some of us use Eclipse often, some occasionally.  We want
> anyone who uses Eclipse or NetBeans, who wants to play with our stuff,
> to have an easy test-drive (or at least as easy as can be managed).
>
> Currently, our Scala/Eclipse integration is broken, but we're working
> on it.
>
>
> In practice, this is hard:
>
> - It requires a dedicated user of the IDE to keep using the project,
> and to keep up-to-date with plugin changes.  In our case, that means
> that whatever IDEs we work well with, have to have someone using them
> often.  In your case, of building the plug-and-play system, that means
> you need to keep track of the plugins.
>
>
> - We haven't figured out how to lick the plugins problem.  Whoever does
> this, still has to go get the plugins and install them, and (I think)
> this changes slightly from Eclipse version to Eclipse version.  In
> particular, in the latest version (3.5) of Eclipse it looks like the
> plugins like to be installed one at a time, with Eclipse recommending
> a restart each time (there seems to be a new method for doing this,
> because I recall previously adding a bunch of plugins in one step, then
> restarting).  This is a bunch of tedious steps that get in the way of
> actually using the IDE.
>
> Is it possible for Eclipse to work with its plugins checked into a
> repository, instead of "installed" in Eclipse proper?  (I'm a many-years
> multi-platform Eclipse user, but I have not explored all of its twisty
> passages.)

I agree. Plugins are complicated.

Why don't we provide a complete eclipse/ folder with the necessary plugins?

Want to try scala?
a) follow these instructions and get your dev environment working, at
your own expense
b) go for the one "size fits all" pre packaged eclipse installation
with the "it just works feature" 90% guaranteed

Option a) is what we have now, which is good but introduces a
variable. If you multiply that risk by a large team, then its
unmanageable.

Let's create an option b)

Here's a real life example:

Adobe did this with Flex4 IDE ( Gumbo ) last year, which is based on
Eclipse. "It just works", and customers can get a feeling or even move
forward with a reasonably stable IDE for the masses.
Technology is still not even in Beta and things have radically change
since then ( deep API and compiler changes ), but when the time comes,
it will be a mechanical process to update ONE project the latest
SDK/library.
In the meantime developers could actually get work done.

>
>
> - How about non-IDE users?  I don't know enough about Maven (I know it
> is supposed to deal with versions of this and that), but one problem
> we have run into is the "command line" side of the build using their
> copies of the jar files, and the Eclipse side of the build using their
> copies of the plugins, and there being notable differences between the
> two.  The non-IDE guys will do stuff that causes problems for Eclipse
> (e.g., adding tools, upgrading tools, adding multiple build.xml files)
> and other IDEs.

See the Adobe anecdote above. It is an 80/20 solution. Those who go
astray have to suffer, but at least it gives you a manageable
alternative.

>
> I think this is again "can Eclipse run against plugins checked into
> a repository?", because if you could get that right, and if the plugins
> contained the bits necessary for command line use (the one time that I
> looked, they did, though the jar files had funny names), then things
> would work ok, at least until the non-IDE users went and installed a
> non-plugin version of the jar on top of it.  (If "eclipse compatibility"
> is not part of your unit tests, this can happen.)
>
>
> - Plugins can be surprisingly brittle.  For example, We use ASM, we
> like it very much, but with Eclipse 3.4+, you have to go to one site
> to get the basic ASM tools, and to another site to get the compatible
> version of Bytecode outliner.  You might be tempted to think you could
> get them all at the ASM site, but (for whatever reason) that doesn't
> work (at least, it didn't work earlier this week).

True. But again this noise could be reduced by sticking to a sealed solution.

>
>
> - We've run into one particular, annoying problem, that is Scala-related.
> Scalac can make unusual demands on a VM, so the heap and stack sizes
> need to be bigger, and neither ant nor Eclipse makes it especially
> easy to deal with this for a new or casual user, especially not in a
> way that you can check in to a repository in a platform-independent way.
> Eclipse requires editing of a file buried in its "application" (how this
> looks is platform-specific).  Ant can be tweaked by setting environment
> variables, but those are not always re-set for you when it is run within
> an IDE (or rather, you may need to set them a second time within the IDE).
> The Eclipse editing is "bad" because if you do it wrong, you can make
> Eclipse be un-startable.
>
>
> - As a Sun employee, I think I'm supposed to say "hey, what about NetBeans",
> but as an Eclipse addict who has been unable to break the habit, I can
> understand only dealing with one IDE, and choosing the one that you like
> best.
>
>
> On the plus side, we did get it down to one page of instructions, it's just
> that each step requires a bunch of mousing around and waiting.  This is the
> sort of thing where it would really be much nicer to have it all be do-able
> from the command line, so that someone who was interested could just swipe
> some text, copy, paste in a shell window, and go get coffee.

Or just click "download".
And the alternative is always there if you need more customization, of course.

But again, this is all about helping someone ( a manager ) *predict* a
scenario. Even if it is not optimal.

I want to be able to say, to a customer: "we'll do this project in
Scala, and I can assure you that things will work, for each of your 20
developers, under this conditions".

You can't manage what you can't measure ;)

>
>
>> The rationale is this: Most developers will fit in one or two
>> profiles. For example, this is a very common profile.
>> * Maven
>> * Eclipse 3.4/5
>> * SVN
>> * Java + Scala mixed sources
>> * Scala 2.7.4.RC1
>>
>> That could be boiled down to a .classpath, .project, skeleton.
>>
>> BTW. We also tried IDEA and Netbeans. Different versions, different
>> setups, different machines. Results are amazingly inconsistent. I
>> understand there are many collateral settings in all these IDEs that
>> make it really hard to figure out what went wrong.
>

Thanks,
A

Hi Miles,

On Thu, Apr 23, 2009 at 9:30 AM, Miles Sabin wrote:
> On Thu, Apr 23, 2009 at 11:05 AM, Aldo Bucchi wrote:
>> The rationale is this: Most developers will fit in one or two
>> profiles. For example, this is a very common profile.
>> * Maven
>> * Eclipse 3.4/5
>> * SVN
>> * Java + Scala mixed sources
>> * Scala 2.7.4.RC1
>>
>> That could be boiled down to a .classpath, .project, skeleton.
>
> With the exception of Maven, this setup should work out of the box
> without any need for templates of any sort.

It does. Maven is the spoiler.

>
> Maven, apparently, does all kinds of bad things with Eclipse's
> internal metadata. You might find this thread, especially the comments
> from Josh Suereth, helpful,
>
> http://groups.google.com/group/liftweb/browse_thread/thread/3dac7002f9e5...
>
> I'd appreciate it if people would direct their venting at the
> developers of the maven-eclipse-plugin because it seems that it's at
> the root of a lot of the issues that people have been having with the
> Scala IDE for Eclipse in general, and Lift developement in particular.

You would know better than anyone ;)
And for what I can tell experimentally, it is mostly Maven that wreaks
havoc. But it is probably the interaction between both plugins, so
this has to be studied a bit before venting things to the Maven
family. They will want concrete directions and motivation.

That's a long road and there's probably a cheaper alternative. And
you're moving quite fast with Plugin development so,

Here's THE question:

Have you managed to get a project with Maven running OK?
( I have already been told that someone has )

Could (someone) then please provide the layout, .settings, .classpath,
etc for it? Just to see what OK means.
This is not an easy problem to isolate. Look.

From experimentation, I have seen that subtle combinations of settings
of the following
* Exports and Order
* Layout of source folders ( combinations of main/tests | java/scala/ )
* Output folders for said source folders
* Scrub on clean or not
* Link extra class folder ( circular link to output, usually /bin )
* Eclipse and Maven version
* JRE vs Scala container order
* And of course Scala and plugin version (which we can normalize to
2.7.4.RC1 or other later)
* Unit testing or Spec ( and how you run whichever you're using )
* Maven POM setup
* Whether you share output folders between Maven and Eclipse or not
* Clean ( Eclipse and Maven )

All give different results!
I have some clues on the internals, but you can understand that this
is quite a complex problem to tackle and I wouldn't push a customer
down that road blindfolded.

So, a pre-packaged alternative sounds quite attractive.

I can donate some S3 space.

Comments?

Thanks,
A

>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://twitter.com/milessabin
>

I figured I should chime in now....

On Thu, Apr 23, 2009 at 4:58 PM, Aldo Bucchi <aldo.bucchi@gmail.com> wrote:

>
> Maven, apparently, does all kinds of bad things with Eclipse's
> internal metadata. You might find this thread, especially the comments
> from Josh Suereth, helpful,
>
> http://groups.google.com/group/liftweb/browse_thread/thread/3dac7002f9e59546#
>
> I'd appreciate it if people would direct their venting at the
> developers of the maven-eclipse-plugin because it seems that it's at
> the root of a lot of the issues that people have been having with the
> Scala IDE for Eclipse in general, and Lift developement in particular.

You would know better than anyone ;)
And for what I can tell experimentally, it is mostly Maven that wreaks
havoc. But it is probably the interaction between both plugins, so
this has to be studied a bit before venting things to the Maven
family. They will want concrete directions and motivation.

That's a long road and there's probably a cheaper alternative. And
you're moving quite fast with Plugin development so,

Here's THE question:

Have you managed to get a project with Maven running OK?
( I have already been told that someone has )

Yes.  They do, in fact, work well together.  Starting from a position of understanding maven alone, and scala alone, I beleive that you, too, can use both together succesfully.  I started a project to try to capture issues and handle them: http://code.google.com/p/esmi/
 
I currently have a internal multi-module maven project written in 100% scala that is made up of 5 sub-projects (this uses Specs).  I'm developing this in eclipse with no issues.  I'm also taking one of our main applicaitons (10+ modules and growing) and working with mixed java-scala mode.   Things are also fine here (just issues with unit tests, discuessed below).

Could (someone) then please provide the layout, .settings, .classpath,
etc for it? Just to see what OK means.
This is not an easy problem to isolate. Look.

From experimentation, I have seen that subtle combinations of settings
of the following
* Exports and Order
* Layout of source folders ( combinations of main/tests | java/scala/ )

There are sometimes issues here with the scala plugin not being 100% friendly  with multiple source/output directories.  This hasn't caused me much grief because I use the same output folder for all source folders.

* Output folders for said source folders
* Scrub on clean or not
* Link extra class folder ( circular link to output, usually /bin )
* Eclipse and Maven version

This can cause issues.  I like to have my maven build output to different directories than eclipse

* JRE vs Scala container order

Adding the Scala Nature as the *last* step to a project helps this.

* And of course Scala and plugin version (which we can normalize to
2.7.4.RC1 or other later)
* Unit testing or Spec ( and how you run whichever you're using )

I do have trouble with these.  After my current dev crunch, I plan to look into it.

* Maven POM setup

 I hope to have enough examples for people in this space.  There are a few workarounds you must use if you're using the maven-eclipse-plugin.

* Whether you share output folders between Maven and Eclipse or not

Right now, I would say not, unless you can use the same version of the Scala Development Tools as the version of scala you want for your build.  (I'm currently running Scala Development Tools nightlies, so I avoid sharing output like the plague).

* Clean ( Eclipse and Maven )

All give different results!
I have some clues on the internals, but you can understand that this
is quite a complex problem to tackle and I wouldn't push a customer
down that road blindfolded.

So, a pre-packaged alternative sounds quite attractive.

Pre packaged?  The issue here is that the configuration changes with POMs. 
 

I can donate some S3 space.

Comments?

 

<rant>
My biggest comment is that modifying meta-data externally to the eclipse applicaiton just seems like a bad idea to me.  This is why I prefer methods chosen by tools like q4e or m2e.  In this case, you create a Java Project and add "natures" for maven + scala.   This generally has the best results.  I am willing to open up the wiki to anyone intersted on ESMi so that users can contribute knowledge of maven-eclipse-scala workarounds.  I'm also hoping that over time we can agree on a  "best tool" or solid approach that users can use.  I know some people who prefer modifying eclipse metadata externally due to speed issues with running Maven plugins inside eclipse.  I see the speed issue decreasing over time (see q4e 0.9.0 beta release), whereas externally modifying metadata will always run the risk of becoming stale or not "playing nicely" with the eclipse environment.  The main reason I pushed some patches (and bugged the hell out of Miles) for the "Add Scala Nature" feature was so we had viable methods of making Maven + Scala play nicely in eclipse.
</rant>

Hope this isn't too much of a tirade.  I'd like to figure out a way to solve this issue once and for all.  I plan to deploy a maven-scala-plugin 2.11 build soon, one feature will be improved documentation about the maven-eclipse-plugin.

- Josh

Josh,

Thanks for the tips. I comment up here as getting into too much detail
will probably branch ad infinitum. ( which is exactly the problem with
these situations. don't want to waste everybody's time in vain ).

You're right that
1- Different projects have different POMs
2- Modifying metadata externally can be a bad idea

With some restrictions, though. Can we solve this?

1-Not quite, but... there could be some suggested POM settings (
critical differences will be some of plugins, executions and versions
of specific artifacts. This is what you're doing with your current POM
suggestions in fact )

2-Yes. Metadata can be passed around if Eclipse versions are the same
and installed plugins are the same, then there is no problem in
sharing metadata. I have seen this done several times to homogenize
development teams. I also have workstations on virtual images that are
created from a blueprint. EC2 makes this a piece of cake now.
You can always extend that base install, of course. Or you can have
several IDEs and use them as complement ( like most of us already do )

Rant:

I know there is a really rich world behind and history the scenes and
I am brutally over-simplifying. But it can't be so painful to move *a
team* to Scala these days. Right?
It shouldn't be if you are really willing to.

People in this community are visibly far above average in terms of
brains and knowledge. But, can't we create a "for dummies solution?"

Am I really missing the alternative, that's all. The language is
supposed, after all, to be aimed at pragmatism and productivity. It is
branded as such. So there's a paradox.
Mass adoption drives growth and spins off the virtuous cycle, even if
it means cutting things to its least common denominator.
Java One is coming soon, for example. If you deliver a turnkey
solution people will catch up.

( I come from the SemWeb community and we have lately learned that
valuable lesson through Linked Data, the more the merrier ;) )

Josh, what would happen if you put up a sample eclipse installation on
your Google code site?
I believe that providing the URL to a specific Eclipse download and
then the plugins and features folders should be enough for a start.
Then a project skeleton or even a workspace folder.

I might be wrong here. This might not work, of course. At least not at
first, but we could give it a try. It will take some tweaking to get
it right but there might be something down the road.

Thanks,
A

On Thu, Apr 23, 2009 at 5:24 PM, Josh Suereth wrote:
> I figured I should chime in now....
>
> On Thu, Apr 23, 2009 at 4:58 PM, Aldo Bucchi wrote:
>>
>> >
>> > Maven, apparently, does all kinds of bad things with Eclipse's
>> > internal metadata. You might find this thread, especially the comments
>> > from Josh Suereth, helpful,
>> >
>> >
>> > http://groups.google.com/group/liftweb/browse_thread/thread/3dac7002f9e5...
>> >
>> > I'd appreciate it if people would direct their venting at the
>> > developers of the maven-eclipse-plugin because it seems that it's at
>> > the root of a lot of the issues that people have been having with the
>> > Scala IDE for Eclipse in general, and Lift developement in particular.
>>
>> You would know better than anyone ;)
>> And for what I can tell experimentally, it is mostly Maven that wreaks
>> havoc. But it is probably the interaction between both plugins, so
>> this has to be studied a bit before venting things to the Maven
>> family. They will want concrete directions and motivation.
>>
>> That's a long road and there's probably a cheaper alternative. And
>> you're moving quite fast with Plugin development so,
>>
>> Here's THE question:
>>
>> Have you managed to get a project with Maven running OK?
>> ( I have already been told that someone has )
>
> Yes.  They do, in fact, work well together.  Starting from a position of
> understanding maven alone, and scala alone, I beleive that you, too, can use
> both together succesfully.  I started a project to try to capture issues and
> handle them: http://code.google.com/p/esmi/
>
> I currently have a internal multi-module maven project written in 100% scala
> that is made up of 5 sub-projects (this uses Specs).  I'm developing this in
> eclipse with no issues.  I'm also taking one of our main applicaitons (10+
> modules and growing) and working with mixed java-scala mode.   Things are
> also fine here (just issues with unit tests, discuessed below).
>
>>
>> Could (someone) then please provide the layout, .settings, .classpath,
>> etc for it? Just to see what OK means.
>> This is not an easy problem to isolate. Look.
>>
>> From experimentation, I have seen that subtle combinations of settings
>> of the following
>> * Exports and Order
>> * Layout of source folders ( combinations of main/tests | java/scala/ )
>
> There are sometimes issues here with the scala plugin not being 100%
> friendly  with multiple source/output directories.  This hasn't caused me
> much grief because I use the same output folder for all source folders.
>>
>> * Output folders for said source folders
>> * Scrub on clean or not
>> * Link extra class folder ( circular link to output, usually /bin )
>> * Eclipse and Maven version
>
> This can cause issues.  I like to have my maven build output to different
> directories than eclipse
>>
>> * JRE vs Scala container order
>
> Adding the Scala Nature as the *last* step to a project helps this.
>>
>> * And of course Scala and plugin version (which we can normalize to
>> 2.7.4.RC1 or other later)
>> * Unit testing or Spec ( and how you run whichever you're using )
>
> I do have trouble with these.  After my current dev crunch, I plan to look
> into it.
>>
>> * Maven POM setup
>
>
> I hope to have enough examples for people in this space.  There are a few
> workarounds you must use if you're using the maven-eclipse-plugin.
>>
>> * Whether you share output folders between Maven and Eclipse or not
>
> Right now, I would say not, unless you can use the same version of the Scala
> Development Tools as the version of scala you want for your build.  (I'm
> currently running Scala Development Tools nightlies, so I avoid sharing
> output like the plague).
>>
>> * Clean ( Eclipse and Maven )
>>
>> All give different results!
>> I have some clues on the internals, but you can understand that this
>> is quite a complex problem to tackle and I wouldn't push a customer
>> down that road blindfolded.
>>
>> So, a pre-packaged alternative sounds quite attractive.
>
> Pre packaged?  The issue here is that the configuration changes with POMs.
>
>>
>> I can donate some S3 space.
>>
>> Comments?
>
>
>
>
> My biggest comment is that modifying meta-data externally to the eclipse
> applicaiton just seems like a bad idea to me.  This is why I prefer methods
> chosen by tools like q4e or m2e.  In this case, you create a Java Project
> and add "natures" for maven + scala.   This generally has the best results.
> I am willing to open up the wiki to anyone intersted on ESMi so that users
> can contribute knowledge of maven-eclipse-scala workarounds.  I'm also
> hoping that over time we can agree on a  "best tool" or solid approach that
> users can use.  I know some people who prefer modifying eclipse metadata
> externally due to speed issues with running Maven plugins inside eclipse.  I
> see the speed issue decreasing over time (see q4e 0.9.0 beta release),
> whereas externally modifying metadata will always run the risk of becoming
> stale or not "playing nicely" with the eclipse environment.  The main reason
> I pushed some patches (and bugged the hell out of Miles) for the "Add Scala
> Nature" feature was so we had viable methods of making Maven + Scala play
> nicely in eclipse.
>
>
> Hope this isn't too much of a tirade.  I'd like to figure out a way to solve
> this issue once and for all.  I plan to deploy a maven-scala-plugin 2.11
> build soon, one feature will be improved documentation about the
> maven-eclipse-plugin.
>
> - Josh
>
>
>
>

On Thu, Apr 23, 2009 at 6:29 PM, Aldo Bucchi <aldo.bucchi@gmail.com> wrote:

Josh,

Thanks for the tips. I comment up here as getting into too much detail
will probably branch ad infinitum. ( which is exactly the problem with
these situations. don't want to waste everybody's time in vain ).

You're right that
1- Different projects have different POMs
2- Modifying metadata externally can be a bad idea

With some restrictions, though. Can we solve this?

1-Not quite, but... there could be some suggested POM settings (
critical differences will be some of plugins, executions and versions
of specific artifacts. This is what you're doing with your current POM
suggestions in fact )

Actually, the pom suggestions are to fix the maven-eclipse-plugin.  I'll see if I can make a turn-key solution for "if you use maven and scala inside eclipse".
 

2-Yes. Metadata can be passed around if Eclipse versions are the same
and installed plugins are the same, then there is no problem in
sharing metadata. I have seen this done several times to homogenize
development teams. I also have workstations on virtual images that are
created from a blueprint. EC2 makes this a piece of cake now.
You can always extend that base install, of course. Or you can have
several IDEs and use them as complement ( like most of us already do )

This is all well and good, except the issue isn't with the initial meta-data, but with regenerating the metadata based on maven pom files.  The current plugin works great for java, and some extensions, but can cause strange issues to users who hope that it will magically solve their eclipse configuration woes.  My opinion is merely that being inside eclipse and modifying the meta-data live leads to an easier-to-maintain software.  What I'm trying to do is outline a path to follow to get Eclipse + Maven running well together.  I'd rather not support the maven-eclipse-plugin path, because I see it as being a decent amount of work currently.  We've also attracted the attention of Jason van-Zyl who wants to provide fast integration with m2e.  I see this as being a much better option, and something users would be happier with.
 

Rant:

I know there is a really rich world behind and history the scenes and
I am brutally over-simplifying. But it can't be so painful to move *a
team* to Scala these days. Right?
It shouldn't be if you are really willing to.

People in this community are visibly far above average in terms of
brains and knowledge. But, can't we create a "for dummies solution?"

Am I really missing the alternative, that's all. The language is
supposed, after all, to be aimed at pragmatism and productivity. It is
branded as such. So there's a paradox.
Mass adoption drives growth and spins off the virtuous cycle, even if
it means cutting things to its least common denominator.
Java One is coming soon, for example. If you deliver a turnkey
solution people will catch up.

( I come from the SemWeb community and we have lately learned that
valuable lesson through Linked Data, the more the merrier ;) )

Josh, what would happen if you put up a sample eclipse installation on
your Google code site?
I believe that providing the URL to a specific Eclipse download and
then the plugins and features folders should be enough for a start.
Then a project skeleton or even a workspace folder.

If you'd like to see an eclipse install that has a maven plugin + the scala plugin, there's a chance I can make that happen.  I'm not an IP ninja, but I think there would be some form of "here are the relevant licenses" for people to see before they could download my bundled version.  That's one reason why plugins require you to accept license terms when you download them.  I think this isn't an impossible barrier, just a harry legal one.  If you're interested in helping set this up, perhaps starting a thread on maven-scala-plugin?  I'm willing to donate resources to automate the building of this beast, but perhaps some investigation into how we can satisfy all licenses satisfactorially on download would be good.

This however, still does not solve the initial issue:  Users are trying to take a tool designed for the "simple java case" to be easy.  The maven-eclipse-plugin requires internal knowledge of how thirdy-part plugin meta-data is configured to be placed inside your pom-file, or it will not work correctly.  This imposition on users is by nature of how the tools works.  Once again, I implore users to try something which works inside eclipse, and can therefore take advantage of eclipse's plugin system to ease integration.  i.e. I can write an eclipse plugin to integrate between maven and scala, but the maven-eclipse-plugin does not have its own plugin system (and is therefore stale and unchangeable).  This means everytime you make a pom, you need to rewrite this configuration AND you have to keep it up to date with plugin changes.
 

I might be wrong here. This might not work, of course. At least not at
first, but we could give it a try. It will take some tweaking to get
it right but there might be something down the road.

I'm game for some boiler-plate projects to get people started.  In fact, I may make one right now (that includes meta-data).  Most of my "sample" projects are on github, and all of them use maven to build (except of course, my Scala Development Tools hacking as scala uses Ant).  Perhaps when I revitalize the ESMi plugin itself, this would be one means of installing it.

The key here is that it is possible to use maven + eclipse together, just don't use methods that require in-depth knowledge unless you want to go in-depth.


-Josh

On Thu, 2009-04-23 at 17:24 -0400, Josh Suereth wrote:
>
> My biggest comment is that modifying meta-data externally to the
> eclipse applicaiton just seems like a bad idea to me.

I disagree. If you know what the metadata is supposed to look like, this
is more predictable as it's plain Eclipse under the hood. All one needs
to do is configure it properly. The configuration is a bit verbose (as
usual with Maven), but only has to be done once in the parent pom and
all child projects just work.

> This is why I prefer methods chosen by tools like q4e or m2e. In
> this case, you create a Java Project and add "natures" for maven +
> scala. This generally has the best results.

I guess I need to try these again. They used to be quite bad for
multi-module projects with plain Java (to be fair, it's been more than a
year since I tried them). My build went into an infinite loop a large
number of times and sometimes things would get stale and I'd need to
clean, etc. The more annoying thing is that these would happen during
normal development, not necessarily when adding and removing
dependencies.

When I moved to mvn eclipse:eclipse, it was a joy to have a reliable and
quick build inside Eclipse again. That didn't last for long since I then
started using the Scala plugin. ;)

Best,
Ismael

On Fri, Apr 24, 2009 at 5:44 AM, Ismael Juma wrote:
> When I moved to mvn eclipse:eclipse, it was a joy to have a reliable and
> quick build inside Eclipse again. That didn't last for long since I then
> started using the Scala plugin. ;)

OK, so do I throw my hands up in despair and blame it all on the Maven
Eclipse folks, or is there something simple and straightforward that I
can do in the Scala IDE which will make everybody's lives easier?

Cheers,

Miles

On Fri, 2009-04-24 at 09:21 +0100, Miles Sabin wrote:
> OK, so do I throw my hands up in despair and blame it all on the Maven
> Eclipse folks, or is there something simple and straightforward that I
> can do in the Scala IDE which will make everybody's lives easier?

I think the best thing to do is to create a parent pom with everything
configured correctly so that mvn eclipse:eclipse, q4e and IAM all work
correctly and link to it from the Scala IDE for Eclipse download page. I
think this should be possible, but if not, then one could provide a
separate one for eclipse:eclipse.

I've been meaning to do something like this, but have not had a chance
yet. Josh, you did something like this for Lift right? Maybe you can
just trim the stuff that is Lift specific and use that.

Best,
Ismael

On Fri, 2009-04-24 at 09:35 +0100, Ismael Juma wrote:
> On Fri, 2009-04-24 at 09:21 +0100, Miles Sabin wrote:
> > OK, so do I throw my hands up in despair and blame it all on the Maven
> > Eclipse folks, or is there something simple and straightforward that I
> > can do in the Scala IDE which will make everybody's lives easier?
>
> I think the best thing to do is to create a parent pom with everything
> configured correctly.

Or create a maven archetype. I don't usually bother with that, but many
projects seem to use them (I think Lift does too). Josh would be able to
provide more details.

Ismael

On Fri, Apr 24, 2009 at 9:35 AM, Ismael Juma wrote:
> On Fri, 2009-04-24 at 09:21 +0100, Miles Sabin wrote:
>> OK, so do I throw my hands up in despair and blame it all on the Maven
>> Eclipse folks, or is there something simple and straightforward that I
>> can do in the Scala IDE which will make everybody's lives easier?
>
> I think the best thing to do is to create a parent pom with everything
> configured correctly so that mvn eclipse:eclipse, q4e and IAM all work
> correctly and link to it from the Scala IDE for Eclipse download page.

So you're really saying that there aren't *any* changes that I can
make to the Scala IDE that will make special configuration
unnecessary?

If that's the case then the Maven Eclipse plugin really is broken ...

Hmm ... seems like I really should spend a little time investigating this.

Cheers,

Miles

On Fri, 2009-04-24 at 09:57 +0100, Miles Sabin wrote:
> So you're really saying that there aren't *any* changes that I can
> make to the Scala IDE that will make special configuration
> unnecessary?

No, I am not saying that. I am just saying that if you want to use Maven
with Eclipse and have tooling support out of the box, you should just
use... one of the Maven plugins for Eclipse (either q4e/IAM or m2e).
That is their aim. I think Josh was doing some work so that IAM would
support Scala out of the box. Not sure what the status of that is. It
just happens that they were unreliable in the past, but according to
Josh they're much better now.

> If that's the case then the Maven Eclipse plugin really is broken ...

I don't know which of the plugins you're talking about, but the aim of
mvn eclipse:eclipse is to generate Eclipse metadata from the pom so that
the native Eclipse tools work as if maven was not being used at all.
Given that one can change pretty much all the maven defaults through the
pom, I don't see how the Eclipse IDE for Scala can do the right thing
here aside from reading the pom.

What could be done better is that mvn eclipse:eclipse could understand
Scala projects based on something in the pom and then generate metadata
that would match what the Scala IDE for Eclipse expects. But anyone that
uses maven should have a parent pom anyway and it's easy to include the
bits that make that true without having to wait for upstream developers
to do something (if they ever do).

> Hmm ... seems like I really should spend a little time investigating this.

If you like. Personally, I think there are some more important
things[1], but it's your time. :)

Ismael

[1] Even though the plugin is much better now, basic things like syntax
highlighting, content assist and navigation (e.g. F3) are still quite
unreliable.

On Fri, Apr 24, 2009 at 10:26 AM, Ismael Juma wrote:
>> If that's the case then the Maven Eclipse plugin really is broken ...
>
> I don't know which of the plugins you're talking about, but the aim of
> mvn eclipse:eclipse is to generate Eclipse metadata from the pom so that
> the native Eclipse tools work as if maven was not being used at all.
> Given that one can change pretty much all the maven defaults through the
> pom, I don't see how the Eclipse IDE for Scala can do the right thing
> here aside from reading the pom.

And presumably it's (re-)generating it incorrectly for Scala projects?

>> Hmm ... seems like I really should spend a little time investigating this.
>
> If you like. Personally, I think there are some more important
> things[1], but it's your time. :)

I agree, except that about 60% of the "Eclipse is buggy as hell so I'm
switching to Netbeans/IntelliJ/emacs/vim" type complaints seem to
resolve down to these Maven issues. It's making the Scala IDE look bad
and I'm getting a bit fed up with it.

Cheers,

Miles

On Fri, 2009-04-24 at 10:40 +0100, Miles Sabin wrote:
> On Fri, Apr 24, 2009 at 10:26 AM, Ismael Juma wrote:
> >> If that's the case then the Maven Eclipse plugin really is broken ...
> >
> > I don't know which of the plugins you're talking about, but the aim of
> > mvn eclipse:eclipse is to generate Eclipse metadata from the pom so that
> > the native Eclipse tools work as if maven was not being used at all.
> > Given that one can change pretty much all the maven defaults through the
> > pom, I don't see how the Eclipse IDE for Scala can do the right thing
> > here aside from reading the pom.
>
> And presumably it's (re-)generating it incorrectly for Scala projects?

Yes, because it's based on the principle that the pom is the canonical
source and the Scala information (e.g. source folders, classpath
container, nature) is either missing or in a format that it doesn't
understand. As mentioned before, this can be remedied quite easily and
without repetition (verbosity in the parent pom aside).

Yes, it's not perfect, but this tool doesn't aim at perfection. It's
just a stopgap until the "seamless" tools work well enough. If they do
already, that's another alternative, just tell people not to use mvn
eclipse:eclipse unless they know what they're doing.

> >> Hmm ... seems like I really should spend a little time investigating this.
> >
> > If you like. Personally, I think there are some more important
> > things[1], but it's your time. :)
>
> I agree, except that about 60% of the "Eclipse is buggy as hell so I'm
> switching to Netbeans/IntelliJ/emacs/vim" type complaints seem to
> resolve down to these Maven issues. It's making the Scala IDE look bad
> and I'm getting a bit fed up with it.

That's a pretty high number and if that's the case, then you have every
right to be. :)

Best,
Ismael

On Fri, Apr 24, 2009 at 10:53 AM, Ismael Juma wrote:
> Yes, it's not perfect, but this tool doesn't aim at perfection. It's
> just a stopgap until the "seamless" tools work well enough. If they do
> already, that's another alternative, just tell people not to use mvn
> eclipse:eclipse unless they know what they're doing.

I would love to do just that ... unfortunately mvn eclipse:eclipse
seems to be recommended starting point for working with Lift.

> That's a pretty high number and if that's the case, then you have every
> right to be. :)

It certainly seems that way at least on the lift lists. And typically
most of this never manifests itself as tickets in Trac, just griping
and ship-jumping.

Which is unsurprising in a way I guess. If your main interest is Lift,
then you're going to use whatever tool gets the job done. Nevertheles,
it's very frustrating for me ...

Cheers,

Miles

Miles,

On Fri, Apr 24, 2009 at 5:58 AM, Miles Sabin wrote:
> On Fri, Apr 24, 2009 at 10:53 AM, Ismael Juma wrote:
>> Yes, it's not perfect, but this tool doesn't aim at perfection. It's
>> just a stopgap until the "seamless" tools work well enough. If they do
>> already, that's another alternative, just tell people not to use mvn
>> eclipse:eclipse unless they know what they're doing.
>
> I would love to do just that ... unfortunately mvn eclipse:eclipse
> seems to be recommended starting point for working with Lift.
>
>> That's a pretty high number and if that's the case, then you have every
>> right to be. :)
>
> It certainly seems that way at least on the lift lists. And typically
> most of this never manifests itself as tickets in Trac, just griping
> and ship-jumping.
>
> Which is unsurprising in a way I guess. If your main interest is Lift,
> then you're going to use whatever tool gets the job done. Nevertheles,
> it's very frustrating for me ...

Which other techs fcompile to Java?

I know Maven suggests groovy sources to be put under /src/main/groovy,
so at least layout is similar.
Now, I don't know heck about groovy (is it interpreted or compiled?) I
am just throwing an example to make a point: What if there is another
tech out there with a plugin for Eclipse that has already solved a
similar situation and learned to deal with Maven?

That might be a starting point.

Regards,
A

>
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://twitter.com/milessabin
>

Sent from my iPhone

On Apr 24, 2009, at 5:58 AM, Miles Sabin wrote:

> On Fri, Apr 24, 2009 at 10:53 AM, Ismael Juma
> wrote:
>> Yes, it's not perfect, but this tool doesn't aim at perfection. It's
>> just a stopgap until the "seamless" tools work well enough. If they
>> do
>> already, that's another alternative, just tell people not to use mvn
>> eclipse:eclipse unless they know what they're doing.
>
> I would love to do just that ... unfortunately mvn eclipse:eclipse
> seems to be recommended starting point for working with Lift.

When the lift archetypes are fixed, you should notice less "zOMG
eclipse!" emails. I'll also look into updating/creating a new
archetype just for eclipse + java/scala projects.
>
>
>> That's a pretty high number and if that's the case, then you have
>> every
>> right to be. :)
>
> It certainly seems that way at least on the lift lists. And typically
> most of this never manifests itself as tickets in Trac, just griping
> and ship-jumping.
>
> Which is unsurprising in a way I guess. If your main interest is Lift,
> then you're going to use whatever tool gets the job done. Nevertheles,
> it's very frustrating for me ...
>
>

Definitely understand. Think of them more as complaints against
eclipse-maven integration, which for lift would be a viable reason to
switch. Of course, the way I use eclipse + maven, I think, alleviates
most of these complaints.

> Cheers,
>
>
> Miles
>

On Fri, Apr 24, 2009 at 12:23 PM, Josh Suereth wrote:
> When the lift archetypes are fixed, you should notice less "zOMG eclipse!"
> emails.  I'll also look into updating/creating a new archetype just for
> eclipse + java/scala projects.

I saw your patch and message on the lift list ... but no visible sign of action.

Who's responsible for getting this done? I need to chase them ... this
madness must end, now ...

Cheers,

Miles