#111 Mavenizing

Christopher Piggott Thu 4 Jul 2013

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

Brian Frank Thu 4 Jul 2013

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.

Mike Jarmy Thu 4 Jul 2013

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.

Christopher Piggott Thu 4 Jul 2013

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

Christopher Piggott Thu 4 Jul 2013

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

Richard McElhinney Fri 5 Jul 2013

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

Brian Frank Fri 5 Jul 2013

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

Matthew Lohbihler Fri 5 Jul 2013

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.

Mike Jarmy Fri 5 Jul 2013

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

Matthew Lohbihler Fri 5 Jul 2013

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.

Christopher Piggott Sat 6 Jul 2013

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.

Christopher Piggott Sat 6 Jul 2013

>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 Lohbihler Mon 8 Jul 2013

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

Brian Frank Wed 10 Jul 2013

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

John MacEnri Fri 3 Apr 2015

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

Samuel Toh Tue 28 Mar 2017

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

Matthew Giannini Thu 6 Apr 2017

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/

Login or Signup to reply.