Re: [flux-dev] flux projects

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I understand the problem but I'm not enough
of a Maven user to recommend the answer. We had a good solution for this
problem in the Ant builder world in the form of "external tool builders".
You could add an extra builder to your project that would produce the extra
jar. This can then be triggered to build before launch, or on every incremental
build, etc. Here is an example of a project that is doing this (see scripts/buildExtraJar.xml):

http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.publisher.eclipse

I don't know if Eclipse maven tools
extend the "external tool builder" concept with the ability to
run Maven, or maybe it could even be invoked via Ant or shell script which
I know are supported by external builders.

Eventually the lib does need to get
onto a plugin's classpath, which means either copying the jar into the
wrapper plugin, or adding the minimal manifest.mf to the "plan Java"
for it to be recognizable as a plugin itself (this is what we tend to do
with 3rd party libraries such as Apache libraries - throw in a manifest
and treat it as its own OSGi bundle.

John




From:      
 Kris De Volder <kdevolder@xxxxxxxxxx>
To:      
 Flux developer discussions
<flux-dev@xxxxxxxxxxx>, 
Date:      
 10/31/2014 11:49 AM
Subject:    
   Re: [flux-dev]
flux projects
Sent by:    
   flux-dev-bounces@xxxxxxxxxxx

---

> 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.

Let me clarify it.

I've been refactoring common bits of Java 'flux client'
code into a separate 'java.client' project. This code is intended to be
used by both 'plain' Java projects and Eclipse/Osgi plugins. To bridge
the gap between plain java/Maven and Eclipse/Tycho I've created a 'wrapper'
around the client.java which is an eclipse plugin and can be part of tycho
builds etc.

The wrapper contains a few jars in a 'lib' folder. One
jar is the 'java.client' built by 'plain maven'. The other jars are internal
dependencies for java.client. The jars are on the wrapper plugins classpath
(added via its manifest.mf from libs folder) and java.client packages are
exported.

To make this work, the jars have to be in the libs folder,
otherwise your dev workspace will not be able to find the 'java.client'
classes (in the eclipse world) and have lots of compile errors.

So to setup a dev workspace, either we have to commit
these jars to git, or we run have to run a mvn build to rebuild / download
them as needed.

Le me know if something isn't clear. Or, if you know a
less painful way to bridge between eclipse/tycho world and plain Java/maven
worlds... 

Kris

On Fri, Oct 31, 2014 at 1:13 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote:
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

_______________________________________________
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
_______________________________________________
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