Can I stop eclipse bndtools and gradle build conflicting?

[t...@quarendon.net]

When using the bndtools gradle command line build, it uses the same output directory locations as the build uses within eclipse.

This makes life very frustrating when you are swapping between the two. 

Just turning off "build automatically" in eclipse doesn't always seem enough, quite often I have to close down eclipse in order

to get the gradle build to run cleanly.

Is there a way I can make them not conflict?

Thanks.

[BJ Hargrave]

Not really. I always turn off Build Automatically when I need to run command line builds.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Peter Kriens]

BJ, we could do this with a macro, couldn’t we? We can check the driver and then override the macros for bin, bin_test? Something like:

  bin     = ${if;${driver;gradle};bin_g;bin}

  testbin = ${if;${driver;gradle};bin_test_g;bin_test}

Not sure if gradle is the gradle driver name though?

Kind regards,

Peter Kriens

[BJ Hargrave]

"gradle" is the driver name. But I would flip the naming so that gradle uses the "normal" name and Eclipse uses the different name.

  bin     = ${if;${driver;gradle};bin;bin_eclipse}

  testbin = ${if;${driver;gradle};bin_test;bin_test_eclipse}

That would work for the compilation output (.class files) but you still have conflict on the output bundles. So you would need to do the same for target-dir.

  target-dir: ${if;${driver;gradle};generated;generated_eclipse}

[BJ Hargrave]

Actually better would be to set the name for eclipse as the driver:

  bin: ${if;${driver;eclipse};bin_eclipse;bin}

  testbin: ${if;${driver;eclipse};bin_test_eclipse;bin_test}
  target-dir: ${if;${driver;eclipse};generated_eclipse;generated}

This way the names are the defaults unless you are in eclipse.

--

BJ

[t...@quarendon.net]

This way the names are the defaults unless you are in eclipse.

I think that's the better way round.

I'll try this modification out, see if I have any joy. It drives me nuts otherwise!

Thanks. 

[t...@quarendon.net]

I'll try this modification out, see if I have any joy.

Although it appears to work, I seem to have some curious effects.

 

A lot of my packages are now marked as "excluded", which weren't before, 

so it appears to not be able to work out that they are referenced in a bnd file?

Ah. I'll certainly need to change all of the eclipse .classpath files to make the output folders match up.

So this could be the problem,. I have a bunch of warnings:

   Bndtools: src folder 'src' has output folder set to 'bin', which does not match bnd's bin folder 'bin_eclipse': see L/cnf/build.bnd#131

[t...@quarendon.net]

Ah. I'll certainly need to change all of the eclipse .classpath files to make the output folders match up.

So this could be the problem,.

Yes. A global search and replace of the .classpath files, changing 

<classpathentry kind="src" output="bin" path="src"/>

<classpathentry kind="src" output="bin_test" path="test"/>

to add "_eclipse" to the "output" locations seems to have worked.

I suspect that 

       <classpathentry kind="output" path="bin"/>

might also need changing, I don't know.

[t...@quarendon.net]

That's SOOOOOOO much better!

That so needs making standard behaviour. 

Thanks!

[Peter Kriens]

But then you need to change all your .classpath files … Gradle is AFAIK completely driven by these macros?

Kind regards,

Peter Kriens

[t...@quarendon.net]

On Thursday, 22 June 2017 13:30:55 UTC+1, pkriens wrote:

But then you need to change all your .classpath files … Gradle is AFAIK completely driven by these macros?

Sorry, not sure I understand.

What I'm suggesting is that (IMO) this need to be the standard behaviour, so that out of the box my build.bnd file has that configuration, AND the bndtools "new project wizard" needs to set up the .classpath appropriately.

I've always classed it as a bug that this conflict occurs, as it makes life quite tiresome if you are trying to make a build work (running all tests for example seems much simpler from the command line). Without it, it's a cycle of

  turn off automatic building in eclipse

  run gradle build

  see it fails not being able to delete a generated jar.

  try gradle build again

  still doesn't work. Close down eclipse

  run gradle build

  start up eclipse

  clean all projects

  turn on automatic building

  fix the test failure

  repeat

[BJ Hargrave]

Why don't you just run the tests from Eclipse? You don't always have to run the tests from the command line. You can do most of your editing and testing within eclipse and then step out to the command line to run a build before pushing your changes.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Peter Kriens]

Well, BJ is gradle centric and I am Eclipse centric. So I just replied that for me, since these files are in .classpath, it is easier to let gradle use other directories.

And as BJ said, one should normally not use the command line. I just commit to a private repo which will build and that works 99% of the time.

Kind regards,

Peter Kriens

[t...@quarendon.net]

On Thursday, 22 June 2017 15:06:45 UTC+1, BJ Hargrave wrote:

Why don't you just run the tests from Eclipse? 

I'm not aware that I can run all tests from all bundles easily from within eclipse. I can run a single bundle from within eclipse, sure. But I need to run all tests to ensure I haven't broken anything.

So I do it by running the gradle build.

Either way, I always run the gradle build before pushing to master. The CI build is going to run the gradle build, so I run the gradle build in the same way before pushing.

That seems to be good engineering practice. 

Given that changing the way it builds in eclipse has knock on effects to the .classpath files, I'm inclined to reverse my position and have the eclipse gradle build build to the "normal" place, and the command line build build to a different place.

From my point of view this is a no-brainer. Now I know this, I'll always ensure that my workspaces are set up to use separate build output directories. I don't see any possible downside.