- You said my x_project was complete working software! How do I deploy it?
- How to import into my IDE?
- Are goals of example projects contradictory?
- Why is my x_project written with spring/java configuration?
- What is an x_project?
- Why the jammazwan.shared dependency?
- What is this x… prefix?
- Generated or not? README.md vs NOTES.md
- What does jammazwan.maker have to do with any of this?
- Complex project warnings WTH?
- Local v Remote JMS, DB, FTP
- X__Projects vs jammazwan.100? WTH?
- Uh, this isn’t a comprehensive list of example projects.
You said my x_project was working software! How do I deploy it?
x__projects are designed to isolate routing functionality and protect the user from confusing, deployment related code. They are run with unit tests. “Working,” in this context, is not intended to imply that it is deployable on a server.
The routes you would learn about from these isolated examples may be deployed into any server or service as appropriate. One such approach is outlined in another blog, but there are also vertical stack approaches such as Fuse which are amply documented by Red Hat.
Fabric8 or Openshift are also great deployment options, but again, provide their own learning curves.
How to import into my IDE?
You are encouraged – but not required – to open up your IDE into a new workspace and do all jammazwan work in a fresh workspace. This has nothing to do with jammazwan specifically, but is helpful practice whenever experimenting with new tech.
If you use Eclipse, then Import > General > Existing Projects into Workspace > Next > Browse > … then follow the prompts.
Other IDEs, or even Eclipse as an alternative to above, will import any project which has a pom.xml file. You may follow this normal process to import your jammazwan project into your IDE.
Are goals of example projects contradictory?
Jammazwan example projects are all about:
- Driving adoption to increase learning speed.
- Isolation of functionality to increase learning speed.
Isn’t that a contradiction? Don’t you need to pick one, instead?
Yes, it’s a contradiction. Maximizing the tension between the two is where learning gets real. Drive adoption and you create a huge desire to learn more, really fast. Isolate functionality and you make Camel easy to learn. Together, it’s a magical combination.
The tension between the two does create other problems, though. These are great problems to have.
Why is my x_project written with spring/java configuration?
There are so many language and configuration combinations available to the author of a Camel project, there could be no canonical, or even “best” choice.
Instead I opted for what seems to be the most common and powerful configuration choices. The choice of Java for it’s fluent API is the most important, because it is the most powerful.
What is this x__project naming convention?
One of the major challenges of isolating functionality in example projects is that now you have too many of them.
x__project is often used in the docs as a name for
see below: “What is this x… prefix?” if you need more info on this.
Why the jammazwan.shared dependency?
Some, but not all, x__projects require jammazwan.shared as a dependency, as indicated in their respective README.md
X__project design tries to include only what is unique to this example, so you can focus only on what is required to demo the MyCoolCamelComponent feature in isolation. The single shared project includes dumb artifacts that shouldn’t be unique to a single x__project, such as:
- Beans used as value objects for all example projects
- pom.xml dependencies of a more general nature
- .csv and other source files for use as data sources
- generic utility functions not specific to a single project
So you sometimes have to git clone jammazwan.shared as a sibling first, then run mvn install, before installing your project.
If you want to replicate the functionality of your project into your own stand-alone project, you will need to pull some dependencies and code from each.
Another pattern I could have followed would be to create jammazwan.shared as a parent project. This pattern has been horribly abused in recent years, (IMO), creating insanely nested and hard to decipher project structures, so I just avoided it entirely.
What is this x… prefix?
The prefix x__ is used for maintaining sort order in a directory, providing packaging, and is otherwise meaningless. The x stands for example.
A side benefit is that I do a lot of work in a bash shell, so being able to type cd ../xao [tab] saves me a lot of time, and is easier to remember than a lot of project names.
Generated or not? README.md vs NOTES.md
Every project has a README.md which is generated from here, and never hand modified.
Some projects also have a NOTES.md which is entirely created by hand, and contains information which is not in the metadata. Go there first if you have any needs that are not answered in the opening page README.
What does jammazwan.maker have to do with any of this?
All x__projects are created with a generator. Interesting notes about the generator, if you care:
- Written entirely in Camel
- Can create, and update, any project.
- Uses Velocity component
- Open source, use it for anything you wish.
- Not in any way documented or supported.
Complex project warnings WTH?
Xab and at least one other project start out by advising you to go away. Kind of silly.
The whole point of x__projects is isolation of just one small thing. These projects break that implicit contract. So instead of learning just one thing you are confronted with way more than you can absorb, possibly doing more harm than good.
I’m still not sure why they are here, but some day I might come up with a better strategy and explanation.
Local v Remote JMS, DB, FTP
to be documented later, if ever.
X__Projects vs jammazwan.100? WTH?
Is Jammazwan about x__projects or jammazwan.100? Don’t they have different goals in mind?
- jammazwan is 90% about example projects
- jammazwan.100 is for advanced work
Uh, this isn’t exactly a comprehensive list of example projects.
Pull requests welcomed.