You're certainly right. CU next week in Germany. :-)
-----Original Message-----
From: Arun Gupta [mailto:arun.gupta_at_gmail.com]
Sent: Montag, 16. März 2015 18:47
To: Markus Karg
Cc: users_at_glassfish.java.net
Subject: Re: Maven
Emotions on emails are always difficult to understand, lets keep them for personal interactions, possibly at JavaLand ;)
On Mon, Mar 16, 2015 at 10:29 AM, Markus Karg <karg_at_quipsy.de> wrote:
> Arun,
>
> sorry I just got angry reading that lot of nonsense about this very
> appreciated tool. I think we should close this thread, as it is
> off-topic anyways. :-)
>
> Regards
> -Markus
>
> -----Original Message-----
> From: Arun Gupta [mailto:arun.gupta_at_gmail.com]
> Sent: Montag, 16. März 2015 16:24
> To: Markus Karg
> Cc: users_at_glassfish.java.net
> Subject: Re: Maven
>
> Maven is as scary as any software is :)
>
> The issues with Maven are more talked about because of its excessive usage to build software. All my samples/demos, and most of Red Hat Java related workspaces, heavily rely upon on Maven anyway. So I don't think there is any need to defend for anybody!
>
> Arun
>
> On Mon, Mar 16, 2015 at 12:34 AM, Markus Karg <karg_at_quipsy.de> wrote:
>> Arun and Wayne,
>>
>> I need to chime in here -- can't stand the unjustified Maven-bashing
>> any longer! ;-)
>>
>> Maven in fact is the greates build tool I've ever seen, as it provides one single declarative solution to building any kind of project, independent of the platform and the IDE, which is great, as we have to deal with approximately 10 platforms and don't have the time to learn all compile switches of any fancy outdated product just to fix a bug. It even works with Delphi 1 (16 Bit), WiX, or InstallShield 10! We do not just need to "live with it", we should actually make it mandatory to everybody and stop to reinvent the wheel wrt build scripting each time a programmer is unhappy to read the Maven manual or take a class.
>>
>> I can't see anything that is "scary" with Maven (certainly it might have bugs just as any other software). It simply does what you tell it to do, but certainly you must know how to *correctly* tell it what that. Would be glad to to get an example what you mean with "scary", actually. As only project owners can upload to Maven Central, please complain with the particular product managers to get that fixed. Actually it is prohibited to upload unsigned JARs. But this has nothing to do with Maven as a tool! You don't even are forced use Maven Central but can use any other repository or download dependencies manually.
>>
>> Regards
>> -Markus
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Arun Gupta [mailto:arun.gupta_at_gmail.com]
>> Gesendet: Sonntag, 15. März 2015 03:14
>> An: users_at_glassfish.java.net
>> Betreff: [gf-users] Re: Java EE 7 Hands-on-Lab Updated (for You to
>> Use)
>>
>> Wayne,
>>
>> See in line ...
>>
>> On Sat, Mar 14, 2015 at 4:06 PM, Wayne Pollock <pollock_at_acm.org> wrote:
>>> It is a fine idea, well implemented. Yet, I do have concerns I'd
>>> like to discuss.
>>>
>>> Too many of these tutorials rely on GUIs and/or maven. The result
>>> is a lack of understanding of the underlying processes. I would
>>> like to see *just one* "Hello EE world" tutorial that describes
>>> compiling and deploying a WAR using nothing but javac and jar. Once
>>> the basics of how EE works (the directory structure of a WAR, the
>>> proper setting of CLASSPATH, etc.) is done, *then* is the time to go
>>> on to teaching the Java EE technologies using automation and GUIs, if you wish.
>>>
>>> Maven scares me. As far as I can tell from the Google searching
>>> I've done, the Maven central repository consists of unsigned contributed code.
>>> The maven tool automatically downloads, installs, and runs such code.
>>> I can't imagine how much longer it will be, before malware makes its
>>> way into developers' PCs, and ultimately to servers, using maven as
>>> an attack vector.
>>
>> Maven is indeed scary, but a pragmatic reality. So we all have to get
>> used to it :)
>>
>> Have you looked at https://github.com/javaee-samples/javaee7-samples
>> that shows Hello World samples for different Java EE 7 technologies?
>> They can run against WildFly or GlassFish.
>>
>> There is also https://github.com/javaee-samples/javaee7-simple-sample
>> that is a simple sample to showcase different Java EE 7 technologies.
>>
>>>
>>> Glassfish 4.1 scares me. I have reported the problem with it many
>>> times, to a deafening silence. It contains bad/corrupted jars in
>>> the official distribution, both from Oracle and from java.net. You
>>> can't see the errors if you build using a GUI such as Netbeans, or using ant or maven.
>>> But, add the javaee.jar to your CLASSPATH, and compile anything such as:
>>>
>>> class Foo {}
>>>
>>> with:
>>>
>>> javac -Xlint:all Foo.java
>>>
>>> and you will get about 20 warning messages about bad or missing jar
>>> files. (I did make a bug report on this as well.) I am currently
>>> switching my Java classes to use Wildfly. It's hard because, like
>>> all Java EE servers, the Wildfly docs make no mention of how to
>>> build code without using maven or some GUI IDE. They don't seem to
>>> come with a javaee.jar, or equivalent.
>>
>> Have you looked at
>> http://www.mastertheboss.com/jboss-server/wildfly-8/maven-configuration-for-java-ee-7-projects-on-wildfly?
>>
>>
>> Arun
>>
>>>
>>> The new paradigm is "Devops". Developers need to understand
>>> something about deployment, instrumenting code, logging, etc., in
>>> addition to understanding CDI or Java messaging. They need to know
>>> how to design file formats and message formats; many real-world
>>> enterprise applications do use files along with databases. Your
>>> tutorial should also address these issues, if possible.
>>>
>>> Finally, I would like tutorials to show correct security coding
>>> practices, such as the proper normalization, sanitization, and
>>> validation of external (untrusted, or "tainted") data. It's scary
>>> that even today, the #1 vulnerability is SQL injections. Yet, try
>>> to find any Java EE tutorials that do this, or any textbooks either.
>>> I haven't found any. No wonder each new generation of programmers
>>> makes the same errors.
>>>
>>> Thanks for the opportunity to vent a bit. Hopefully, you'll find my
>>> arguments have at least a little bit of merit. If so, you don't
>>> need to change the code; just add some comments here and there about
>>> what was left out for the sake of clarity, with some pointers to
>>> more information. As I said in the beginning, this is a good
>>> tutorial and well implemented. I just think it can be improved to
>>> give students a deeper understanding of Java EE development and
>>> deployment, and of security best practices.
>>>
>>> --
>>> Wayne Pollock
>>>
>>> On 3/13/2015 6:10 PM, Reza Rahman wrote:
>>>> Folks,
>>>>
>>>> Many of you are probably already familiar with the official Java EE
>>>> 7 Hands-on-Lab (https://glassfish.java.net/hol/). It is an
>>>> excellent learning resource initiated Arun Gupta while still at
>>>> Oracle. I just finished successfully delivering the lab once again at DevNexus 2015.
>>>> In preparation for DevNexus and beyond I made a few
>>>> updates/changes:
>>>>
>>>> * I tried to make the lab entirely self-directed and self-paced for
>>>> attendees by removing as many possible stumbling blocks (however minor) as possible.
>>>> * I updated the lab to use GlassFish 4.1 and NetBeans 8.0.2.
>>>> * I polished up the code to make it as realistic as possible within
>>>> the scope of a simple lab.
>>>>
>>>> The first bullet point above is what I would really like to bring your attention to.
>>>> Every time I have run this lab I've tried to execute it such that
>>>> it requires bare minimum or no involvement from me and in fact I
>>>> believe I've succeeded in doing just that. The reason this really
>>>> matters is that I think this lab material has much greater
>>>> potential than just something else our team does at conferences. I
>>>> believe that the lab is now in a state such that anyone can go
>>>> through the lab entirely on their own, by just using the public HOL
>>>> page. More importantly I think it is possible with very little
>>>> effort for someone to lead the lab in their user group or company.
>>>> I highly encourage you to do so if you have an interest in
>>>> supporting the Java EE community. If needed, our team could provide any help that you may need (such as being present virtually or working with you one-on-one to get you prepared). I've supplied all the resources that you should need on the public HOL page.
>>>>
>>>> Do drop me a note off alias if you have any feedback on this, if
>>>> there's anything that I can improve with the lab or if you need any
>>>> help. For sake of completeness, I should mention that Arun also now
>>>> has his own version of the lab
>>>> (https://github.com/javaee-samples/javaee7-hol) that you should
>>>> also take a look at if time permits.
>>>>
>>>> Cheers,
>>>> Reza | Java EE Evangelist
>>>> Cell: 267-798-9331
>>>> Home Office: 215-736-1208
>>>> Google/Skype: m.reza.rahman
>>>> Twitter: @reza_rahman
>>>> https://blogs.oracle.com/theaquarium/
>>>> https://blogs.oracle.com/reza/
>>>> https://cargotracker.java.net
>>>>
>>>> P.S.: In this same vein I'd like to point out that I've added
>>>> detailed speaker notes to my version of our current flagship Java EE 8 talk:
>>>> http://www.slideshare.net/reza_rahman/javaee8 (PowerPoint source
>>>> available for download). Making use of this, you could deliver this
>>>> talk yourself. As an example, Hanneli Tavante did this at ConFoo
>>>> and Josh Juneau will be doing that soon at the Chicago Coder Conference.
>>>> Of course talks are highly personal and I don't expect that anyone will just use my deck as-is (in fact neither Hanneli nor Josh are doing that).
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta
--
http://blog.arungupta.me
http://twitter.com/arungupta