Maven Repository for Jide Jars.

[rahul.arora]

Hi ,
I am pretty sure people might have raised this point earlier, but we do see a benefit out there if Jide would allow downloading jars through a repository.It would be very very easy for us to use whichever version of jide we want.

Currently we have built our own local repo and everytime jide comes up with a new version, we had this activity of uploading jars to local repo and modifying pom.xml in our project.

Thanks
Rahul

[JIDE Support]

The main problem we are facing is we don't know to build password control to the maven repository.

Thanks,

[petecarapetyan]

Regarding the problem of getting password control to the maven repository.

The maven repo can be just a web server eh ? So we have had them on https, or http. I would imagine that even basic authentication with something like .htaccess file would be enough ?

Or, you could look at a product such as Nexus. I'm just not sure what capabilities it offers in this area but I bet it has some, and it has a free and open source version.

[robinroos]

So I'm about to commence a new Swing UI, and it looks like JIDE would be the best docking manager and Swing component framework. So I went to maven central to get the POM, and only the "common layer" is present.

Now I have to manually download jars, manually chase dependent jars (the pom would have ennumerated to Maven all the dependencies, and each dependent's POM would have done the same, so my dependency list would automatically be complete).

Please publish this information via Maven, even if you then require a license key file to be in the CLASSPATH at runtime. Lack of the key can invoke the "demo" functionality of popping up warning messages as the JARs are loaded....

If you'd already done this, then my project would already be using JIDE (and I would soon have to pay).

Robin.

[JIDE Support]

We probably don't want to publish the jide jars to any maven repostiories due to the reason I mentioned earlier. We also want to limit the number of people who can access jide release jars. Right now only customers can get jide release jars. But if there is anything else that we can do to make your setup your maven easier (after you download jide jars manually), please let us know.

Thanks,

[calmeby]

Ok, I really think you should setup a Maven 2 style repository. It's indeed possible to do with password authentication. The login details should be given to the authorized users, i.e. your customers. It's no significant difference to giving access to the download section on your site. Have a look at this page: http://maven.apache.org/guides/mini/gui ... maven.html. It contains details of what your customers need to do when your done with your part. Nexus is by the way a great artifactory (repository) server.

If you're still reluctant to setting up a repository and want to build a zip for download. Just build your project using Maven 2, zip the file tree under: ~/.m2/repository/com/jide/. It will save at least 15 minutes of hazzle for each of your customers, for each release. It'd be a great help.

Regards
Christian, Baymarkets

[malcolmdavis]

I’ve inserted the JIDE components I use in a local Maven repository. (not all, just 5 components)

Since the products I develop require Java 6, the JIDE component dependency tree is different than non-Java 6 applications (and what JIDE distributes). Additionally, I use some newer versions of some of the third party libs. Hence, it would not match a Maven repository that JIDE may setup.

When JIDE deliveries an update, I have a little script I run to insert the updates. Hence, just a few clicks and repository is updated, and then I verify the third party libs.

Just some thoughts,
Malcolm

[JIDE Support]

Thanks Malcolm for sharing.

[petecarapetyan]

Heads up to the JIDE team on a very easy approach to continuing existing password protection and throw a bone to all maven users who want to try your latest release.

1. Go get the free version of nexus from sonatype
2. deploy on a tomcat or ....
3. set up your own admin password so no-one can jack with it
4. upload jars easily - has a simple UI
5. set up password protected repository access in nexus using existing credentials

I've been using nexus for almost a year now and it's pretty easy and well documented stuff.

Do the above, and it becomes an easier way to try out, and thus sell your great product.

[calmeby]

I'm really curious to what the Jide team thinks about setting up a password protected Nexus repo, or just at least package another version of the release zip file that conforms to the Maven repository structure, using pom.xml files and the correct directory structure. I'm now about to, for the 23423 time, go through the hazzle of adapting the Jide release to our private and internal Nexus-server. This takes about 20 mins and is so boring I'm going under. Why don't spend a few hours on fixing your release packaging procedure, once and for all??! I mean, with all your modules you using Maven yourself internally, right?

BR
Christian, Baymarkets

[malcolmdavis]

Hello Christian,

I'm not clear why you have to update everything every time JIDE puts out a new release.

When JIDE deliveries an update, I have a little script I run to insert the updates. Hence, just a few clicks and repository is updated, and then I verify the third party libs.

I use my own JIDE structure:

Code: Select all

    \jide\jide-charts\2.10.0

My master POM.xml has jide-ver, which I modify and all the dependencies are up-to-date.

Code: Select all

    <properties>
        ......
        <jide-ver>2.10.0</jide-ver>
        ......
    </properties>

All my dependieces use the jide-ver.

Code: Select all

    <dependencies>
        ......
        <dependency>
           <groupId>jide</groupId>
           <artifactId>jide-common</artifactId>
           <version>${jide-ver}</version>
        </dependency>
        <dependency>
           <groupId>jide</groupId>
           <artifactId>jide-grids</artifactId>
           <version>${jide-ver}</version>
        </dependency>
        <dependency>
           <groupId>jide</groupId>
           <artifactId>jide-dialogs</artifactId>
           <version>${jide-ver}</version>
        </dependency>
        <dependency>
           <groupId>jide</groupId>
           <artifactId>jide-pivot</artifactId>
           <version>${jide-ver}</version>
        </dependency>
        <dependency>
           <groupId>jide</groupId>
           <artifactId>jide-charts</artifactId>
           <version>${jide-ver}</version>
        </dependency>
        ......
    </dependencies>

So I'm not clear why you have do this 23423 times, I update things about every 2-3 weeks on new releases.
24 times a year * 2 minutes = 1 hours a year updating the repository for JIDE updates.

If I had the time or was a little smarter, I could build my own maven-plugin for managing the all of this and just download the JIDE zips and go.

I could also be smarter on some of the Maven stuff, I think I could move dependency up. It works for now.

[calmeby]

Ok, first of all. You had to write a script to update the Jide jars. This is the first problem. I don't want to have to write a script for this. Even though it's doable it feels like it'd be a smaller effort and far much more reusable for Jide to publish the jars in Maven repository style on a hosted Nexus server, or if that's too much to ask, at least in a zip file that I may extract on our Nexus server.

Secondly, and much less important. I don't have a clue what you mean with "you're maintaing own Jide structure" and "that you're not clear why I have to update everything every time I want to upgrade my Jide dependencies". I don't want to go into this discussion either.

My strong belief is that Jide should conform to one of the most widely spread standard of building tools, i.e. Maven. I'd like a reply from the Jide guys if that's possible. Thanks!

Best regards
Christian

[malcolmdavis]

Christian

I have installed Maven on numerous clients as a consultant, from commercial software to fortune 500 companies. I have also worked with Maven since the early days of 1.0. Hence, I know a little bit about Maven, and maybe more of than the JIDE people.

1. Maven ain’t all that: People are constantly looking and creating alternatives to Maven. http://www.streamhead.com/maven-alternatives/. I know many people that avoid the entire Maven thing all together and keep it simple with Ant.

2. If you like it, learn it: You are asking JIDE to invest time and money into something that will change. If you such a big Maven fan, and think the way you do about Maven, learn Maven. Write a script or two, get your head around the problem space. Once you get into Maven, maybe you will understand why people look for alternatives.

3. Build tools: I have not seen any empirical evidence on your claim about Maven. Just by own experience with others, I think Ant or the IDE is the most widely used build tool, not Maven.

Lastly, JIDE knows it’s client base better than you or I. I’m sure if they think it is reasonable, JIDE will do so.

[JIDE Support]

Hi Christian,

I am not really a fan of maven so some of my points below might be incorrect or inappropriate so please feel free to correct. I just don't think it is a big deal for users to download the release zip file, copy the jide jars from the zip and overwrite the existing jide jars (that's why we didn't put version number in the jar file name so that they will overwrite). Not consider the downloading time, it is at most 10 seconds of your time to copy the files. Is it really a big deal for you?

Even though we post a new release every 2 to 4 weeks, we don't really expect you upgrade all the time. Malcom updates very often. I guess it is mainly because he is a very active JIDE user who reported many bugs to us in the past (or because of the cute script he wrote so it is easier to upgrade;-). He wants to keep on the latest to get his bugs fixed. Most other users don't. We still heard people on 1.9.5 release. The philosophy for them is if everything works great, why bother upgrading. JIDE cover a lot of areas in Java UI development. It has more lines of code than Swing. So in my point of view, upgrading JIDE is like upgrading Swing. You need to test all the UI code depending on JIDE after you upgrade JIDE. Some companies allocate a whole release cycle to upgrade JIDE. If the upgrading is done automatically and silently, you don't even know JIDE is updated. For this reason, you will never ask maven repository for Swing/JDK, right? Isn't it the same thing for JIDE?

We are still using ant to do the build. Since we don't have many external dependencies, there isn't really a need to use maven internally. I am using maven for the JIDE Common Layer since its hosting site java.net has maven repository setup already. To be frank, it was not fun. It took me a long time to figure out how to do little things in maven comparing to ant which is more straightforward. Considering the complexity of our ant script, I don't dare to migrate to maven at the moment. Rather spend the time making more components

Malcom was just trying to share his experience. So please be nice to each other.

Thanks,

[calmeby]

Malcolm, I'm not even gonna comment your post. You were the one jumping on me with your latest post. I was addressing Jide support in this issue and I'm not interested in a discussion whether your script works, or not, or if I'm competent using Maven, or not. Frankly I didn't understand much from your explanation on how the script works. Following standards instead of home brewed scripting is a winner in my eyes.

A few comments on the other post. Since we're building with Maven we need all of our dependencies using the Maven structure. It's not working to just to have a bunch of jar files in a directory. Since we're a couple of developers we maintain a Nexus server so that at the time we upgrade, all of us get the dependencies automatically downloaded. It's about 15 mins of very boring work to upgrade to a new release. I have to fill in group name, artifact id, and version number for each of the jars. Then I need to open a file browser, selecting the jar, add that to a list box. The submitting.

And furthermore, as a comment on your release strategy. Today I upgraded to 2.10.0 and that had a severe error for Mac users. One of your guys replied and announced that a patch release will be posted later this week. That's awesome! One problem with this though is that I've got to spend another 15 mins to upgrade to 2.10.1.

Jide is a very competent software, taking GUIs in Java to a place far beyond Swing. I've been working with Swing intensively for a few years and I'm happy that my current company found Jide and decided to use it. As with all software bugs appear. In a perfect world you just upgrade and see whether it's gone. For us Maven users, and I can assure you that our company is not alone (just look at the other posts in this thread), it'd be a no-op to to upgrade if you found it worth the effort to extend your build procedure to package a Maven style zip file as a complement. Then it'd be easy to upgrade to get rid of bugs or add functionality, and just let the software go through functional testing procedures. If it fails, it's not a big deal to downgrade again. Just a version variable in a pom file.

Well, now I've spent half an hour on this discussion. I'm gonna leave it here. If you don't want to still, I'm fine with that. We'll have to take turns doing the upgrades among us developers. I've got a feeling though that you can reach more customers to try the product if the hazzle of getting it into a Maven build procedure is down to almost zero.

Peace and best regards
Christian

[calmeby]

I sat down and wrote an Ant script for making the conversion to the Maven friendly format I suggested. I'll use it myself and if anyone else needs it, feel free. I'm running it with Ant 1.8, but I believe 1.6+ would do. Please note that antcontrib is required in the ANT_HOME/lib/ folder.

It produces a zip file in the current directory and is run like below. The pom template file (attached as well) needs to be in the current directory.

/usr/local/ant/bin/ant -f mavenify_jide.xml -Drelease.version=2.10.0

The zip file should be possible to extract in your local Maven repo, or on the file system of the Nexus server.

Please note that it was at least 5 years since I touched Ant scripts, so I'm a bit rusty. Hope you can make something out of it. In the best of worlds this could be integrated into the Jide build procedure. If not, I'm happy using it myself.

Best regards
Christian

[JIDE Support]

Thank you Christian. I am sure other Maven users will appreciate your effort.

[buntonn]

Thanks Christian,

Found this really helpful.

Nick

[robinroos]

There are customers watching this thread who are content to use ANT. That is fine for them and should not be discouraged.

There are other customers watching this thread who wish to integrate JIDE into their project dependencies using Maven.

The two requirements are not mutually exclusive. JideSoft should seek to satisfy both sets of customers, and may see their customer base grow as a result.

Kind regards, Robin.

[JIDE Support]

We have migrated our code base of Common Layer from java.net to github, and changed the main building method to Maven. However ant method is still available.

Please refer to the README.txt on the new code base at https://github.com/jidesoft/jide-oss for a brief usage.

Thanks,

[gqman69]

Ok, fine. The jide-oss is on github and uses maven. Bravo.

Doesn't help the paying customer like us. What is so difficult with providing the poms for each artifact (jar) ?

You can use ivy (http://ant.apache.org/ivy/history/lates ... kepom.html) to do it.

I can understand not providing a private repository but come on.

Sad.

[JIDE Support]

We are just not sure how to ensure the repository can only by customers.

[gqman69]

You may want to check Sonatype Nexus (Recommended, http://www.sonatype.com/Products/Nexus-Professional) or Artifactory (http://www.jfrog.com/home/v_artifactorypro_overview).

You can setup the repository as to require a login/password.

But at the minimum, without using a repository, without converting your project you might want to provide the poms (pom.xml) associated to your jars (artifacts).

This way when we download a new version we can simply deploy in our repository without the hassle of validating dependencies for each jars (README.TXT).

[JIDE Support]

The user calmeby actually provided a script on this page (scroll up to see it) to convert any JIDE releases to a maven compatible format. It worked fine when I tried it. You can easily do it yourself by running the script after downloading any JIDE releases, then copy the result to your maven repository. We think the effort is very minimum. That's why we think it is okay to leave it to our users.

[gqman69]

Obviously this is futile.

It amazes me how you do not get it. Fine.

The script you are talking about doesn't help me one bit. I have my own script. That's not the point.

One word: Dependencies.

This is 2012, 4 years after someone said Maven isn't all that... yet Maven is very much alive and arguably the new standard.

All Apache projects use Maven, almost all Java OSS use Maven, we use Maven, most of the world use Maven...

Why do I have to manually check dependencies for each jar you provide ? You see, from release to realse I have to make sure dependencies are the same (versions?). I have to be thorough.. This cost me time. When, really, you have this information, you can provide this information for a very low cost. To be fair you do provide this information in the form of a README.TXT !

Reminder: This is 2012.

I would invite JIDESoft to take pause for a moment and look at the advantage Maven provides. No. Forget Maven, look at Ivy and its Maven handling. You guys use Ant and Ivy is part of it.

I'll give you 1 of my pom.xml for jide-grids.jar

Code: Select all

<project>

    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.jidesoft</groupId>
        <artifactId>jide-parent</artifactId>
        <version>3.4.4</version>
    </parent>

    <artifactId>jide-grids</artifactId>

    <dependencies>
        <dependency>
            <groupId>com.jidesoft</groupId>
            <artifactId>jide-common</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>poi</artifactId>
            <version>${poi.version}</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>ooxml-schemas</artifactId>
            <version>${poi-ooxml.version}</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.apache.lucene</groupId>
            <artifactId>lucene-core</artifactId>
            <version>${lucene.version}</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>${hibernate.version}</version>
            <optional>true</optional>
        </dependency>
    </dependencies>

</project>