I tried to pull the Electrum code into an IDE, first Idea and then (the horror!) Eclipse, with little success. It feels like there’s some assumed detail in the instructions. For the line that says,
You can then
Importexisting projects from the Git workspace
does that mean import the various directories one-by-one, or is there a one-step solution?
I’ve installed the Bndtools plugin.
I am running electrum. You can import all projects but they must be in the same directory. The tricky part I recall was the pardinus project since it is a Git submodule, unlike the Alloy project.
It does help to start with a bit more positive attitude towards Eclipse. I know Eclipse got a bad rap in certaing groups because most of their plugins were usually half baked and they do a few things differently than most. However, I work with a lot of people that start using Bndtools and I often see that their initial dislike is actually causing most of the problems. Everything that does not work immediately as they expected is seen as a bug. It pays off handsomely to accept that there is some learning to do. And if everything else fails, you can always stick to Gradle. Eclipse provides the exact same build interactively as Gradle does on the commandline. There is a also a plugin for Intellij that works with the same build structure defined in the bnd.bnd files. However, the Eclipse version has many more viewers and functions for the bnd model of development.
Since I am a committer on the bnd project let me know if you’re missing some functionality.
To import projects: When you startup Eclipse, you should switch to the Bndtools perspective and call up the context menu in the Bndtools or Package explorer and do “Import Projects”. You can then select existing projects. Then select the directory where they are and Eclipse will parse the directory and show you a list of projects. Click finish and it should build.
As said, I had some troubles to get the submodule to work. Once the Electrum guys submit their code I will take a good look and see how we can handle this so that you get the same experience as the curent Alloy .
A bit of background, I used to work for OTI, which was the company that built the first version of Eclipse. I was a regular Eclipse user for years, until I got fed up with the bloat and lack of investment in the Java refactoring. There are still some things better about Eclipse, such as it’s handling of large projects and its incremental compilation, but the refactoring and code analysis in Idea is compelling. IBM (as main contributor to the consortium at the time) blew it again.
So, I select the top-level Electrum directory rather than each directory within in?
Ah, OTI, a blast from the past! You knew Bjorn Freeman-Benson? Magical times.
I tried to avoid the fight about tools as long as a tool can do the job, even if it is less perfect than some other tool. My only preference in an organization is to limit the number of tools. As a consultant, I work what is thrown at me, prefer to work on new functionality.
That said, we worked extremely hard in Bndtools to close the impedance mismatch between the CI tooling (Ant, Maven, Gradle, Make, Sbt, etc.) and a responsive user interface that provides the exact CI build result at any moment in time. A very hard problem.
I think when Eclipse was developed, the idea was that the GUI would be everything but I think time has shown the CI is more important in the end. I conside this as the primary mistake, their offline build was basically non-existent. The frequent mismatch between what you got in the GUI and what was made by the command line was why many people switched to the command line. I still love the GUI but I absolutely need the CI; bnd is an attempt to eat our cookie and have it too 
by creating a build model separate from the build driver (Gradle, Eclipse, Maven, etc.). Looking at the organizations that now work with it, having some builds of over thousand projects, it works quite well. People that learn to use it tend to really like it because it always provides an up to date overview of the complete build of complex products.
Yup, but I guess you’ve already tried this The only really important thing is that the cnf directory is in the same directory as all projects. I.e. the cnf directory is used as a marker for a bnd workspace.
OK. So tried using import existing BND workspace at the electrum level and I get, for the pardinus, project,
Path ‘/Electrum2/org.alloytools.alloy.dist/target/classes’ must denote location inside
project ‘org.alloytools.alloy.dist’
which looks like an absolute rather than a relative path.
tried reimporting through a different route (plus bouncing Eclipse a couple of times). I’m getting an unresolved import in NativeSolver at import org.alloytools.nativecode.util.NativeCode;
I think it’s a different story. Eclipse was really about providing a general GUI framework that would allow people to bind together different legacy systems on the desktop. If you look a the tooling they built for the Eclipse organisation, it was all there. The JavaIDE was really just their first application–and it shows. Unfortunately, these days, the use of Eclipse in an organisation usually is a sign that they’re too cheap to buy tooling for their developers.
Hello.
I’ve tried to add a fresh clone of Electrum2 to Eclipse and I did find a couple of issues, I don’t know if they are related to yours.
First I had a conflict with JDK compliance level which was not being inferred correctly and caused the compilation to fail. I went to Java > Compiler and set it to 1.8. Then there was an issue with the org.alloytools.alloy.core project, where for some reason Eclipse deletes the aQute.bnd.classpath.container from the classpath. I had to manually add the “Bnd Bundle Path” to the Java Build Path of the org.alloytools.alloy.core project and everything compiled correctly.
Having Pardinus as a submodule didn’t cause any trouble, as long as you git clone with the --recursive option.
An additional note, by simply running the SimpleGUI through Eclipse it will not package the resources (eg, no images will appear). You have to set org.alloytools.alloy.dist as the parent project at the run configuration.
Nuno
First, I’d suggest adding all this detail to the README.
Should I be building the v2.1 branch, as master hasn’t moved in ages?
Which level do I import? I believe I’m supposed to import the top directory using the BND aspect, but that fails on my machine because it’s looking for /Electrum2/org.alloytools.pardinus/target/classes Looks like there’s an absolute rather than relative path.
Alternatively, if I import using generic directories, it also picks up the top directory and I get duplication. It would help if you could be very precise about the steps here.
A bit late to the party, but submodules make me nervous. To me they imply that either there should be a monorepo, or there should be a jar to import.
Do I need to build Pardinus separately?
latest news. In Idea, including org.alloytools.pardinus in both buildpath and testpath means the dependencies are registered for test only, and so not available for the application.
No, once it was imported as part of the Bnd workspace it compiled automatically with rest of the projects.