Java questions which don't deserve their own thread, yet.

«‹›147 »

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

GrumpyDoctor: Jan 25, 2005; Trust me. I'm a doctor. An ANGRY doctor.

Gazpacho posted:

You would not implement MouseListener on the component class. If you want the component to show some visual feedback that it was clicked, or other such intrinsic behavior, then the component should create an inner MouseListener object in its constructor and add that listener to itself.

If you want the component to report back to the application that it was clicked, for the application's own purposes, then the application should create a MouseListener object and add it to the component.

Perfect, thanks!

# ? May 12, 2013 17:27

Adbot: ADBOT LOVES YOU

# ? May 24, 2013 23:47

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

baquerd posted:

Can someone point me in the direction of difficult problem sets dealing with low-level concurrency? I feel the need to brush up, having been spoiled with Spring and dealing with problems that don't care about approaching concurrency with a naive solution. As a related aside, I've had a copy of Java Concurrency in Practice for many years.

One of the best ones I've seen is the one Rich Hickey demonstrated about an ant colony.

Best links I can find are these:
http://juliangamble.com/blog/2011/1...i-demo-of-ants/
https://gist.github.com/jjcomer/1494094

# ? May 13, 2013 03:38

DholmbladRU: May 4, 2006

I am attempting to take in a String which is poorly formatted xml similar to below

code:

<parent>
<row id="1">
  <rowcell>Central</rowcell>
  <rowcell>2008</rowcell>
  <rowcell>$196,301</rowcell>
</row>

<row id="2">
   <rowcell>Central</rowcell>
  <rowcell>2009</rowcell>
  <rowcell>$254,469</rowcell>
</row>
</parent>

I read it into a documentbuilder and then begin to parse it. But for some reason when i get the parent node and perform NodeList.getLength() there is only one child node available.

code:

 DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
			    InputSource is = new InputSource();
			    is.setCharacterStream(new StringReader(xml));



			Document doc = db.parse(is);

			NodeList nodes = doc.getElementsByTagName("parent");

Does anyone have any insight?

# ? May 14, 2013 22:09

lamentable dustman: Apr 13, 2007; "I'm not laying underneath a grown man with my legs spread on worldwide TV. Some guys subscribe to that theory, but I'm a Republican, and we don't do that."

The XML works fine for me. The first nodelist returns the "parent" nodes which is length 1. Getting the children of parent returns the "row" nodes.

code:

		DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
		InputSource is = new InputSource();
		String xml = "<parent><row id=\"1\"><rowcell>Central</rowcell><rowcell>2008</rowcell><rowcell>$196,301</rowcell></row><row id=\"2\"><rowcell>Central</rowcell><rowcell>2009</rowcell><rowcell>$254,469</rowcell></row></parent>";
		is.setCharacterStream(new StringReader(xml));

		Document doc = db.parse(is);

		NodeList nodes = doc.getElementsByTagName("parent");
		for (int i = 0; i < nodes.getLength(); i++) {
			Node n = nodes.item(i);
			System.out.println(n.getNodeName());
			NodeList nl = n.getChildNodes();
			for (int j = 0; j < nl.getLength(); j++) {
				Node n2 = nl.item(j);
				System.out.println(n2.getNodeName());
			}
		}

code:

parent
row
row

# ? May 14, 2013 22:21

loinburger: Jul 10, 2004; Sweet Sauce Jones

I'm creating a ConcurrentHashMap wrapper that supports "snapshots" in order to provide consistent iterators - the ConcurrentHashMap's iterators are "weakly consistent" which means that they may or may not reflect changes made to the underlying map after the iterator was created, but I need iterators that are strongly consistent (if two iterators were created at the same time then they should return precisely the same elements). I could use a ReadWriteLock, but iteration takes awhile (there are several thousand elements in the map and it takes at least a few dozen milliseconds for a reader to process each one) and I don't want writers to be blocked for that entire time (and if there enough iterators being created then the writers might block indefinitely), so I'm opting for an approach that doesn't use a map-wide lock:

1. The wrapped ConcurrentHashMap's keys are Strings, and its values are instances of ConcurrentSkipListMap<Long, T>
2. When an element is added to the hashmap with putIfAbsent, then a new skiplist is allocated
3. A key-value pair <key, value> is added via map.get(key).put(System.currentTimeMillis(), value) (I don't try to prevent collisions in this skip list map - if two writes happen at exactly the same time then only one gets saved)
4. To query the map, I use map.get(key).lastEntry().getValue() to return the most recent value. To query a snapshot (e.g. with an iterator), I use map.get(key).lowerEntry(iteratorTimestamp).getValue(), where iteratorTimestamp is the result of System.currentTimeMillis() called when the iterator was initialized
5. If an object is deleted, I use map.get(key).put(System.currentTimeMillis(), DELETED), where DELETED is a static final object

The problem is that this map will grow indefinitely; if all iterators started on or before X have terminated then it is safe to remove all skip list keys less than X (provided that there is a higher key in the map, e.g. for X = 50 then given a skip list with keys {1, 40, 80} I can remove {1, 40}, but given keys {1, 40} I can only remove {1}), however I don't know of the best way to determine this. If an iterator's "hasNext()" method returns "false" then the iterator has terminated, but not every iterator is necessarily going to run to completion. What I'm doing at present is maintaining a list of weak references to the iterators returned by the wrapper so that I can determine when an iterator has been garbage collected.

code:

private ConcurrentSkipListMap<Long, WeakReference<Iterator>> iteratorMap = new ConcurrentSkipListMap<>();

public Iterator entrySetIterator() {
     Weakreference<Iterator> weakReference = new WeakReference(wrappedMap.entrySet().iterator());
     long timestamp = System.currentTimeMillis();
     while(iteratorMap.putIfAbsent(timestamp, weakReference) != null) {
         timestamp++; // timestamp collision
     }
     return weakReference.get();
}
    
public void run() {
    while(true) {
        long latestGC = 0;
        for(Map.Entry<Long, WeakReference<Iterator>> entry : iteratorMap.entrySet()) {
            if(entry.getValue().get() == null) {
                iteratorMap.remove(entry.getKey());
                latestGC = entry.getKey();
            } else break;
        }
        // remove ConcurrentHashMap entries with timestamps less than `latestGC`
        Thread.sleep(300000); // five minutes
    }
}

The "run" method finds the latest timestamp that it is safe to remove from the wrapped map's values, removes them, and sleeps.

I'm wondering if there's already a Java library that implements something like this, and barring that whether there is a better way to determine when all iterators created on or before a certain time have been termianted.

loinburger fucked around with this message at May 17, 2013 around 20:44

# ? May 17, 2013 19:11

rhag: Mar 3, 2009

From what I can tell, one way to achieve what you need (consistent iterators) would be to just clone the map, and return the iterator of the cloned map. Then...yea, that iterator is consistent. Will never change.

The solution you have there looks fishy to me, but unfortunately I can't think right now of another way. Have you looked at guava? Can't use anything from there? http://code.google.com/p/guava-libr.../GuavaExplained

# ? May 17, 2013 21:19

loinburger: Jul 10, 2004; Sweet Sauce Jones

No luck with Guava, ditto with Apache Commons. It seems that third party libraries rarely implement new concurrent collections.

And unfortunately a clone won't solve the problem unless I lock the map while creating it - otherwise I'd be using an iterator to copy the map and that iterator wouldn't provide strong consistency, so two map clones initialized at the same time might not be identical. (If I locked the map, cloned it, and iterated through the clone then I'd have to lock the map for less time than I would if I locked the map and iterated through it since the time it would take to copy each element is less than the time it would take for the iterator to process each element, but nevertheless I'd prefer a solution without locks if possible.)

loinburger fucked around with this message at May 17, 2013 around 21:31

# ? May 17, 2013 21:27

Win8 Hetro Experie: Apr 17, 2009

How can you tell if two iterators were created at the same time? System.currentTimeMillis() gives out long values so it has 1ms resolution but the actual value is provided by the OS and it might only be precise to 15ms or so. Then the thread is running on a CPU which operates in the gigahertz range but something happening 1000 times a second is only in the kilohertz range, 6 orders of magnitude slower, so you'd need to use System.nanoTime() which has its own problems to correlate between threads.

And then there's the really weird stuff, like Relativity of simultaneity. Threads can only communicate at the speed of light, so it might be the case that thread A sees the order of iterators being created as B<A<C and thread B sees the order as C<B<A and that the reality is they are both correct.

# ? May 17, 2013 22:56

loinburger: Jul 10, 2004; Sweet Sauce Jones

System.currentTimeMillis() provides sufficient accuracy for me - that's enough to ensure that two iterators created at more or less the same time will see the same output (with perhaps one update or deletion), whereas a weakly consistent iterator can't provide that strong of a guarantee. To provide a stronger guarantee I'd need to lock the hell out of everything

loinburger fucked around with this message at May 17, 2013 around 23:20

# ? May 17, 2013 23:03

Aleksei Vasiliev: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Just a reminder, currentTimeMillis can run backwards or skip around due to clock adjustments.

# ? May 17, 2013 23:36

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

The first thing that came to mind for me was structure sharing. Maybe you can look at this library? It has a PersistentHashMap you can probably steal and repurpose.
https://github.com/krukow/clj-ds

My thoughts are, if the underlying CHM changes after the snapshot iterator is generated, the iterator's internal instance simply will not be aware of the modified entries, but all subsequent operations on the original CHM instance will be available for any other operations.

You will likely have to do some wizardry to regain the full semantics of CHM but it shouldn't be too hard.

# ? May 17, 2013 23:44

loinburger: Jul 10, 2004; Sweet Sauce Jones

Thanks, that's the sort of thing I was looking for - I'd tried looking through Purely Functional Data Structures for something along those lines, but all that was in the book were queues and heaps.

# ? May 17, 2013 23:57

Win8 Hetro Experie: Apr 17, 2009

Providing a consistent and realistic ordering of events is a lot more reasonable goal. Without resorting to locking creating copies and iterating over them seems like the way to go.

How about:

- a primitive which is a copy of the map and the millisecond timestamp when the copy was finished. This isn't a snapshot but it becomes one.
- a concurrent List which holds snapshots.

To give out an iterator, create:

- primitive A and declare its timestamp as the timestamp of the iterator.
- primitive B right after primitive A.
- the snapshot by combining everything up to A's timestamp from both A and B. This snapshot's timestamp is primitive A's timestamp. Add this snapshot to the list.

Now you have a snapshot that can be iterated by anybody and all that's left is the cleanup.

So, create a copy of the snapshot list. If there's any snapshots with a timestamp less than your timestamp, take the oldest one of them and remove it from the shared snapshots list. Then, remove everything in it that's been superseded in your snapshot from the map. Repeat the copying until there are no more snapshots that are older than yours or you find a newer snapshot, in which case just return that.

Maybe.

Win8 Hetro Experie fucked around with this message at May 18, 2013 around 00:24

# ? May 18, 2013 00:20

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

It sounds like you're looking for a persistent data structure. You can implement a persistent data structure by just holding a bunch of snapshots, but there are better ways to do it.

A hashmap is surprisingly easy to implement persistently (as long as you don't need retroactivity), all you really need is a persistent list implementation to chain off each bucket. You can find examples of persistent lists and such in the literature.

# ? May 18, 2013 03:56

loinburger: Jul 10, 2004; Sweet Sauce Jones

That's essentially what I'm doing right now, except that I'm chaining with a skip list instead of a linked list; however, considering that most of the time I'm only returning the highest element in the skip list, it may be worth replacing the skip list with a simpler alternative e.g. a ConcurrentLinkedQueue

# ? May 18, 2013 04:11

The Gnome: Sep 8, 2011

Is anybody available who is familiar with WEKA and/or J48 algorithm? I have to do some data mining and I just need some help with this.

Thanks!

# ? May 18, 2013 15:38

Safe and Secure!: Jun 14, 2008; OFFICIAL SA THREAD RUINER
SPRING 2013

Neat, I've never heard of persistence in data structures before. Are persistent data structures commonly used in concurrent applications?

# ? May 18, 2013 19:43

loinburger: Jul 10, 2004; Sweet Sauce Jones

Sort of - they're commonly used in functional programming, which is commonly used for concurrent applications. They're not as common in languages with mutable data structures (C++/Java/etc), which is why Java doesn't have a persistent map in its library.

# ? May 18, 2013 20:08

dereekb: Nov 7, 2010; What do you mean "error"?

Ok, finally got around to playing with Spring, starting with this tutorial of Spring Security + Google App Engine.

I am having trouble with using Hibernate Validator, since at run-time I get a massive error that goes:

code:


java.lang.ExceptionInInitializerError
	at org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator.interpolateExpression(ResourceBundleMessageInterpolator.java:227)
...

Caused by: javax.el.ELException: Could not find expression factory class
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:209)
...

Caused by: java.lang.ClassNotFoundException: de.odysseus.el.ExpressionFactoryImpl
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
...

WARNING: Nested in java.lang.ExceptionInInitializerError:
javax.el.ELException: Could not find expression factory class
	at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:209)
...

Caused by: java.lang.ClassNotFoundException: de.odysseus.el.ExpressionFactoryImpl
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
...

So, it's looking for "de.odysseus.el.ExpressionFactoryImpl", which I solved first by adding the JUEL API which this is asking for. However, Google App Engine does not play nicely with JUEL, so I can't add that.

So, I went back, removed Hibernate validator, but Spring doesn't see the Apache Commons validator I added, so I check to see if Hibernate even needs JUEL, and it doesn't so I am scratching my head wondering where the hell "de.odysseus.etc..." is being called from and if I can remove it without a problem.

So my question is, what am I probably loving up and if anyone has insight on how to get back on track.

Edit:

Looking at the java docs for ExpressionFactory, I'm assuming that JUEL is just the default that is picked, but still have no idea how to solve that problem.

Also it appears that the issue has been reported on the JUEL github project, but hasn't been addressed I guess.

Edit 2:
I downloaded the JUEL source-code, edited the offending material, recompiled, and problem solved... Sort of.

If there are tips on how to "do" Bean Validation much more cleanly, or if you can think of what I'm missing for the Expression Factory, I'd love to hear ideas.

dereekb fucked around with this message at May 20, 2013 around 04:42

# ? May 20, 2013 03:33

jiffypop45: Dec 30, 2011

rhag posted:

The best way to do that is to provide an option to the user (a dialog) where they can enter their credentials to the database. And be able to change those credentials when they change. And store those credentials with java.util.Preferences (encrypted in some way, just so the plain password is not trivially readable).

If that's not possible (the users won't know those credentials), another way would be to get the credentials from a server upon starting up. Or, even better, never do the actual queries yourself, but have a server that will do them for you and just return the results (via SOAP or REST web services let's say).

The worst way of solving that problem is to hardcode the credentials in the application, but hey...it will work though. Depending on who's the client for the application, it may be even fine (if only 10-20 people will use it in your organization, and everyone knows everyone, having a more secure environment may not be worth it).

At the end of the day, the answer is depends: how much time and complexity do you want to add to the application?

We have a SRS setup that I could have my contact in IT setup a "hidden" report to pull from that would get the info I need. Any idea how hard it would be to parse data from a SQL Reports Server? I actually have permissions to access the reports on that server.

# ? May 20, 2013 19:05

rhag: Mar 3, 2009

jiffypop45 posted:

We have a SRS setup that I could have my contact in IT setup a "hidden" report to pull from that would get the info I need. Any idea how hard it would be to parse data from a SQL Reports Server? I actually have permissions to access the reports on that server.

I personally never worked with SQL Reports Servers, but after a quick glance at the Wikipedia page (http://en.wikipedia.org/wiki/SQL_Se...orting_Services) it seems that it would be quite trivial:

quote:

Reports defined by RDL can be generated in a variety of formats[2] including Excel, PDF, CSV, XML, TIFF (and other image formats[3]), and HTML Web Archive

Since they are called "Reporting Services" I assume that there must be some easy ways to call them remotely. It even comes with a web application itself that users could use to generate/launch and see reports.

# ? May 20, 2013 19:14

dereekb: Nov 7, 2010; What do you mean "error"?

I'm getting another big "gently caress you" thrown at me.

So last night after spending hours debugging the previous problem, I finally got some time to get Apache Tiles working too.

This morning however I must have changed something wrong, because now instead of outputting the correct view, it displays this in plain text:

code:

WEB-INF/tiles/_common/meta.jsp
WEB-INF/tiles/_common/header.jsp
WEB-INF/tiles/register/body.jsp
WEB-INF/tiles/_common/footer.jsp

The HTML for the layout file is there however, but the "<tiles:insertAttribute name="body" />" just inserts the name of the resource instead of inserting the resource. These resources are being checked, and exceptions get thrown if they are missing.

I rolled back my changes completely, but this error persisted. I spend 2 hours checking just about everything, including removing/adding it all over again and no luck still. After that, I just made a new project, started from scratch, and spent another hour getting to a bare-bones type deal but was greeted with the same result.

Any ideas?

Edit:

So, turns out it was a Google Apps Engine thing, since I moved them from "/WEB-INF/jsp" to "/jsp" as a last ditch effort and now it works.

GAE's little restrictions are such poo poo sometimes. Welp, back to actual programming.

Edit 2:

It came back, but this time I figured out it was the tiles definitions not working as I expected. I guess I'll have to dig into the documentation more...

dereekb fucked around with this message at May 21, 2013 around 04:11

# ? May 21, 2013 03:26

fletcher: Jun 27, 2003; ken park is my favorite movie

With the Apache CXF WebClient, is it possible to control the order of the XML elements? It seems to default to alphabetical, but I need to be able to POST this XML with a specific element order.

edit: Looks like there is an annotation, @XmlType(propOrder = { "propOne", "propTwo" }).

fletcher fucked around with this message at May 21, 2013 around 15:49

# ? May 21, 2013 15:09

yellowjournalism: Jul 31, 2004; gawtchyo dawda n err'fin

I'm not exactly sure where to ask this, but ever since the security debacles last month, I've disabled Java on all my browsers, and made sure to never run any applets or Java Web Start programs or whatever. Is Java as a web based platform basically just dead now? I'm told that the JVM, and Oracle in general, is just so far behind the web game at this point (unlike Google who has designed their sandbox from ground up to keep out of the client OS) that they won't catch up. Should I write Java off as anything but a trusted-download desktop application type deal?

# ? May 22, 2013 00:10

baquerd: Jul 2, 2007; Oh God! to hear the Insect on the leaf pronouncing on the too much life among his hungry brothers in the dust!

yellowjournalism posted:

I'm not exactly sure where to ask this, but ever since the security debacles last month, I've disabled Java on all my browsers, and made sure to never run any applets or Java Web Start programs or whatever. Is Java as a web based platform basically just dead now? I'm told that the JVM, and Oracle in general, is just so far behind the web game at this point (unlike Google who has designed their sandbox from ground up to keep out of the client OS) that they won't catch up. Should I write Java off as anything but a trusted-download desktop application type deal?

Java will shine on for many years as a server side development platform and for intranet programs. The general trust of public facing applets has perhaps been dealt a fatal blow however.

# ? May 22, 2013 01:35

yellowjournalism: Jul 31, 2004; gawtchyo dawda n err'fin

baquerd posted:

Java will shine on for many years as a server side development platform and for intranet programs. The general trust of public facing applets has perhaps been dealt a fatal blow however.

Sorry yes I totally mean client-side user-facing stuff in your browser, ok, good to know, thanks!

# ? May 22, 2013 02:54

Hard NOP Life: Jan 22, 2004; Your clothes.

Give them to me. Now!

baquerd posted:

Java will shine on for many years as a server side development platform and for intranet programs. The general trust of public facing applets has perhaps been dealt a fatal blow however.

As if anyone was developing applets in 2010, let alone 2013. Honestly Flash and Java lost their place the moment HTML5 came on the scene.

# ? May 22, 2013 03:57

yellowjournalism: Jul 31, 2004; gawtchyo dawda n err'fin

I wouldn't ever actually use Java applets to do something "worthwhile," it's just that my students (I teach AP CS) ask about them and if we can/should make some and I basically have said no, they're sort of a dangerous and dead thing now and wanted to make sure I've got the right idea in saying so.

# ? May 22, 2013 05:26

DreadCthulhu: Sep 17, 2008; u mad, brah?

Is there a good professional-oriented tome for Java that's basically a comprehensive deep dive into the language adjusted for year 2013? I have a bit of interest in compilers and process vms, so anything that gives quality insight into the runtime, the JVM and how the various internals work would be fantastic.

I have used Java for maybe two weeks every 3 years or so since the early 2000s and never really got to dig deep into it. Shouldn't be that far from C# which I've used for a while. Why Java now? I'm now finding myself writing quite a bit of Clojure, and I'm just not comfortable ignoring all the beefy underlying system that I could leverage as part of the work.

# ? May 22, 2013 07:10

fletcher: Jun 27, 2003; ken park is my favorite movie

Got a maven question. I feel like I'm having to update version numbers in too many poms to fix a bug, but maybe that's just how it has to be.

I've got a parent pom and several modules under it. I use the parent pom for the dependency management, so each module uses the same version of the libraries they share. module-app1 might also use stuff in module-app2 (is this my fatal flaw??) These modules then get deployed to a remote repository.

So it kinda looks like:

+ parent
--+ module-common
--+ module-app1
--+ module-app2

So lets say somebody finds a bug in module-app1. Upon investigation, it turns out the issue was actually in module-common. So then I have to touch the following poms:
1. parent/module-common/pom.xml - increment the version number
2. parent/pom.xml - specify the new module-common version in the dependency management section
3. parent/pom.xml - increment the version number
4. parent/module-common/pom.xml - use the new parent pom version
5. parent/module-app1/pom.xml - increment the version number
6. parent/module-app1/pom.xml - use the new parent pom version
7. parent/pom.xml - specify the new module-app1 version in the dependency management section

Now if I want module-app2 to also have this fix, I need to update the pom in there, update the parent pom again, etc, etc. This seems like a mess and I don't feel like I'm doing it the right way.

edit: http://jira.codehaus.org/browse/MNG-624 this kinda sounds like what i'm dealing with

fletcher fucked around with this message at May 23, 2013 around 00:20

# ? May 23, 2013 00:18

armorer: Aug 6, 2012; I like metal.

Your set up is extremely common for maven, and not really a problem. (Although your parent pom should NOT include dependencies on projects that reference the parent pom itself, that would create a screwy circular dependency and be problematic. It sounds like maybe you have done this? The parent pom should only specify other common dependencies, it should not depend on things that depend on it.)

If you need a project that groups dependencies of things that use your parent pom, you can have a separate project that basically just defines a pom, and then you can specify a dependency on that pom (of type pom) in your other projects. That allows you to group a number of dependencies together, and update versions in one place.

With things set up this way, you would have to do the following.

1) Fix the bug in common, and release a new version
2) Update the version of common to the new one in pom-project and release a new version
3) Update any downstream projects with a dependency on pom-project, and release new versions of them.

You don't need to release a new version of the parent project in this case, unless fixing the bug in common requires that you update a dependency that the parent specifies. In that case, there is a step 0 which is: Update the version in the parent and release a new version. Then steps 1 through 3 also include: update the parent version.

Does that make any sense?

# ? May 23, 2013 01:32

fletcher: Jun 27, 2003; ken park is my favorite movie

armorer posted:

Your set up is extremely common for maven, and not really a problem. (Although your parent pom should NOT include dependencies on projects that reference the parent pom itself, that would create a screwy circular dependency and be problematic. It sounds like maybe you have done this? The parent pom should only specify other common dependencies, it should not depend on things that depend on it.)

Yup that's what I did

armorer posted:

If you need a project that groups dependencies of things that use your parent pom, you can have a separate project that basically just defines a pom, and then you can specify a dependency on that pom (of type pom) in your other projects. That allows you to group a number of dependencies together, and update versions in one place.

With things set up this way, you would have to do the following.

1) Fix the bug in common, and release a new version
2) Update the version of common to the new one in pom-project and release a new version
3) Update any downstream projects with a dependency on pom-project, and release new versions of them.

You don't need to release a new version of the parent project in this case, unless fixing the bug in common requires that you update a dependency that the parent specifies. In that case, there is a step 0 which is: Update the version in the parent and release a new version. Then steps 1 through 3 also include: update the parent version.

Does that make any sense?

That does make sense, I'll try reorganizing things tomorrow and see how it goes. Thank you for the suggestions!

# ? May 23, 2013 01:59

rhag: Mar 3, 2009

You could also use the SNAPSHOT version for your own modules. That is, your modules depend on the other modules (that are yours) not on a specific version, but the SNAPSHOT one (e.g. 1.0-SNAPSOT). That way they'll always be in sync and depend on the latest version.
You could however, have a good reason not to do that, but instead only depend on a released version. At which point, your modules have to be "released" (published in your company's maven repository) to be used. This setup works really well when you have separate teams working on each module, but will create the work that you're describing.

# ? May 23, 2013 12:05

armorer: Aug 6, 2012; I like metal.

SNAPSHOT dependencies are great for when you have one team working on a common component, and another team working on a release that depends on that common component (or any analogous scenario really). It gives you an easy way to depend on the latest and greatest through your development cycle, and you just have to release the common thing before you release the primary project so that you can depend on a fixed version in your release. I don't think that is the issue he is having though. He has a parent that specifies dependency versions for projects that extend the parent, which is going to result in some unpleasant weirdness. Having a parent is good if you share a lot of external dependencies among projects, and want to make sure they all line up. If you want to do the same sort of thing with projects that extend the parent, then a pom dependency is very handy. It is also handy if you want to do something like make sure all your web apps use the same version of Spring dependencies, but you don't want to put them in the parent because not everything will need them. You make a pom project for Spring which specifies the various jars you need, and depend on that in your webapps. Then when a new version of Spring comes out, you update all the various versions in the spring-projects pom, and you only have to update one version (the spring-projects pom dependency version) in all your webapps.

armorer fucked around with this message at May 23, 2013 around 12:57

# ? May 23, 2013 12:51

Sedro: Dec 31, 2008

armorer posted:

Your set up is extremely common for maven, and not really a problem. (Although your parent pom should NOT include dependencies on projects that reference the parent pom itself, that would create a screwy circular dependency and be problematic. It sounds like maybe you have done this? The parent pom should only specify other common dependencies, it should not depend on things that depend on it.)

You can use dependencyManagement in the parent/aggregate pom without introducing circular dependencies:

parent/pom.xml

XML code:

<project ...>
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>parent</artifactId>
    <packaging>pom</packaging>
    <version>2.0</version>

    <modules>
        <module>module-common</module>
        <module>module-app1</module>
    </modules>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <artifactId>module-common</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>${project.version}</version>
            </dependency>
            <dependency>
                <artifactId>module-app1</artifactId>
                <groupId>${project.groupId}</groupId>
                <version>${project.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

module-common/pom.xml

XML code:

<project ...>
    <parent>
        <artifactId>parent</artifactId>
        <groupId>org.example</groupId>
        <version>2.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>module-common</artifactId>
</project>

module-app1/pom.xml

XML code:

<project ...>
    <parent>
        <artifactId>parent</artifactId>
        <groupId>org.example</groupId>
        <version>2.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>module-app1</artifactId>

    <dependencies>
        <dependency>
            <artifactId>module-common</artifactId>
            <groupId>${project.groupId}</groupId>
        </dependency>
    </dependencies>
</project>

Now any time you add a fix, you increment the parent pom version, point all modules to the new parent, then build the parent.

# ? May 23, 2013 15:37

armorer: Aug 6, 2012; I like metal.

So in this instance, all of your projects have the same version? I really don't see what you gain from this. Personally I use the maven release plugin for all releases, and avoid manual manipulation of the project version unless it's needed to increment the major or minor place. I am always doing development on a SNAPSHOT, and release new versions of whatever dependencies I modified to obtain a fixed release version before doing the primary release. If you have a child project inheriting a dependency on an earlier version of itself from a parent pom things are likely to get weird. Given that maven gives you other, more appropriate mechanisms to deal with this, I can only ask: why?

# ? May 23, 2013 16:50

Sedro: Dec 31, 2008

Yes, you would use the same version for each module and develop/release them as a single unit. Sometimes I don't need the granularity that Maven provides. For example, my application might reference a separate module containing binary resources (separated for reasons outside of maven), and the two artifacts must be deployed together.

# ? May 23, 2013 17:31

armorer: Aug 6, 2012; I like metal.

In that case, you are basically just developing one application, which is a different use case than I believe we are talking about here. If you are working on one application that is modularized, then that should work fine.

I believe in this case though we are talking about someone who has a parent pom used in several distinct applications, as well as one or more utilities that are only ever released as jars. It is relatively common in the corporate java world to have that sort of setup, and it allows you to push very common external dependencies out into the parent, and help avoid dependency conflicts between utility jars and applications (which might arise if they each handled that independently). In that sort of a setup, it is impossible to join all your different applications and utilities together into one uber project, because they are all being evolved for different reasons on different timeframes by different people.

# ? May 23, 2013 17:40

fletcher: Jun 27, 2003; ken park is my favorite movie

My use case is a bunch of uberjar command line programs (module-app1, module-app2, etc). I didn't want to use SNAPSHOT since I need these to be versioned so that the people using them know what version they are using.

# ? May 23, 2013 18:07

Adbot: ADBOT LOVES YOU

# ? May 24, 2013 23:47

armorer: Aug 6, 2012; I like metal.

Well if they are really distinct applications, and if you have them set up as modules under one project, I would recommend breaking them apart into separate projects. They can still extend a parent, and you can create a new pom project for shared dependency management in order to get it out of the parent. If they are all released together on the same schedule, and can logically be treated as one application, then doing what Sedro says should work and be even simpler.

As for snapshots, nobody should be using the SNAPSHOT version except the developers as they work on it. People will install (and other projects will depend on by release time) non-SNAPSHOT versions. The release plugin handles a bunch of stuff for you, including automatically updating your version to a non-SNAPSHOT before release, and then to the next SNAPSHOT after release. Generally speaking, maven developers should embrace SNAPSHOT versions.

You can end up in weird scenarios if you don't use it, generally in the case that you have a version of a dependency in your local maven cache, but it it doesn't match the actual released tagged version for that number, because you had local changes. If you only ever do development work in a project using a SNAPSHOT version, you will never end up with a "dirty" jar in your local repo. It gets worse if developers do releases from their own machines instead of a common build server, because then those dirty dependencies can end up in your release and you'll never know it. That can lead to "it doesn't happen on my machine" type of bugs that are very costly to track down.

# ? May 23, 2013 18:23

«‹›147 »

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.