search

nexml / nexml.java

Java API for NeXML.
MIT License
4 stars 6 forks source link

Update to v1.6 #20

Closed daisieh closed 7 years ago

daisieh commented 7 years ago

This just updates the version numbers for Maven, including the README. If merged, can you update the version stored at the maven repository?

rvosa commented 7 years ago

Hi Daisie,

just to verify, are you sure that the new maven naming scheme is correct? Specifically, does the README.md in the root of the repository indeed reflect our intentions? The reason I'm asking is that in the previous version, the naming was like this:

org.nexml.model nexml 1.5-SNAPSHOT

And this has changed to:

  <groupId>org.nexml</groupId>
  <artifactId>model</artifactId>
  <version>1.6</version>

In other words, both the groupId namespace have changed (s/org.nexml.model/org.nexml/), as well as the artifactId (s/nexml/model/), which results in a different folder structure inside the maven repository and a different, less descriptive, name for the nexml JAR. Why would we want it this way? There could very well be reasons I'm not aware of, just checking to make sure.

Best wishes,

Rutger

On Tue, Apr 4, 2017 at 2:24 AM, Daisie Huang notifications@github.com wrote:

This just updates the version numbers for Maven, including the README. If merged, can you update the version stored at the maven repository?

You can view, comment on, or merge this pull request online at:

https://github.com/nexml/nexml.java/pull/20 Commit Summary

  • Update to v1.6

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nexml/nexml.java/pull/20, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGf-nzsdZuBXFH4ah9NmwWoYeFWKtOyks5rsY2jgaJpZM4MyQBb .

daisieh commented 7 years ago

I refactored the targets in the last PR #19 so that there are now several separate target products instead of one single uber-NeXML jar. The rearranged folder structure reflects that, and so do the artifactIds. It seems to me to be good practice to allow people to be able to install just one target, like the model, without having to build dependencies on all of them.

So in the new arrangement, there are four separate sub-targets that are built by the root POM, and any one of those should be able to be used as its own dependency. These are model, mesquite-module, transformer, and validator. I assumed that the "model" part of the groupId was really part of the model target, but perhaps I'm misunderstanding your intent?

rvosa commented 7 years ago

Ah, great, that makes sense.

So, I should actually make all these artifacts separately and push them all into the maven repo, yes? At this point, all maven knowledge has leaked out of my brain so I am literally back to 'hello world' as far as that is concerned (so, any hints?).

Thanks! :)

On Tue, Apr 4, 2017 at 6:42 PM, Daisie Huang notifications@github.com wrote:

I refactored the targets in the last PR #19 https://github.com/nexml/nexml.java/pull/19 so that there are now several separate target products instead of one single uber-NeXML jar. The rearranged folder structure reflects that, and so do the artifactIds. It seems to me to be good practice to allow people to be able to install just one target, like the model, without having to build dependencies on all of them.

So in the new arrangement, there are four separate sub-targets that are built by the root POM, and any one of those should be able to be used as its own dependency. These are model, mesquite-module, transformer, and validator. I assumed that the "model" part of the groupId was really part of the model target, but perhaps I'm misunderstanding your intent?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/nexml/nexml.java/pull/20#issuecomment-291559921, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGf-q_09JcBkByyfxg0SVd42gg_kB4Pks5rsnMSgaJpZM4MyQBb .

daisieh commented 7 years ago

I think separate artifacts, yes. I have never made a maven repo either; I was hoping you knew how! Time for some googling, I guess :)

daisieh commented 7 years ago

Hi Rutger, sorry to bug you again after several months...did you figure out how to update the maven repo, or should I look into it myself?

rvosa commented 7 years ago

Hi Daisie,

recently I have been working on resurrecting the TreeBASE build, which uses the 1.5-SNAPSHOT version of the NeXML libraries. To this end I revisited the maven repo, and I now know that this is hosted here: https://github.com/nexml/nexml.github.io/tree/master/maven/repository/org/nexml/model/nexml/1.5-SNAPSHOT

Which means it becomes available thusly in the pom.xml of TreeBASE:

m2.nexml.repos NeXML Remote Repository http://nexml.github.io/maven/repository org.nexml.model nexml 1.5-SNAPSHOT

Now, it appears to me that your refactoring should be able to live peacefully next to that. The way to do that would consist of something like:

The exact steps were a bit of trial and error for me to get the metadata right but eventually the build picked up the 1.5-SNAPSHOT artifacts. Maybe it's best if you do the same trial and error for the mesquite build? I've given you admin rights to the nexml.github.io repo so you can poke around till it works.

Best wishes,

Rutger

On Sat, Aug 26, 2017 at 3:39 AM, Daisie Huang notifications@github.com wrote:

Hi Rutger, sorry to bug you again after several months...did you figure out how to update the maven repo, or should I look into it myself?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/nexml/nexml.java/pull/20#issuecomment-325071013, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGf-gYINcc_T1aQc_bo5RVxhNW6vE17ks5sb3dYgaJpZM4MyQBb .

daisieh commented 7 years ago

Thanks for the access! I can figure out how to set up the version I need for Mesquite.

I think that generally speaking, you are probably supposed to put a non-snapshotted version into the repo itself? Like, snapshots are meant to be temporary versions that you are building in your local repo.

rvosa commented 7 years ago

Thanks for the access! I can figure out how to set up the version I need for Mesquite.

I think that generally speaking, you are probably supposed to put a non-snapshotted version into the repo itself? Like, snapshots are meant to be temporary versions that you are building in your local repo.

I know, but I am an idiot and now this artifact version name has taken on a life of its own. I should fix that. :)