Re: [flux-dev] flux projects

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I'm definitely not a fan of committing
jars to Git, especially if they change frequently. You end up with very
bloated Git repos that are hard to work with. But, I admit I don't fully
understand what JARs you are talking about and why they need to run on
any git pull operation. 

John



From:      
 Kris De Volder <kdevolder@xxxxxxxxxx>
To:      
 Martin Lippert <mlippert@xxxxxxxxxx>,

Cc:      
 Flux developer discussions
<flux-dev@xxxxxxxxxxx>, "os-tooling@xxxxxxxxxx" <os-tooling@xxxxxxxxxx>
Date:      
 10/30/2014 01:35 PM
Subject:    
   Re: [flux-dev]
flux projects
Sent by:    
   flux-dev-bounces@xxxxxxxxxxx

---

> I changed this: ...

I have no objections. I don't know why you are getting
errors because of this, for some reason I do not. I committed some pom
bits that are supposed to make m2e shut up about the missing lifecycle
crap. But I beleave you are right we don't really need m2e support on PDE
supported projects. That is, unless we can come up with some way that m2e
doesn't complain about the lifecycle mapping bit and actually produces
the jars as needed instead.

> Another question came up:
> - Do I have to run the maven build after every git pull operation?

You only need to run the maven build if something has
changed in java.client. But it may be safest to run it when in doubdt (i.e.
if you are unsure whether the client jar or its dependencies have changed).

> (If that is the case, I would like to vote for committing the libs
to the bundle instead of running the build)

If that's what other people also think... sure. Here are
my objections:

  - git doesn't like versioning jar artefacts. Makes
for bloated repos, slow clone pull/push etc.
  - the snapshot jar will look different every time
it gets built. Even if it hasn't really changed. This is only a problem
if you actually run maven build locally. Some of us do that. It may be
annoying to decide whether you really need to commit the new jar (is it
a real change?) or not.
  - If you would break something in the pom so that
it no longer properly updates the libs/jars you might not notice because
there will be jars already there even if your build is broken and so the
build will 'work' but may use wrong/old artefacts.
  - I do not like putting artifacts into git that
our own build produces.

Okay so I won't vote -1. Let's call it -0.5. So unless
other people agree with me on the objections outweighing the benefits I
concede and we can put the jars in the repo.

Just realized we are holding this discussion only in internal
os-tooling list, we probably should have it in public flux-dev. So I'm
cc-ing it there.

Kris

On Thu, Oct 30, 2014 at 6:22 AM, Martin Lippert <mlippert@xxxxxxxxxx>
wrote:
Hey!

I tried to setup all the various Flux projects in my workspace and followed
the steps (the additional Maven build).

I changed this:
- I removed the Maven nature from the plugin projects, since the plugin
projects doesn’t need any m2e functionality. In addition to that I had
errors showing up in the pom.xml file.
- I removed the Maven nature from the feature projects, that isn’t necessary
either and is causing similar trouble

Another question came up:
- Do I have to run the maven build after every git pull operation?
(If that is the case, I would like to vote for committing the libs to the
bundle instead of running the build)

Cheers,
-Martin


_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev