I'm forking Project Haystack for several purposes:

• I want to convert it to maven
• I want it packaged as a .war
• I am interested in converting the web server to use JAX-RS
• I want to separate the core library from the server component
• I would like to move the code into a proper namespace (org.something?)
• I'd like to release it into maven central

There are other things I'd like to do as well, like expanding unit tests (and converting them to use JUnit). I don't care about J2ME, though I won't intentionally do anything to break that.

Before I start any serious work I want to get some thoughts from you.

--Chris

I think making it available from Maven is a good thing. Although I recommend against anything that creates breaking changes in the APIs or can get out of sync with master repo. There is a big difference in changing distribution/packaging and changing the APIs/code itself.

So I think changing the package name is a bad idea.

If you can map tests to JUnit by reusing existing code (maybe tweak hooks), then that seems like good thing. Its a real shame that in 2013 you can't write unit tests using only the JDK.

I don't understand what convert to JAX-RS means, does that provide some value? Isn't that just a layer above servlet API itself?

Creating separate distributions/jars for different packages and making it available as war and Maven all seems like nice ideas.

That sounds like a really cool project. It'd be nice to see some work in haystack-java that made it easier to use in a normal Java web server environment.

NHaystack is constrained in many ways since it has to run on underpowered devices like Jaces. As such, it has to use Tridium's built-in web server (javax.baja.web.BWebService) rather than a "real" server. This also makes it play nicely with Tridium's authentication and such.

RE: J2ME, maybe what you can do is rig maven so that it will contain to build the core library against 1.3, but for the server jar that you are adding you can just do what you like with generics, java.nio, etc.

OK. I won't touch the packaging.

>I don't understand what convert to JAX-RS means, does that provide some value? Isn't that just a layer above servlet API itself?

Yes, it is ... that layer providing some basic kinds of things like routing, context injection, annotation-based security, and a bunch of other things. I think that defining MessageBodyReaders and MessageBodyWriters to handle ZINC and JSON would be helpful, too.

So based on your feedback, what I think I'll do is to just make a pom that builds the existing code, in the existing framework, into a jar. The only real conflict is the inclusion of servlet-api, but I can just leave that there and let the pom pull one in from maven central. So what I can do is release a separate project for the core, and have the enterprise version (using jersey, guice, websockets) be a completely separate project that just depends on the former.

Now to do this, I'm going to have to release it into maven central as com.autofrog.haystack ... of course I'll leave all the licenses etc. in place but I can't release into a groupId I don't own. Hope that's okay - if anyone feels strongly about this, let me know and I will come up with another plan. If someone more official wants to sign up for a maven central account that'd be fine, too. There's good documentation on how to approach naming here:

https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates

I am PERFECTLY fine pushing this out on my own groupId if nobody cares. What would be unfortunate is if someone decides to do the same later with their own, which tends to confuse people. (For example, jackson appearing under both jackson.com [old] and fasterxml.com [new]).

I pushed my fork to:

https://bitbucket.org/wz2b/haystack-java-maven

Before I release it, I want to ask one more time: do the original authors wish to do this instead of me? If I release it, it is going to be my fork, meaning the groupId will be mine. What's confusing about that is that people won't know where to find it there. They'll know if it's under a haystack related groupId.

My "fork" doesn't change any of the code, though, it's just repackaging it to use maven (including resolving servlet-api). If developers here have ANY interest in switching from ant to maven then it'd be better to take my pom and you guys release it. If not, then I'm willing to maintain the fork.

Next question is version numbers. My first release needs a version like "1.0". I'm new to the world of mercurial so I'm not sure what the conventions are for tagging/versioning but it seems like there's some advantage to me maintaining parity with you. Please advise!

--Chris

Hi Chris,

This does seem like an interesting project and a great way to promote the software stack built around our modelling and tagging standards.

Is it it possible, for the benefit of the community, if you could share your use-case for going down this road? Are you embedding it into any particular automation system? Is this work being done for any particular organisation?

I understand if you can't share too many details for commercial reasons but I think that we'd all like to hear about how your using this to promote the use of Haystack standards.

Cheers, Richard

Christopher, looking at your fork so far it looks like all you have done is add a pom file. If that is all, then I can merge your changes back into my repo. Email me at [email protected] to discuss

I agree that the current packaging is unfortunate; i will be moving it to something like you (Chris) suggested. Also, having the source dir in the root folder is problematic in Eclipse, so in my fork i've already moved it into a "src" folder.

Chris -- FWIW I am totally on board with moving from ant to maven. I chose ant because I thought we needed something other than a fan script to build it with, and I was already proficient with ant. But we can switch to maven, I have no problem with that whatsoever.

I hope that we'll be able to merge as many useful changes from other folks back into the "official" version as possible, so that everyone can benefit. What I've always done so far (well, up until yesterday) was just email Brian patches. I created a fork yesterday and did a pull request just because I wanted to experiment with that. Git probably does that approach better (though I am more of a mercurial proponent in other things).

I do agree that the packaging structure could perhaps look like "org.projectHaystack" or some such. So +1 to that idea from me.

For versioning, what I've always done with hg is just have a separate branch that builds are done out of, with changesets on that branch having commit messages saying which build they are from. E.g. NHaystack does it that way. So perhaps Brian and/or I could start that branch once we get your maven stuff pushed. We can call that 1.0, that sounds good to me.

And by the way, I'm with Richard in being curious as to what you are up to :-).

I did the repackaging in my fork today. "haystack" was moved to "org.haystack", and HVal and subclasses were moved to "org.haystack.tagval" because it was never quick to pick them out from all of the "H"s.

Matthew, in your fork I guess you can do whatever you want, but it should probably be org.projecthaystack right? haystack.org seems to be an unrelated project. That sounds confusing.

>I understand if you can't share too many details for commercial reasons but I think that we'd all like to hear about how your using this to promote the use of Haystack standards.

I'm sorry for not answering this part sooner.

I was working on a response to a government RFP for open source building automation systems. As part of this, my team and I started looking at existing object models. We came across Project Haystack and thought we'd like to consider it for either or both of the storage model or and REST API. The AFLv3 license makes it attractive because, even though our purpose is open source, we don't want to scare off vendors that may want to contribute drivers, analytics, etc. in the future.

When I get this working, I'm going to do a few things. I want to make a pom that wraps the haystack jar into a war. I'll probably deploy it on my Amazon EC2 instance, which is already running a J2EE container.

Second, I want to build a couple of agents -- starting with modbus, then BACnet, then ZigBee ZCL. I'm going to start with a read-only interface (pushing into haystack) to begin.

Third, I'd really like a websockets interface. I think it'd be a good and natural extension to the REST API, particularly what you call "watches."

The thing about mavenizing all of this is that it'll let me build on these things without having to do so through forking. When I get this released into maven central, to include haystack you just have to add

<depends>
   <groupId>org.project-haystack</groupId>
   <artifactId>haystack-core</artifactId>
   <version>0.1</version>
</depends>

to your project and it'll find it.

I'm still a little uncomfortable having the package names not being somewhat consistent with the groupId (sans hyphen, of course). But, I don't want to maintain a fork just for that... so if I can't convince the project to change package names, I'm going to just live with it as is.

I think this should be fun :-)

Matthew, in your fork I guess you can do whatever you want, but it should probably be org.projecthaystack right? haystack.org seems to be an unrelated project. That sounds confusing.

The other haystack.org doesn't appear to be Java-related, so i don't think there's much risk in using it as a package name. Still, it's little to me if folks like org.projecthaystack better.

But, I don't want to maintain a fork just for that...

My fork has a number of other changes, including (what i believe to be) better support for tag maintenance (relaxing the immutability of HVals et al), significant performance improvements (with more to come), and some additional features (such as a "like" operator).

I renamed the package to org.projecthaystack in the Java toolkit to be consistent with Christopher is doing with maven

Hi,

did the maven build of this project ever make it into a central maven repo anywhere?

Also interested in the maven build to include in a middle-tier layer we're writing to call into the SkySpark APIs

Thanks

John

Hi all, sorry for resurrecting this old post.

At the start of this, there was a discussion on tweaking the existing java.haystack project support deploying on a conventional web server like Jetty, which would require the build to a .war file.

Quote: I want it packaged as a .war

Just wondering, did we ever got to this?

Thanks! Sam

Hi Sam - I just pushed a changeset to the haystack-java repo that will generate a war file that can be deployed in a servlet container. I did not have it generate a web.xml that declares the example servlet because I assumed most people would want to write their own servlet handler for haystack servers.

So this war file just make the client library available for use in a server.

let me know if this meets your needs. To generate the war file:

./gradlew war

The war file will be in build/libs/